At work (how do librarians say it? MPOW?) we use Google Analytics extensively to analyze the behavior of web sites and the people who use them. I had a call this morning about applying the same tools to library web sites, and it made me start to think about a bunch of stuff that I had been noodling around about but not actually writing up.
There's at least two ways to use analytics tools to help the process of making a better system. One is to understand your user population better, so that you can provide them with things that they are finding you for that they're not finding on your site; the second is to test and refine the process by which people complete specific tasks that you want them to complete.
Understanding what people do when they get to your web site goes by many names in many closely related fields, depending on what part of the world you live in. (Some acronyms, for style: UX, UXD, HCI, interactive design, perhaps some IA in the mix). From an analytics point of view, there are lots of things you can figure out, but some primary ones I'd guess from a library web site would be simple things like
- how many people are coming to my site
- what pages are they viewing
- how long do they stay on those pages before moving on
- how frequently do they give up on the site entirely
- what search terms are they using to find me
- what geographical area are they coming from
These reports and more are in the standard set of analytical tools that Google Analytics provides right off the bat, and they provide good aggregate information that you can watch over time.
The second slice of the analytics pie is task completion. As a web designer, you set a goal of some task you know that people are trying to do at your site, and create the path ("funnel") of events that lead up to that goal. (e.g. the goal might be to register for a class, and first you have to hit three pages that let you look at class listings, select a class, confirm a time, and get a thank you note). You configure this path through the system as a goal, and then you can track which % of visitors complete that goal and which if any of those completion paths come unusually from particular search terms, referral sites, or the like. You might answer questions like
- How many people registering for story time give up before they click OK
- When someone reserves a book on line, do they get it from search or browsing?
- How many people give up in the middle of the "contact us" form?
- When someone types "hours" into the search box, do they find our hours page?
Measurements like these are practical if and when you have a flexible enough system to actually make changes to improve the results, and when you have enough results to make a difference. Depending on the organization, it may mean that you work on the "web site" part of your system first or earlier, leaving the "catalog" part of your site in the special circle of the 198x version of design that it came in on.
Depending on which state or country you live in, patron browser behavior on some parts of your library web site may be transactions that are protected by law with specific privacy and data retention requirements. Implement with care.