Part 2: The pros and cons of Event Tracking by Lukas Oldenburg

One of the best things about In-Page Analytics was that you don’t need to add any code to your page or alter your links. With Event Tracking or Virtual Pageviews though, there is no way around some additional coding.

Event Tracking or Virtual Pageviews?
So what’s the difference between Event Tracking and Virtual Pageviews again? To make a long story short: With Virtual Pageviews, you can track Pageviews for “virtual” URLs (you can decide their name), even though there is no real pageview. For example, anytime someone clicks a link on a teaser, you can tell Google Analytics to record a virtual pageview like “/teaser-click-to-url-x”.

Almost the same happens with Event Tracking. To stick with our example, when somebody clicks on a teaser link, you can tell Google Analytics to track this as an Event. The major difference is that Event Tracking doesn’t create fictional Pageviews and thus doesn’t inflate your Pageview-based data. Imagine that every click on every teaser on your homepage was tracked as an additional Pageview. That would skew your data a lot because it also has a major impact on other data like Bounce and Exit Rate, Pageviews per Visit etc…

I prefer Event Tracking
That is the main reason why I do not use Virtual Pageviews for this purpose. Be aware though that Event Tracking can also skew your bounce rate and Time on Site/Page metrics, for example when you use it to track outbound links (usually bounces). Luckily, Google Analytics has recently published a way to work around this with “Non-Interaction Events”.

Technical Implementation of Event Tracking
There are several ways to technically implement Event Tracking. The easiest way to start with, but also the most tedious and error-prone, is telling your editors to add a Javascript onclick event handler to every link like this:
Link

If you have only a few links to track and technically prone editors, this might be a viable way. In other cases, you can do the following:

1. Let your Content Management System assign a special class to each teaser link.
   For example, every teaser link gets a class of “teaser”:
   Link

2. Put additional Javascript at the bottom of your page.
   The script we are using creates an Event Listener (not an Event Handler!) for a click event that looks for all links with a class of “teaser”. In English: Every time someone clicks on a link with the class of “teaser”, we let Google Analytics track an event. Depending on your page and CMS, your script might look a little different. The script also uses jQuery, so you need to load jQuery in your page as well.

The script allows you to track every teaser link without adding anything but a class to your links. If you know a little Javascript, you’ll even find methods to identify teaser links without having to add an extra class (for example by identifying them as all links in a div container with the id of “teaser-box” or whatever your website uses).

What the script above does:

• Every click gets tracked as an Event like this:
• Category: Teaser
• Action: Click
• Label: from {current page} to {destination page}
• (Feel free to change the naming logic according to your Event Tracking hierarchy.)
• The script follows the link with a delay of 100 milliseconds to make sure the Event does indeed get sent to Google Analytics before the click causes the visitor to leave the page (in that case, the request to Google Analytics would be aborted). If you do not want this, just delete “event.preventDefault();” and “setTimeout(‘document.location = “‘ + this + ‘”‘, 100)”. Most clicks get tracked anyway.

As you can see in the next screenshot, this allows some insightful analysis (my exmple is in German, so the “from – to” becomes “von – zu”). For instance, you can now sort by “from {your homepage URL}” to get all the links on your homepage, or you sort by “to {destination page}” to see which teaser page did the best job in bringing people to that page.

Another great thing about this is that you can export this data (unlike with In-Page Analytics) via the Google Analytics API to Excel (we use “AutomateAnalytics” Excel functions for fetching GA data) or other places.

Say you want to see which on- or off-site campaign brought how much traffic to which of your new articles. With this Event Tracking script, you can end up with a neat table that displays the Pageviews generated by your newsletter right next to the clicks generated by your homepage teasers (see next screenshot for an example). Note that Events and Pageviews will overlap though, because a person that has arrived at your article via your newsletter might well go to your homepage and click on the teaser to the same article again.

The Pros and Cons of Event Tracking for on-site campaign tracking:

Pros:

