In August 2017, Google announced the Google Universal Analytics Global Site Tag.

The announcement triggered a few discussions on Twitter, with digital marketers and IT folks worldwide asking: “is it time to upgrade already?”

This post explains what is at stake with the Global Site Tag and why you should switch – or not.

What is the Global Site Tag?

The Global Site Tag (gtag.js) is a new version of Google Analytics’ JavaScript capture API, currently using analytics.js for web pages and web apps.
At the end of the day, both analytics.js and gtag.js both leverage and send data to the Measurement Protocol, Google Universal Analytics’ data collection API.

Why would Google release the Global Site Tag now?

For starters, analytics.js is 7 years old, which is ancient by Internet standards – and best practices. In those 7 years, the JavaScript-powered digital marketing industry has massively embraced JSON as a replacement for XML for configuration and data exchange. The most obvious example is the adoption of data layers for tag management systems which, with a couple exceptions, all use JSON objects to handle all business and technical variables required for the tags fired by the TMS.

Even the in-page Google Universal analytics (analytics.js) makes some use of JSON to supercharge hit requests:

ga('send','pageview','/mypage.html',{
  'dimension1': 'blog',
  'dimension2': 'english'
});

The Global Site Tag using gtag.js makes use of the Google Tag Manager data layer methods and infrastructure, as shown below:

<!-- Global Site Tag (gtag.js) - Google Analytics -->
<script async src="https://www.googletagmanager.com/gtag/js?id=GA_TRACKING_ID"></script>
<script>
  window.dataLayer = window.dataLayer || [];
  function gtag(){dataLayer.push(arguments)};
  gtag('js', new Date());

  gtag('config', 'GA_TRACKING_ID');
</script>

This methodology can be extended to add clear parameters for hits:

gtag('config', 'GA_TRACKING_ID', {
  'page_title': 'homepage',
  'page_location': 'http://foo.com/home',
  'page_path': '/home'
});

And the Global Site Tag also allows for predefined values for events, which auto-widens event categories or actions based on event labes for instance.

But don’t take it from me and look at posts by esteemed colleagues:

So should I switch to the Global Site Tag?

Luckily for you, I put together a convenient flowchart to help you decide whether you should migrate to the Global Site Tag, as shown below:

… and the short answer is: no, you do not need to migrate to the Global Site Tag for another year at the very least.

As you can see in the flowchart, the decision to migrate to the Global Site Tag boils down to whether you use a TMS – or rather, whether you don’t use one. If you use in-page tags, you are in no rush to migrate but if you feel so inclined, Google has a brief Global Site Tag migration guide in the support section.

In the past, Google has warned about decommissioning old versions of their tracking code. For instance, the original urchin.js code introduced in 2005 with the first version of Google Analytics was supposed to be decommissioned after a moment. Back in 2009, when the new ga.js tracking code was around the corner, I was asked my opinion about migrating to the new code and whether Google would stop collecting data on sites using the old code. My advice then was to prudently migrate just in case but history has shown that urchin.js is still around (eeek), ga.js works on quite a few sites in the world (and is still somehow supported by GTM via the Google Analytics Classic tag). The official tag is still very much analytics.js, until Google promotes the Global Site Tag as the default collection method.

In closing

Keep in mind this migration is “just” the adoption of a new tagging syntax, not a functional upgrade. You will not miss out if you stick to in-page Universal Analytics (analytics.js) code so make sure you migrate for the right reason, i.e. you’re using old code and need to benefit from Universal Analytics features.

If you are using a TMS such as Google Manager, you will be all set. Unless of course you went the custom tag route and you’ll need to maintain the new libraries yourself.

What about you? Are you planning to migrate? Have you already migrated? Tell your story in the comments below.