Should you switch to Google Analytics’ Global Site Tag?

2020 October UPDATE: With the release of Google Analytics 4 (App+Web/Firebase), the old tracking code (analytics.js) is no longer supported, only GA4 and gtag.js are supported going forward.

2019 September UPDATE: In September of 2018, Apple rolled out its Intelligent Tracking Protection (ITP) 2.0 program. When ITP is activated, third-party cookies can only track a user’s activity across sites for 24 hours from the exact moment a user visits a website. After this 24-hour window, these third-party cookies are only able to “remember” a user’s login information. With ITP, all third-party cookies are gone after thirty days.[link]

Recommendation

Use Google Analytics tracking via GTM in order to avoid any code conflict and use a conversion linker

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 data collection 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 labels for instance.

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

• E-Nor
• Impression
• Goanalytics (IT)
• Analytics-Insights (DE)

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. At the very least, if you use GTM, all you need to do is add a conversion linker.

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.

So it’s not about analytics.js vs gtag.js or vice versa:

• you can keep using analytics.js but keep in mind that:
  • that code base is now deemed obsolete
  • third-party cookies will be affected
• you can use Google Analytics (“regular” or v4) over Google Tag Manager but use a Conversion Linker tag in order to avoid cookie issues

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 *may* not miss out right away if you stick to in-page Universal Analytics (analytics.js) code. There are features in Google Analytics 4 that will make you want to upgrade, especially the BigQuery integration.
Make sure you migrate for the right reason, i.e. you’re using old code and need to benefit from new Google Analytics features.

If you are using a TMS such as Google Manager, you will be all set. Switch to Google Analytics 4 and add a Conversion Linker tag. 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.