Today’s Agenda

1. Where we’re at

2. Upcoming requests for help

3. Stats deep dive

• DPLA = harvest is a go!

• API out there

• Calisphere designs: so close

Beyond the Wiki:new resources

http://bit.ly/UCLDC

What now?

• Finalizing harvests from…

Irvine (virtual reading room)

UCLA (various from Fedora)

San Diego (various from Fedora)

San Francisco (Tobacco archives)

Santa Barbara (Cylinder collection)

Santa Cruz (Omeka collections)

(May 30 deadline for finalizing mappings!)

What now?

• “Deep harvest” and display from DAMS

• Workflow to Merritt via DAMS

• DAMS upload client

Calisphere Beta is coming!

Soft Launch: June 30ish

On the web, but not in GoogleCommunity Q/A: help us find bugs!

Public Release: August 31ish

Open for end usersOpen to crawlers

http://bit.ly/UCLDC

http://bit.ly/UCLDC

seeking your help on…

• Data review: campus / units / collections

• Soft launch Q/A: reporting bugs

• Minimum viable product?

STATS!

they’re kind of complicated. but not this complicated.

2 kinds of stats

1. Extent (how much stuff?)

2. Usage (how much + what kind of access?)

Extent

• Megabytes, etc.

• For DAMS users:We can provide these on requestIn the future, more self-serve

Questions / concerns? Let us know.

Usage: what happens now

• You create Google Analytics profile and give us the code

• We put the code on your objects

• Same report for OAC and Calisphere stuff

• Could also have your other library site stats

Some questions for you

Why do you want them?

• Schedule F

• Other reporting, maybe internally?

• Decision-making?

Tell us more.

What data do you want?

• On what content?

• On what actions?

Tell us more.

How do you want the report?

• Google Analytics OK?

• How do you want them sliced?e.g. Campus

Unit/departmentCollection

• Together or separately with other stats?

Tell us more.

A Proposal

1. Google Analytics on your objects

2. Code applied at the unit level (as defined in UCLDC Registry)—but no finer.

A Proposal

• Could have one campus report (apply same code to all campus units)

• Could have different reports for different units

• Could not have different reports for “sub-units” or any units not defined in Registry

A Proposal

1. Google Analytics on your objects

2. Code applied at the unit level (as defined in UCLDC Registry)—but no finer.

A Proposal

1. Google Analytics on your objects

2. Code applied at the unit level (as defined in UCLDC Registry)—but no finer.

3. Within the report, ability to filter by collection

So…

Does this plan make sense to you?

What concerns do you have?

Who else should we consult with?

Known Issues with GA

• Technically heavy

• Nothing retrospective

• A strain on documentation

• A learning curve for you

In the future…

Store all the logs

Search them later, on the fly

Simpler reports, change as your

needs do