1. Clean Data
   Event Tracking is my favourite way of tracking teaser links because it keeps your Pageview-based reports and your URLs clean (not the case with URL parameters that specify the referrer). And your Event Tracking Data will never be messed up by Pageview data. It lets Pageviews be tracked by Pageviews, and Events as Events.
2. No additional effort for your editors (if you implement the script above)
   They can keep working as they used to.
3. Historical data available
   That was a big minus of In-Page Analytics.
4. Data is easily exportable for further analysis in other tools
   You can use all the export functions Google Analytics offers and access the data via the API.
5. No problems with outbound or subdomain links
   Another big minus of In-Page Analytics.
6. You’re really counting clicks
   In In-Page Analytics, what you are seeing are not really clicks. The fact that In-Page Analytics shows you a click from page A to page B is actually being inferred from the fact that the pageview before page B was page A (see more on that in the first post of this series). With Event Tracking, you are only counting real clicks.
7. No problem with non-static content
   Visitors to your site get to see different teasers depending on whether they are logged in or not? Your teasers or banners are rotating every other hour? An absolute killer for In-Page Analytics, but no problem for Event Tracking.

Cons:

1. You need an Event Tracking Concept
   How do we name the “Event Categories”? What teaser categories are we going to need? How should the “Event Label” be constructed? All these questions and more have to be answered if you don’t want to end up with a dumpster full of unstructured data.
2. Small additional IT effort
   Usually, the only thing you need is to include the script above, add a class to your teaser links (there may of course be other ways to identify teaser links) and maybe modify the script a little bit so it fits your Event naming logic. It shouldn’t take your IT more than an hour or two to do that. Since the script uses Event Listeners instead of Event Handlers (“onclick” attributes on links), you can put it on any page without conflicting with other click events that may be triggered when clicking on these links.
3. No (easy) visualization possible
   That was the biggest pro of In-Page Analytics.
4. “Right-click and open in a New Tab” is not counted as a click
   This can be a big minus when your page structure encourages users to open links in new tabs. That can be the case when you have a lot of links, and users first open several of them in new tabs before reading them. You can manipulate your script to also include right-clicks, but this is not recommended since there are heavy browser issues (Macs don’t have a “right click” and so on) and it is generally seen as obtrusive Javascript (save for some exceptions) to force the browser to do anything else but display the context menu when right-clicking.In any case, “contra” 4 (only clicks count) and “pro” 6 (no right-clicks) usually cause your Event Tracking numbers to be lower than those of your In-Page Analytics (but closer to the truth). To give you an example: 21, 26 and 33 clicks for three links via Event Tracking (without the 100 millisecond delay) gave me 28, 36, and 47 in In-Page Analytics. The tendencies are the same, though, so no worries here.
5. No easy way to connect Events to Conversions
   Unlike with In-Page Analytics, there’s no way to link Events to Conversion Metrics (for questions like “Did Visitors that clicked on Teaser x also register?”), at least not in Custom Reports. With the API, you can help yourself with on-the-fly-segments for every event label you want to analyze the conversions for. That can be tedious, and the queries take a while.So if your main goal is to link your on-site campaign clicks to conversions, you may want to use Virtual Pageviews or other URL-related methods. If you only want to compare clicks (which satisfies most editors) to get better at identifying the best content and position for your teasers, Event Tracking should do the job.

   If the Event itself is a goal, Google Analytics now also allows Events to be counted as Conversions, but that won’t help you here because the click on an on-site campaign link is usually not a conversion yet.

Conclusion:
Event Tracking requires a little bit of coding up front, doesn’t have the visual appeal of In-Page Analytics and is harder to connect to conversion metrics, but it is a very clean and manageable way to analyze your on-site campaigns. That is also why, in most cases, it is better suited than Virtual Pageviews.

It is also a very good alternative or addition to In-Page Analytics: It works no matter if your page has mostly static, dynamic or rapidly changing content, you can access historical data at any time, and you can export it for more nasty things in Excel & Co.

Lukas Oldenburg is a featured blogger for Web Analytics World, you can read his latest articles here

Online Competitor Analysis