3 Things You Should Know About Google’s New Global Site Tag
By Olaf Calderon
Marketers have access to more consumer data than ever, which is in part why Acronym is expanding its Analytics practice. That, of course, includes hiring digital analytics guru Olaf Calderon, who joined Acronym in August. Here, Calderon weighs in on Google Tag Manager (GTM) and explains what’s hot – and what’s not – about Google’s new Global Site Tag (gtag.js):
Google’s recent release of the Global Site Tag (gtag.js) certainly created some waves in the analytics and marketing sectors. Although, to be fair, any time Google releases anything, it’s sort of a big deal and there are lots of eyes on it.
This release is a new code library that will eventually replace Google Analytics’ analytics.js library. The main idea is to make the coding for Google Analytics, AdWords and Firebase more uniform and improve inter-tool communication. Eventually, the goal is to have just one tag that sends data to all Google tools, instead of having separate tags for Analytics, AdWords, etc.
So without getting into the technical features and frameworks, here are three basic but important things you should know about gtag.js:
1. It is in beta.
Gtag.js is currently in beta. This means it has limited functionality so far, but it’s laying the groundwork for future improvements. The purpose is, after all, to have better communication between the different tools and Google has been making a move toward having a unified structure to make this communication seamless. It is very important to have AdWords, DoubleClick, Firebase, Google My Business and Analytics libraries follow a global structure for data and this is a big step closer.
So should you update your code now? Well, beta is a testing platform, so you’ll be taking a risk and you’ll be assuming all responsibility. Some of the issues with beta releases include not having all features enabled (much as analytics.js was missing the display features) or not having SLA coverage. In addition, things may change, move or stop working. Our suggestion is to set it up on a test environment and start getting familiar with it. Eventually, it will be ready for you. You’ll find out more about compatibility below.
2. It is not for Tag Management Systems (TMS).
While gtag.js lives on the www.googletagmanager.com domain, it is important to note that it is not Google Tag Manager (GTM). Google representatives have said there are two main reasons that the GTM domain was used:
- Some Google Clients must whitelist domains in order to comply with internal security policies. For these organizations, GTM is generally already whitelisted. Loading googletagmanager.com within gtag.js means that no additional work is required for these Clients.
- Some pieces from GTM are included in the gtag.js file. Only select code snippets are shared between GTM and gtag.js though, like loading in various request templates / libraries automatically & efficiently, and translating data passed to the platforms into the correct format. The gtag.js is roughly 20KB in size, but deduplicates a lot of the logic required to implement various tags.
There is no web interface for gtag.js, which means everything is governed via the code. Nobody “owns” a container, like they would in GTM, nor can any tags be added without developers’ knowledge. You can deploy gtag.js through another tag manager if you want, without worrying about whether this creates a “backdoor” where others can add tags within gtag.js without your knowledge.
3. It is backwards-compatible.
The new library allows for some notable changes and simplifications to custom on-page Google Analytics code, such as a simplified syntax for tracking events. But Google has made sure that gtag.js fully supports analytics.js code syntax. This means that you can make the change in your snippet and not worry about other inline code breaking things. Think of gtag.js as an add-on for now. Keep using the code syntax you have in place, but start experimenting with the new features and definitely start planning a strategy for migration over time.
It’s also likely analytics.js will be supported for a very long time. Just think: The old urchin.js code still works and it’s been deprecated for over ten years.
So, overall, gtag.js is like a road sign on the roadmap towards a unified Google code base. It’s worth getting familiar with how it works and some of the new syntax, but we wouldn’t recommend planning a migration in the near term.
If you want to get into the technical details, you might as well go straight to the source: