Tag Archives: crazy egg

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!

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.

SharePoint Migration

Posted on by

At long last, my university IT Department is gearing up to initiate campus-wide migration of all websites to SharePoint. This includes the library’s website.

Say what? SharePoint for a public-facing library website?

I’ll admit, I was fairly incredulous about this concept and continue to wonder how it will play out. This is a Microsoft product after all. But the experimental nature of the idea intrigues me, and I’m actually looking forward to it. Alot of this excitement, of course, also arises from our current CMS conundrum. You see, we’re on Serena Collage, perhaps one of the clunkiest content management systems still in operation…In fact, that’s the problem, it’s not really supported anymore. Fact is, it often doesn’t work at all.

So, I’m excited about getting out of Collage. And, I’m coming around to SharePoint as well…kind of.

Much of my remaining hesitation stems from not knowing how this will all work. Case in point, my team currently has access to the server, where we can do a fair amount of development, despite Collage’s problems. It remains unclear exactly how much access to the server we will have in the future to do the kinds of web service development that we’re accustomed to.

But, let’s focus on what is known…and it’s much to be happy about. SharePoint has a pretty good governance structure to it, which will allow our library to assign sections of the site to curators responsible for keeping information up to date, while allowing me to keep on top of what they’re doing. There are other features that I’m extremely happy about:

  • multiple instance of blogs
  • on-the-fly database creation
  • intranet capabilities

Another cool aspect of this migration is that, as far as I can tell, no other library has used SharePoint as its public site’s CMS. Think journal articles and presentations here. I like that…

So, as you can imagine, there is quite a bit of activity at the library right now. We’ve got until the summer before the migration begins. In the meantime, I’m working on cleaning up our site as much as possible so that we get rid of the clutter and worst usability issues. My sense is that once we begin working with IT, there won’t be much bandwidth for working out a whole new architecture. I’ll have to come back to that later on my own. But I am using some Google Analytics and Crazy Egg data to help re-architect some areas of the site, particularly the unwieldy Special Collections areas ahead of the migration…as sort of site weeding if you will.

As such, my plan post migration is to do immediate user testing, followed up by iteration, more testing and then iteration. We’ll keep that up until we get where we need to be.

Along the way, I plan on keeping a few channels open to our stakeholders, essentially following the model established by the North Carolina State University’s Library redesign project…namely by creating a Web Advisory Committee composed of librarians from across our organization, focused librarian interview sessions and also through a public blog aimed at the university stakeholders. But I’ll also add commentary here when appropriate.

Wish us luck!

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.