Google Analytics and the library web site and catalog

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.

Technorati Tags: analytics, library

Comments

[Thane]

I'm just wondering if it would be easier to just do usability testing. Research indicates that 5 users, given specific tasks, can reveal enough information on the usability of a site to make conclusions about a site (see Jakob Nielsen's work for more information). It can also provide more qualitative information than simply tracking user's behaviour on a site. Properly done research also avoids problems with privacy legislation etc.

Knowing that 50% of people don't actually complete registration for Storytime (the data retrieved from something like Google Analytics) seems to be less valuable than knowing that users don't complete the task because there are too many boxes to fill in or the form doesn't display properly in certain browsers (this would be the type of data that can be retrieved from usability testing).

Anyway, these are just some thoughts. I would be curious to know What do other people think and whether or not they're conducting usability testing on their library's website before making it public????

[Brad Dennis]

I agree with Thane, however, the best solution is to triangulate or use both Google Analytics and usability studies. Using the storytime registration example, it is true that from Google Analytics you may be able to collect data suggesting that 50% of customers are not completing registration. A debriefing/interview session after the usability study may indicate why they are not completing registration.

While it may seem that quantitative data is not as helpful as it could be, I find that often it is more helpful than I anticipated in making data driven decisions. Again using the storytime registration example: How many customers were not able to complete the registration, 5 or 50? This makes a huge difference and it is data that cannot be gleaned from usability studies.

In my opinion, using data gleaned from Google Analytics then analysis to determine what you want to examine in depth through usability studies or focus groups is the best option. To answer Thane's question, we did conduct usability testing on the library website before and after making it public and we are also using Google Analytics at Western Michigan University Libraries.