The Google Analytics Setup I Use on Every Site I Build

While the current tracking snippet is good, it can definitely be better. One problem with the async tracking snippet is, by default, it will still create two HTTP requests (one for the analytics.js script and one to send the initial pageview) that will push back the load event, which will affect other load-based metrics and potentially delay code scheduled to run after the window loads.

There are two ways to solve this problem, the first is to wait until after the load event fires to run the tracking code, but this is undesirable since it will potentially result in missed pageviews from users who bounce early.

The second option is to use the tracker to use navigator.sendBeacon() for all subsequent hits:

Putting your tracking code in a separate file

The default tracking snippet instructions recommend adding the snippet code to the <head> of all pages on your site. If you’re just using the snippet as is, that’s probably fine, but as we add more code to track additional user interactions (which we will throughout this post), keeping all that code in the <head> is a bad idea.

I prefer to put all my analytics-related code in a separate file that I load asynchronously after my other site code has finished loading.

If you use a build tool that supports code splitting (like Webpack), you can lazily initialize your tracking code from your script’s main entry point like this:

Your custom tracking code will then live in its own module and can be initialized via its exported init() function:

Now your template files only includes the <script async> tag to load analytics.js as well as your site’s regular JavaScript code:

Note that if you’re not using a build system with code splitting features, you can get the same effect by compiling your tracking code separately and loading it via <script async> just like you do with analytics.js.^[1] Also note that you don’t have to worry about load order; analytics.js is specifically designed to handle cases where it loads first, last, or not at all (e.g. in cases where its blocked by an extension):

Tracking custom data

This code works by passing a function to the this uuid() function because it’s very short, but you can use whatever function you like:

Then set the Window ID value on your tracker object before you send any data to Google Analytics:

Hit ID, time, and type

The Google Analytics interface lets you easily report on aggregate data, but if you want to get access to individual user, session, or hit-level data, you’re mostly out of luck.

The Hit ID dimension is set to the result of calling our uuid() function (like we did with Window ID), the Hit Time dimension is set to the current timestamp, and the Hit Type dimension is set to the value already stored on the tracker (which, like with client ID, is tracked by GA but not made available in reports):

Error tracking

Do you know for sure if your code is running as intended (and without error) for every user who visits your site? Even if you do comprehensive cross-browser/device testing prior to releasing your code, there’s still the possibility that something went wrong or that some browser/device combination you didn’t test will fail.

There are paid services like Track:js and Rollbar that do this for you, but you can get a lot of the way there for free with just Google Analytics.

I track unhandled errors by adding a global error event listener as the very first <script> in the <head> of the page. It’s important to add this first, so it catches all errors:

This code stores any unhandled errors in an array on the listener function itself. Then, once the rest of the analytics code has loaded, you can report on these errors with the following functions:

Note: the nonInteraction field is set to true to prevent this event from influencing bounce rate calculations. If you’re curious as to why this is important you should read more about Real Time report and event hits do. It’s a shame because, of all the hit types that you’d want to know about in real time, exception hits are clearly at the top of that list.

Performance Tracking

Several years ago Google Analytics introduced Custom metrics (similar to custom dimensions) do not have either of these limitations, so that’s what I use to do all my performance tracking.

Custom performance metrics

To see how to track performance via custom metrics, consider three of the more commonly referenced performance metrics from the formatting type to “Integer”), you can use this code to track them:

const metrics = {
  RESPONSE_END_TIME: 'metric1',
  DOM_LOAD_TIME: 'metric2',
  WINDOW_LOAD_TIME: 'metric3',
};

export const init = () => {
  / …
  sendNavigationTimingMetrics();
};

const sendNavigationTimingMetrics = () => {
  / Only track performance in supporting browsers.
  if (!(window.performance && window.performance.timing)) return;

  / If the window hasn't loaded, run this function after the `load` event.
  if (document.readyState != 'complete') {
    window.addEventListener('load', sendNavigationTimingMetrics);
    return;
  }

  const nt = performance.timing;
  const navStart = nt.navigationStart;

  const responseEnd = Math.round(nt.responseEnd - navStart);
  const domLoaded = Math.round(nt.domContentLoadedEventStart - navStart);
  const windowLoaded = Math.round(nt.loadEventStart - navStart);

  / In some edge cases browsers return very obviously incorrect NT values,
  / e.g. 0, negative, or future times. This validates values before sending.
  const allValuesAreValid = (...values) => {
    return values.every((value) => value > 0 && value < 1e6);
  };

  if (allValuesAreValid(responseEnd, domLoaded, windowLoaded)) {
    ga('send', 'event', {
      eventCategory: 'Navigation Timing',
      eventAction: 'track',
      nonInteraction: true,
      [metrics.RESPONSE_END_TIME]: responseEnd,
      [metrics.DOM_LOAD_TIME]: domLoaded,
      [metrics.WINDOW_LOAD_TIME]: windowLoaded,
    });
  }
};

Now you can get the average load time values by dividing the totals for Response End Time, DOM Load Time, and Window Load Time by the metric ga('create', 'UA-XXXXX-Y', 'auto', 'prod'); ga('create', 'UA-XXXXX-Z', 'auto', 'test'); ga('prod.send', 'pageview'); ga('test.send', 'pageview');

Filtering out local/spam data

Sometimes spammers will send fake data to your Google Analytics account to promote their shady businesses. If you don’t believe me, just search for

Time to first paint distribution for the Google I/O WebApp (Desktop)

On mobile the median was 1634 ms when controlled by a service worker vs. 1933 ms when not controlled.

Time to first paint distribution for the Google I/O WebApp (Mobile)

Conclusions

There are a lot of features developers would like that Google Analytics doesn’t track by default. However, with only a bit of configuration and extra code, you can do almost everything you want with Google Analytics’ existing extensibility features today.

This article provides a brief introduction into my rationale for including a lot of these features in my “boilerplate” analytics.js implementation. If you want to keep up to date with the current state of best practices, you should follow the share it on Twitter.