Note: This post originally appeared on the blog of my since-shuttered analytics firm: Axiomatic. That said, if you need some analytics work, get in touch

One of the things your website analytics should do the absolute best for you is letting you know when things went wrong.

When your search engine referrals fall of a cliff or when your conversion rate falls, you should be able to rely on your site analytics to tell you that it happened.

Today, though, let's talk about all your other errors - 404s and 500s primarily - and how best to track (and report on) with Google Analytics.

First off: Why would I track errors in GA?

If you're a developer (or friendly with your dev staff), chances are you already have error tracking for your site or apps1. So, why bother to track it in GA as well?

First, chances are you're not going to have the marketing department traipsing through your dev error tracking system, right?

Secondly, most developer error tracking services are geared more to individual issues: What went wrong and how to fix it. Tracking your errors in GA unlocks all of the other GA features - segmenting, technology, trends and the like - to tell you less about what went wrong and more about who's been affected.

Also, a class of errors that's just noise to most developers - 404s - can be extremely useful to dig into for marketers.

So, my first recommendation is to track errors, yes, in two places - your dev error tracking of choice for issue resolution and in Google Analytics for trends, impact and marketing knowhow.

What should I track?

As I mentioned up top, there are two primary classes of errors that are especially handy to track in GA: 404s and 500s. Javascript errors are also handy, but we'll save that for next week's Tuesday Tip.

Let's walk through them one by one.

Tracking 404s

As I alluded to earlier, most development teams treat 404s as simply noise. In most cases, nothing's actually broken from a code standpoint and, to be honest a 404 means your system is likely doing exactly what it should.

If you're a marketer, however, 404s can tell you a great deal:

  1. Do you have old broken links out in the wild?
  2. Did you just put the wrong link out on social media?
  3. Does Google really need to reindex your site?
  4. Do you have referrals out there that you'd don't even know about that need to have their URLs corrected?

The key thing here is to not track them as a page view; you don't want errors inflating your other metrics. Each of these error classes is better tracked using Custom Events.

The other important tip is to not redirect the URL to a single 404 page (ala www.yoursite.com/404.html) but rather render the 404 template and keep the URL the same. Essentially, to maximize the tracking's usefulness, we want to keep the referral, visitor and path information intact.

There are of course ways to still track all that formation while redirecting to a fresh page, but it's going to be more work for you in the long run.

To make this work, we're going to need to modify our tracking code a bit.

The default tracking code provided by Google2 looks like the below:

<script>// <![CDATA[
  (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
  (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
  m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
  })(window,document,'script','//www.google-analytics.com/analytics.js','ga');

  ga('create', <YOUR_UA_ID>, 'auto');
  ga('send', 'pageview');

// ]]></script>

So, first off, we want to remove the page view, which is the ga('send', 'pageview'); and replace it instead with some event tracking such as the below:

ga('send', 'event', 'error', '404', window.location.href)

Final full tracking code:

<script>// <![CDATA[
  (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
  (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
  m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
  })(window,document,'script','//www.google-analytics.com/analytics.js','ga');

  ga('create', <YOUR_UA_ID>, 'auto');
  ga('send', 'event', 'error', '404', window.location.href)

// ]]></script>

The nice thing about tracking this way is that you still get all the niceties about your users, acquisition and the like while avoiding pollution of your page view data (including bounce rate).

Once it's in the GA interface, you can still segment by anything you'd like in the Events reporting area (Behavior > Events).

One final note on the above: This change should be made only on the 404 page template. Leave your GA tracking code alone on all other pages.

Tracking 500s

As a quick recap: 404 errors are when a URL isn't there. The 500 class of errors3 are when something is messed up.

The procedure and technique listed for 404s largely applies here as well - as do the benefits. Again: If you can, don't redirect the page for 500s. Keep them where they are so you can pass the referral information without any extra effort.

Really the only change is in the event action, changing our replacement line of code with:

ga('send', 'event', 'error', '500', window.location.href)

Now, GA isn't going to be able to tell you what the error was, but from a marketing perspective that's immaterial. And besides, your dev team should really be tracking 500s in a more issue-based interface. In this case, GA is handy because you can segment the errors by things like operating system - which can prove hugely helpful for things like errors that might only apply to one browser or operating system.


  1. If you're not tracking errors in a dev-friendly interface, you really should be. Knowing when things are broken at the same time as end users - and ideally, before a client notices - is an all around big win. If you're on a Ruby platform, I can't recommend HoneyBadger highly enough. 
  2. Of note: these examples are using the universal GA interface - which you should really be upgrading to if you haven't already. 
  3. 500 errors can actually represent a wide range of issues. If you're serving a range of 500 errors, breaking this tracking up by specific error code would also be highly recommended.