Tag Archives: analytics

Mouseflow Review

Posted on by

Mouseflow heat mapOMG, have you seen Mouseflow yet? It’s my new favorite analytics tool.

I have bragging rights to click analytics at my institution. After seeing Tabatha Farney’s presentation on click analytics at LITA a few years ago, the first thing I did was purchase a subscription to Crazy Egg and began using click analytics as a central part of my user analysis. After giving a presentation to the data managers group on my campus, many others, including our marketing department also got interested and now they’ve come back to me with a new tool: Mouseflow.

Mouseflow is basically a better mouse trap to Crazy Egg. It does all of the heat maps, scroll-maps and in-page analysis you get with Crazy Egg, but it adds on top of this recordings of actual mouse movement on your website(s). That’s right, as creepy as it sounds, you can place the code onto your web pages and then watch actual videos of users’ mouse pointers as they move across the screen, stumble over trouble areas and click through from page to page.

I ran this on our research guides for a day to test the tool. The result were dozens of recordings of actual user sessions on our research guides. It’s as if you’re sitting behind someone and watching their movement around your site. You get to see where they pause, where they click, how long it takes for them to decide where to go and even watch them try, fail and fail and then either succeed or give up. You can even tell by the movement of the user mouse (often) where they have stopped to read or where they are lost.

It’s fascinating. It’s powerful. It’s possibly a violation of privacy (more on that in a second).

On the back-end, Mouseflow lets you filter by IP range (good for filtering out your staff) and control several parameters to improve your data quality. And you have varying account levels so you can find one that fits your needs and budget. With a paid account, you can download your most telling videos.

It’s truly remarkable for analyzing your site architecture, designs, content. And you don’t need to recruit users for a formal study. But your IRB might still have some concerns as might any regulators or other privacy advocates who might be minding your store. So you’ll (and we’ll) have to do a little due diligence before we roll this out.

Still, Mouseflow does allow you to NOT capture IP information, adding another layer of anonymity to your data. So on the surface, it does seem to be something you could probably use without violating FERPA…except for one thing: I’ve heard it records what is typed into forms (visually), which was the primary reason our marketing was interested in Mouseflow. I didn’t see this as our research guides have displayed:none the internal search boxes in LibGuides. But this could definitely complicate the approval process.

So, check it out. The first 100 recordings are free!

Best Practices for Google Analytics Profiles and Filters

Posted on by

Recently, I heard from a colleague at another institution regarding how to best configure their Google Analytics profiles, especially in regards to filters.

A Google Analytics profile is a view into one of your web properties with specific sets of filters applied to it. For example, one profile I keep of the university library website which I manage filters out everyone except those users coming through an IP range that is used by our wireless users. This profile, then, let’s me see how our wireless users differ from our lab computer users. It’s particularly important, in fact, because it turns out that the browser and OS choices our wireless users make are very different from what our campus IT provides on the lab PC images (Apple vs. Microsoft, Google Chrome vs. IE and Firefox).

The most important best practice for profiles is to always have multiple profiles. You should always have one profile that has absolutely no filters so that if your data ever looks weird you can see right away if it’s your filters causing problems. So, we have one profile without any filters and then multiple profiles that have various other filters applied. For example, for my main analytics report profile, I have the following filters applied:

  • Filter Name: Case sensitive; Filter Type: Lowercase – Remove
  • Filter Name: LibraryIPfilterout (our IP filter); Filter Type: Exclude – Remove (this filter excludes library staff machines from our data)

Here’s how you create a filter:

  1. Go to Google Analytics, and select the Admin tab on the right of the orange bar
  2. On the Account Administration screen, you’ll see a list of accounts (one should be your library site’s account) – select it
  3. On the account’s page, you’ll see your properties (which should include your main website’s URL). You’ll also see a Filters tab – select that
  4. You should now see a list of all filters applied to that web site account. You will also see a “+ New Filter” button. Click that.
  5. You will then need to fill in the parameters of your filter and then Save it.
  6. Once created, it can be applied to any profile. Simply go back to Step 3 and select the URL you want to create your profile for.
  7. Select “+ New Profile” and create this profile
  8. Then locate the Filters tab and apply any filters that you want, including the one you created.

Library IT Project Management Application Now Available

Posted on by

Howdy all! Sorry for the hiatus…just looking at my last post, it’s been 4 months since I posted anything. I suppose that gets pretty close to a closed blog. 🙂

