/ Posts tagged "analytics"



Your Analytics is Breaking your Website

That may sound surprising, and even counter-intuitive, but for a certain percentage of your users, your Analytics implementation is breaking your website.

An example

Take this example, which is the standard way of tracking outbound links as described in the official Google Analytics documentation:

The problem

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.

Is this a really a concern?

Yes, it is. Here are some install stats for these tools, as of May 1st, 2015:

  • NoScript (Firefox): 2,247,350 users
  • Ghostery (Chrome): 1,929,452 users
  • Ghostery (Firefox): 1,456,730 users
  • uBlock Origin (Chrome): 960,300 users
  • uBlock Origin (Firefox): 14,089 users

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:

  • Form submissions (Contact Us, Feedback, Request a Demo, etc.).
  • Add to Carts
  • Cart Checkouts
  • Link clicks
  • etc.

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.

How to prevent your Analytics implementation from breaking your website

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.

Using 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.

Bonus: The Mordern Way of Tracking

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:

Tracking Website Errors with Google Analytics

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?

There are services available to log your JavaScript errors to a local or remote server, but these solutions cost money are require interfacing with external systems. This is usually not something stakeholders are willing to pay for — after all, there are no bugs in the application, right?

A Simple and Free Solution

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:

  • Include the following JavaScript code snippet into your application.
  • Use Google Tag Manager to inject it into every single page of your site.

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.

Using the Data

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.

Free “Website Errors” Dashboard

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.

Tracking Website Errors with Google Analytics


As a bonus, you could also set up Automatic Email Alerts to be notified if Error Rates or Numbers exceed a baseline threshold.