Should You Make the Shift to Google Analytics’ Global Site Tag?
Learn how the use of Google Tag Manager impacts your decision to migrate to the new Google Universal Analytics Global Site Tag.
In August 2017, Google posted several unassuming articles to their developer and support websites regarding a new analytics tag labelled gtag.js. The write-ups were titled with single-minded focus: How to add gtag.js to your site, How to migrate from analytics.js to gtag.js, and How to set up basic web-tracking with heavy emphasis on the addition of gtag.js. But with so little public fanfare, digital marketers and IT folks across the globe are asking whether it’s not too pre-emptive to make the switch to the Global Site Tag.
Read on to learn the nuances of migrating and what’s at stake with the new unified Global Site Tag.
What is the Global Site Tag?
The Global Site Tag’s ‘gtag.js’ is a new version of Google Analytics’ JavaScript capture application programming interface that currently uses analytics.js for web pages and web apps. What the new release clearly hopes to achieve is a unified tagging method that can, in time, combine tag requirements for Analytics, Content Experiments (i.e. Google Optimize) and conversion.js.
But why would Google release an updated conversion tag now?
On the heels of Safari’s Intelligent Tracking Prevention (ITP) that utilizes machine learning on both desktop and mobile devices to block cookies, Google seems to have quickly responded to the advertising industry’s concerns over the ITP’s impact on conversion tracking and remarketing efforts. By updating a website’s tags to the new global site tag, Google AdWords aligns with Apple’s ad attribution recommendations and theoretically improves performance measurements under a single implementation.
It’s also worth noting that the Universal Analytics Code ‘analytics.js’ was first introduced by Google in 2013, with original updates dating back to 2009. If we’re examining Internet best practices, it’s about time for an update. In that time, the digital marketing industry has embraced JSON (JavaScript Object Notation) as an XML stand-in for configuration and data exchange. Just look to the use of data layers for tag management systems which predominantly use JSON objects to manage the technical variables required for the TMS-fired tags.
The new Global Site Tag using gtag.js uses the same dataLayer principle, 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> |
The Global Site Tag is also much more in alignment with the way that Google Analytics for Firebase functions, passing an event name to gtag.js:
gtag(‘event’, ‘login’, {‘method’: ‘Google’});
This is, in turn, recognized by gtag.js as an “automatic event” and assigned the following values: Category (i.e. engagement based on ‘login’ event name), Action (i.e. login pulled from event name), and Label (i.e. Google pulled from the ‘method’ parameter for login events only). This should result in more powerful event tracking than before and hints at a more standardized or streamlined form of tracking for more than just advanced developers.
Should I migrate to gtag.js?
Veterans of Google Analytics will remember the migration from Google Analytics ‘ga.js’ to Universal Analytics ‘analytics.js’ with hard feelings. Venture further back circa 2007, and you’ll remember the migration from urchin.js to ga.js. In both instances, the migration required a sizeable effort for clients to migrate all of their custom tracking to an entirely updated code syntax.
While the Global Site Tag does bear a new syntax as well, it won’t require you to retag your site as the Universal Analytics ‘analytics.js’ is nestled within gtag.js. The functionality remains the same.
The decision to migrate to the Global Site Tag is actually rendered by your use, or lack thereof, of a TMS. If you’re already using a Google Tag Manager, then you are in no rush to migrate. The new Global Site Tag will not replace GTM because a Tag Manager suite like GTM separates concerns from site code and tag management, adding in tag governance and the ability to simultaneously trigger additional external tags outside of Google products.
As gtag.js interfaces with the dataLayer and the full Analytics suite, there’s ultimately no added benefit from a gtag.js installation alongside Google Tag Manager.
Change is inevitable.
While you won’t miss out if you stick to in-page Universal Analytics code with your current tag management system, now is a good time to begin planning your migration to the new gtag.js if you are not currently using Google Tag Manager or don’t require strict control over tag management.
Do you have questions about the new tag or how conversion tags improve performance measurements? Contact our Google Analytics experts here to audit your site strategy and assess whether you’re maximizing remarketing and conversion tracking./http://www.rlcmedia.com