Anyway, things have been extremely busy here with multiple major projects from migrating our website, launching WorldCat Local and lots and lots of experiments with Campus Guides, Drupal, SharePoint and beyond.

But I wanted to let everyone know that I published our Library IT Project Management Application on Zoho yesterday, making it free to the library community, and anyone else out there.

The application is available in the Zoho Marketplace for free!

This ticketing application was developed by my Web Services Team for project management. The application has the following features:

  • Task Request form for external teams to submit to Library IT
  • Task Assignment for Library IT lead to assign to staff
  • Views of tasks and projects by status
  • Email to initiators throughout task life cycle as task status changes
  • Request for review action to allow Library IT lead to review draft work before committing project to production.
  • Rich reports and statistics on tasks

The application uses system-generated emails (like the emails received from task requesters and the Zoho administrator). So there’s no real configuration required. And there’s lots of ways you could develop this further…so have at it…and let me know how you like it!

PS: My presentation on this application, which includes more details on its functionality was given at Code4Lib Midwest 2012. You can view the presentation on my Selected Works site.

Library Who Dunnit

Posted on by

The joke lately at my library is that our website just doesn’t matter anymore. Today, I saw this sentiment come alive in our analytics data.

As you can see from the graph below, we have a typical academic usage pattern, with activity building up during a quarter, peaking just before finals and then crashing as students rush off on their inter-quarterly wanderings.

What was interesting in this last quarter’s data was that this activity failed to build to its usual tempo. In fact, it appeared to build and then flatten out.

The culprit? I think this is our hosted research help portal, LibGuides, which we just soft-launched in the middle of the quarter…about the very time student research needs start to draw them to the library. Pre-LibGuides, we would see alot of traffic to our locally-hosted Subject Guides, which would show up in our analytics data. But LibGuides, which is replacing these Subject Guides, is off the radar as far as Google Analytics is concerned (for now), so this may be why we saw such low numbers.

Anyway, with WorldCat Local configuration almost complete and LibGuides readying for a hard launch in Fall, the library web site will likely see even further erosion in usage. And this is a very good thing, because it means we’ve gotten all the other stuff out of the way, improved the signal to noise ratio and just simplified the act of accessing our resources (which are also all off-site and out in the cloud).

That’s what they call usability folks!

Don’t Forget the Long Tail!

Posted on by

First, off sorry for the hiatus of late…been busy prepping various library sites for a major migration to SharePoint…more on that soon…

Meanwhile, as part of this migration, I’ve been pouring over analytics data to fathom what on earth our users are doing, what’s popular, what’s not.

And then this morning, as I executed my usual Sunday morning web wanderings, I stumbled upon another user interface redesign based on analytics when I noticed that the RSS icon on Firefox 4 was missing. This led me to discover that this was baked in by Mozilla:

Why Firefox 4 abandoned the RSS icon and how to get it back – Tech Products & Geek News | Geek.com.

Apparently, Mozilla was also looking at user data and noted that less than 3% of users were using the RSS feed icon, which if you know how to use it, allows you to subscribe to feeds from web sites you like (blogs, news, etc.). And if you don’t know how to use it, you get a really bad user experience.

Well, I definitely fit into this 3% that actively used the RSS icon. And luckily, there are add-0ns for everything with Firefox, like one that puts the RSS back into FF4, so no real issue here. But it does remind us info architects that users come in many flavors and we ignore the minority at our peril.

Fortunately, Mozilla’s development model, accommodates everybody by offering add-ons to their browser platform, so no harm done. But for the rest of us, locked into less elegant platforms, don’t forget the long tail!

Better Living Through Good Data, Part 2

Posted on by

Crazy Egg confetti view with cookie variable filtersA few months ago, I blogged about a cookie-based filter I deployed to screen out librarian machines from my library’s Google Analytics and Crazy Egg data. Well, after running this experiment for awhile, it looks like our IP data was actually good enough after all.

The original problem that sparked this experiment was that the computers in our library were all on dynamic IPs and thus, we could not reliably screen those machines out in order to get a pure glimpse into what non-librarians thought was important. A few options were considered, such as putting all library machines on static IPs. The university IT department didn’t like that idea, so I had to go back to the drawing table…or baking table, if you will.

The solution was to deploy a browser cookie on each machine used by staff, which Google and Crazy Egg would then use to identify the librarians visiting various library pages. The added bonus was that we could actually see which web elements and pages were mostly used by staff and which ones were mostly used by others.

