That may sound surprising, and even counter-intuitive, but for a certain percentage of your users, your Analytics implementation is breaking your website.
Take this example, which is the standard way of tracking outbound links as described in the official Google Analytics documentation:
The problem with this implementation is that a certain percentage of your users will never navigate away from your page: clicking on the outbound link will have absolutely no effect.
Some users take their privacy to heart, and use extensions to prevent tracking of their online activities (such as Ghostery, AdBlock Plus, NoScript or uBlock Origin). These tools prevent loading of tracking pixels, analytics scripts and other ad-serving resources which all allow third-parties to following of their online habits.
Yes, it is. Here are some install stats for these tools, as of May 1st, 2015:
While in the grand scheme of things, this might not seem like a concern, it is important to keep in mind what would happen if a site-breaking bug prevents a users from completing an action on your site.
Think about all the places where you use such tracking snippets:
All these actions could be broken for users of these extensions. That means potential loss of revenue for you, but most importantly, a user leaving your site for a competitor because it prevents him/her from completing their task. Even worse, these bugs target specifically people mindful of their online privacy — punishing them for being concerned about their online presence is nothing more than shameful.
The critical part to understand here is that although these tools would have prevented you from tracking their presence on your website, they would not have prevented the user from making a purchase on your site (or completing any of your intended micro/macro-conversions). It is your very own implementation that is creating this roadblock.
The very definition of shooting yourself in the foot.
Luckily, there is a fix for this.
For Analytics, the function tracking outbound links can be fixed like this:
This uses the
ga.q property of the Google Analytics tracking snipped used to queue Events before the
analytics.js library is loaded. Once the library is available (after being async-loaded), the items pushed to
ga() are dequeued and the ga.q property is removed. Thus, if
ga.q is still defined, it is either because the event has fired too soon in the page lifecycle or because the library was blocked. In this case, we simply redirect the user to the original location instead of waiting for the confirmation from Analytics that the Event was recorded.
ga.q is safe to use as a reference in the long run, because the property is created locally in the tracking snippet of each page — i.e., it is not injected by an external file. For Google to remove support for this property, it would mean having to force every single Analytics User to update the tracking snippet on each page of their sites.
Not something easily done.
Using onClick callbacks directly in the markup feels dirty, and does not help maintainability. CSS selector-based tracking is more flexible and easier to debug.
Here’s how, assuming jQuery is available:
Is your website compatible with every device? Is your checkout process working from start to finish for every single smartphone or tablet on customers use to shop online? Are you sure you are not missing revenue due to a broken Proceed to Checkout page, and sending traffic to your competitor’s website instead? Are those errors causing fatal crashes, or do they just cause minor inconveniences?
The truth is, you don’t know.
Of course, you test your website regularly and all its most important features have been validated on the largest set of real devices you can afford. But you can’t cover the entire set of devices readily available to the public, and deadlines are always too short.
How, then, can you be sure that website errors don’t prevent your customers from completing their transactions?
Few people know about this, but the free version of Google Analytics supports exception logging. It might be caused by the fact that Google Analytics does not provide any built-in Report surfacing that information. Fortunately, that does not prevent you from making your own.
First, you will need to either:
You can test that the everything is properly set up by opening your browser’s developer console and typing
throw new Error('Crash!'), then checking your Custom Report a few minutes later to make sure your Error is logged.
By advised, though, that debugging minified production code might not be trivial, and that the errors logged do not necessarily mean that something terrible has happened — it only collects data that would otherwise be impossible for you to get.
The ultimate goal, of course, is to have an indication that something has changed on the website, and being able to monitor its health after rolling out an update. That could easily be done using a Timeline Chart to plot the number of errors per day, or a Table listing the most frequent errors and the Device Model on which it occurs, with the Page URL and Timestamp of each error.
There are a lot of options available for Custom Dashboards and Reports, and your needs will dictate how exactly you need that data to be surfaced. For the most common uses, you can always import this free template I prepared into any of your Views.
As a bonus, you could also set up Automatic Email Alerts to be notified if Error Rates or Numbers exceed a baseline threshold.