Event tracking in Google Analytics
This is a short guide on putting together a simple-yet-powerful script for tracking custom events in Google Analytics. Whilst there is already a ton of information on the web about Google Analytics and what you can achieve with it, this blog entry is aimed at devs who want to get going quickly with event tracking.
If you’re completely new to Google Analytics, your best bet is to at least read the Google introduction. They also provide documentation to give an overview on Event Tracking.
The rest of this post assumes that you are familiar enough with GA to know about the ga() function and how it can be used to send events.
Note: Google Analytics doesn’t require jQuery, but the examples in this blog do use jQuery for setting up events. It is also assumed you are using the new version of Google Analytics, analytics.js.
You’ll need the Google Analytics script defined in your page. If you haven’t done this yet, Google have got you covered.
If using ASP.NET MVC, it’s a good idea to have this in its own view that you can cache the output of. You can also use a configuration setting to determine whether to output the script at all, to avoid enabling Google Analytics on development / test servers, or perhaps to use a different ID in those environments.
Simply adding this script will get page views tracking in Google Analytics.
The following is a skeleton script that you can then expand on:
Typically, once this script has been loaded, then, at a suitable point in your site’s code (e.g. after page load), you can call
mysite.analytics.init(); to execute the code and setup your events.
If the Google Analytics script hasn’t been added to the page, this script checks to see if there is a
ga_debug variable defined. If there is and its value is truthy, the script creates a dummy ga() function that simply logs to the console. This is useful for testing your analytics events without needing a real GA account in place. If the debug value isn’t in place, this script simply doesn’t go any further.
Let’s look at some of the events you could create.
First of all, a good piece of advice is to keep your event definitions generic where you can.
Rather than tracking every interaction individually on your site, try to logically group the different types of interaction together and then come up with a method of selecting these elements. This is especially important where you are building a CMS-driven site and the HTML will be generated on the server.
Whilst this will track both of the links, it is time consuming to implement, and you’re going to need to expand your analytics script every time you add a new link to the site.
How about this instead?
If you prefer, you can use a
class selector instead, though using data- attributes helps to keep the classes of your elements simply for styling. You can even drop this method and go for any* click on a link using the
a selector, though this is rather indiscriminate. It’s up to you ultimately on what you’re interested in tracking.
The message here though is to try to group the interactions where you can, so your tracking code can be simpler. There are, of course, times where you will want to track specific events that only occur in single places on your site, and that’s ok.
Now let’s look at some examples of events you can track.
Use this to track when a user clicks on an email link.
|Link Clicked||[email protected]|
If you have social media “Share” links that you executing as part of JS, you could also track them through GA events.
Similar to the example above, a generic link tracking. This however also includes the text of the link, which could prove useful in determining which buttons on your site are resulting in the most clicks.
|Button||Clicked||View products -> /products|
This is useful if you have some top-level header navigation that contains links, and you want to track the level of user interaction with these specific links.
If you have a footer, you can apply the same principle but using a separate data element, for example
|Header||Link Clicked||Products -> /products|
You don’t need to restrict your interaction tracking to just page links on the site. You may already have events setup on your site for particular types of functionality, for example a “Show More” button that reveals some hidden content on the page:
You may be interested in tracking how many users are actually revealing that content. If you want to do this, don’t edit the previously defined event code that implements the reveal; it’s perfectly fine to have multiple events trigger when a button is clicked, and it is much neater to keep your analytics tracking code together in one place. Instead, you can just add another event:
The tiny inefficiency here of multiple events is worth it to keep this code much more maintainable.
A simple page-load isn’t really enough to determine how much of your website a user is actually seeing when they visit. For example, are they just viewing the page and immediately leaving, or are they actually scrolling down to see more content? How many of your users do this?
To help capture this sort of information, you can track when and how far a user scrolls on a page. Whilst you can write this code yourself, there is already a small JS library that wraps up the functionality for you - Scroll Depth.
By default, Scroll Depth tracks events for the percentage a user scrolls down the page - firing events at 25%, 50%, 75% and 100%. However, as well as customizing these percentages, you can also specify the IDs of elements on your page and it will fire tracking events when a user scrolls far enough down for that element to become visible. That’s great, as it tells you how many users are actually seeing a specific part of the page you have designed.
Once the script has been included, a typical way to invoke this library would be:
Using the above skeleton script as an example, the ideal place to execute this would be straight after
_setTrackingEvents is called.