Problem is, deploying the cookie across the staff computers was a real hassle: each computer might have multiple users, like the Reference computers, which required going around chasing down librarians (not an easy task!) and having them log into each computer, launch each browser and change their default homepage to our cookie page (which sets the cookie and then refreshed to the library homepage). In some areas, there might be ten or more people using a single computer.

Needless to say, the pay off for all this work had to be really good.

And as it turned out, it out, the IP range filters were not all that different from the cookie-filtered data.

In Google Analytics, we set up multiple views, one with no filters, one with a cookie filter and one with an IP range filter. We let the data come in for two months and then checked the results to see what the discrepancies were.

What we found was actually surprising. The IP filters were doing a pretty good job…in fact, they were doing too good of a job. It appears that the IP range covers the librarians, but also many of the public machines in our computer labs and elsewhere. This isn’t too bad, since users working at home are very likely not librarians…so, we essentially have our librarians out of our data using the IP ranges.

And statistically, the IP ranges were only a few percentage points off the cookie filters, so the differences were fairly benign.

For example, on Saturday March 5, 2011, we had a total of 6,751 people come to our library homepage. Of those, 49 people were librarians according to our pretty much perfect cookie-filtered data. The IP filters identified 131 users as librarians because it counted some computers used by students in the labs. Doing a little math: we found an average 1.5% difference between the two filters. Not siginificant enough to worry about…especially given how onerous deploying and monitoring the cookie was.

Better Living Through Good Data

Posted on by

Coming onboard at my library a few months ago, I immediately went to Google Analytics to get the details on exactly what this online beast I had inherited was all about. As I later surmised, the data I was getting from Google was likely not all that reliable.

Google Analytics measures invaluable data points like the number of users coming to the site, where they came from, with what computer arrangements they came and what exactly they were doing and for how long.

To get myself a better view of these users, I started off right away by creating some funnels to track likely navigation scenarios, for example, tracking how many people that landed on the home page followed the quickest path to the library hours page. And if they went another route, how did they get there.

To some, this may sound boring, but its crucial knowledge when your aim is to improve usability and functionality on a site.

Crazy Egg confetti view with cookie variable filters

Not long after setting up my funnel reports, I was at the LITA conference, a forum populated by like-minded web librarians, where Tabatha Farney reviewed (and made the case for) click analytics. This kind of data, fills in some areas Google doesn’t do all that well, namely to visualize user clicks on your website through confetti views (right) or heat maps.

Talk about an ah-ha-moment! My first order of business when I got back to the library was to get me some click analytics. I went with Crazy Egg. Then, sitting back, I let the magic happen and was soon able to review Google data and click analytics  without holding a single user interview!

All this sounds wonderful, except that I soon learned that our librarian staff computers were using dynamic IPs…egad! This meant that the nice little filters in our Google Analytics reports were likely not filtering out 100% of our librarians. How many librarians were getting through is a question that remains unknown, but I hope to know soon.

I thought long and hard on this muddying of my otherwise pristine view into my users and then it occurred to me that I might be able to deploy a browser cookie on our staff computers that could be used to filter out the librarians. As it turned out, I could.

Doing a little research, I found that others had had similar problems with dynamic IPs and the solution was already worked out, and to my ego’s satisfaction, the method used was the very cookie-based solution I had come up with (pat on the back).

  1. post a new page on your server with a little javascript to plant the cookie on any browser that visits that page
  2. put some more javascript on my site to check for the cookie and talk to Google Analytics
  3. inside Google Analytics, add a custom filter to disregard any users with the cookie

Of course, all good things go to waste until you get a student worker. And so, this solution sat idle for a couple months while I managed the other gazillion projects that were falling like hail over my desk. All of this changed, when I got the green light to hire a computer science student to help out. So the cookie filter project was back on.

To help test the reliability of this method, we created a couple instances of Google Analytics, one with no filters, one with the old IP filter and one with the new cookie filter.

On the Crazy Egg side, things looked a little less plug-and-play. But then, as if the Cosmic Cactus wanted to signal that it really does care (if only a little prickly), I got a Crazy Egg email announcing a new custom variable feature. This worked quite nicely, although, the variable feature cannot be utilized with some Crazy Egg reports, like my favorite, the Heat Map. Still, with a little tinkering, we were able to deploy another cookie filter to work with Crazy Egg.

Proof’s in the pudding, and as pudding requires a little time to set up in the cooler, we’re eager to see how our data looks once we get this running. Tomorrow, I’m announcing the cookie solution to the library staff and hope to start getting all staff computers cookied so we can let the filters do their work.