Library IT News

It would be nice to have a single stat module/client that can track the round trip usage. I am not sure what level of detail GA can provide: Does it track pdf/html download? Most vendors already provide COUNTER statistics (http://www.projectcounter.org/) which is institutions specific and suppose to be a standard. I doubt the vendors will be willing to consider GA as there are pressure from the library world to be COUNTER compliant. There are some ongoing efforts with SUSHI (http://www.niso.org/workrooms/sushi), the client/protocol part for the statistics. The idea is to create client software that will grab the COUNTER data quickly and easily from the vendor sites.

You have to do special configuration to get it to track the download of non-html content by putting an onclick event on the link to each dowloaded file you want tracked and by making sure the tracking software is called in the header, not the footer. Archives has implemented this to a large extent, and I can saw it would be a challenge to set it up library wide and ensure all pages/conent are being tracked. Also, if you are going to do use GA, you need to be very careful, since unless special permission is received from campus, using a tracking technology like this violates Illinois privacy law. I had to secure special permission from Sally Jackson, and placed a privacy notice here, which was approved for Archives use by campus: http://www.library.illinois.edu/archives/about/privacy.php

Chris, We (Web Content Working Group) thought it would be best to develop a policy amendment to encompass the use of GA as well, if we go this route. Of course, I do find it odd that the main campus web site (illinois.edu) is using GA right now, and the only privacy policy they link to (with no mention of GA by name, or reference to the type of tracking they are using it to engage in) is the generic one. Take a look at the illinois.edu page source (for the GA code) then look for anything that explains its use to the user. :P Of course, we already figured even if, for some odd reason, use of GA was considered to be within the scope of the blanket web privacy policy, we'd come up with our own anyway. And thank you for considering the implications of GA use on your site. I know we have at least a handful of units (maybe two handfuls) that dove right in to using GA without considering the privacy implications. I knew that there would be extra hurdles to overcome if we want to really track all document types (anything that isn't html, or can't at least include a snippet of JS, would need it). The took exhaustive notes from the two day ARL workshop I attended on GA, and really pressed the presenter on a lot of these gotchas, and he pointed me to some clever (if not easily implemented) potential workarounds. I see a client based tracking system like this as a good complement to, and not a replacement for, traditional web log analysis. But I do see a great benefit in getting a more consistent, nearly real time, easily malleable set of user data to give us some more insight into how our users are traversing our sites, which pages they tend to bounce out of our sites from, which they stay on for some deal of time, which are really blind alleys that people travel 4-5 clicks down, only to immediately backtrack 5 clicks to take a different route, etc. A lot of this data _can_ be teased out of transitional web logs, but GA just makes it so darn easy! :)