Experiences hacking GA event tracking
Last month we started using event tracking in Google Analytics (henceforth forever called GA). Should have started years ago but as they say - better late than never. Thought it might be a good idea to share a few things that we learned.
1. Have clear goals
We have a pretty high bounce rate so we wanted to understand what people are clicking on to see how we could make the product more engaging. The second goal was to track which content categories get how much traffic. Believe it or not, we weren’t tracking pageviews by content category. With so many content categories, each with their own super- or sub-categories, it’s important to know where you’re lagging and where you’re doing well.
2. Learn from others
It’s weird but it was impossible to research GA hacking without running into Cardinal Path. We thought Wikia has many content categories so their GA implementation would probably be a good model. So we set out to find where the magic happened and ran into Cardinal.
3. How event tracking actually works
Geek out on this StackOverflow thread to explore how GA event tracking actually works. If you’re tracking a click on a page, the browser probably doesn’t give GA enough time to send its GIF request with the payload to the server. It’s possible the browser opens your link before GA’s Javascript gets a chance to do its thing. (UNLESS ga.js introduces some sort of document.unload handler which finishes all GA tracking before allowing the original document to unload and the new page to load. That would be cool for tracking purposes but totally UNcool for our users. Given a choice between making the site experience faster for users and tracking their clicks, we’d choose our users every single time. Even if you wake us up at 4am to ask. Fortunately, it seems that GA does not force an unload handler on the original document.)
4. Use onMouseDown
So how to handle scenarios where the browser is too fast for ga.js? That’s where we ran into Cardinal Path again with this awesome blog post about onClick vs onMouseDown when using event tracking. Most examples for GA event tracking will show you code like
<a href=“/wherever” onClick=“_gaq.push([’_trackEvent’,category,action,label]);”>click me!</a>
But you can increase the probability that clicks will be tracked if you fire your GA event onMouseDown rather than onClick.
5. Page-level custom variables are useless. Use events instead
At first we tried using page-level custom variables for tracking what content categories are most popular. So for example when a visitor gets to the MacBook Air vs. Pro comparison, we want to track a hit for all the categories in the breadcrumbs. The top-level category is Technology and the second level is Consumer Electronics. We assigned the first custom variable for the top-level category, the second custom var for the 2nd level category and so on. But we wanted to do all this tracking after page load i.e. in $(window).load(function(){…});. But for it to work correctly you need to set your custom vars before GA’s trackPageview call. That’s a major difference between using custom vars and event tracking.
trackEvent fires a request to the big G’s servers immediately but setCustomVar waits until some other function fires a request and piggybacks on that to send its data back to the mother ship. In most cases no other events would be fired so we wouldn’t be able to accurately track custom variables.
Enter event tracking for content categories. We now track each category of the bread crumb as an event where:
- The event category is hard-coded to ‘PopularCategories’
- The event action is the content category in the breadcrumb. (one event for each item in the breadcrumb.)
- The event label is the page that the visitor is on.
The event label is interesting because apparently it’s not needed. GA’s web interface gives you the ability to use the Page Title as the primary dimension when viewing data for a particular Event Action. We didn’t know that so we tracked the page ourselves in the label. What’s interesting is that the numbers we see via the Labels breakdown are different from what GA shows when it breaks them down by page title. We’re still not sure why that is. It’s not a huge discrepancy but it’s not teenie tiny either.
So there you have it. That’s how we implemented GA event tracking.
UPDATE: CardinalPath has released an open-source project GAS (Google Analytics on Steroids) that looks very promising.