GTM’s server-side container is a large shift in how you should think about your on-site data collection. With a simple upgrade path, users of the platform should begin planning out their migration from ‘classic’ front-end based tracking to getting as much of the integration completed in the server as possible. By doing so, you’ll be laying the groundwork for a more private and reliable data pipeline, as well as a site that is more performant and secure. The sources of these advantages are nuanced and technical but explored at a top level below.
Background and Google Tag Manager’s History
When Google Tag Manager (GTM) launched back in 2012, it entered a crowded field, but one in which the standard operating practice was hard-coding of analytics by web-site developers. With Google’s dominance in the AdTech and Web Analytics industry, not to mention the platform's attractive price tag of $0, GTM drove a paradigm shift in how IT departments tackled data and feature implementation for their analytics teams. In doing so, GTM also captured massive market share in the tag management space and spurred many of the incumbents to innovate and add value to justify their considerable licence fees.
Those competitors added value in many ways, such as by adding integrated consent management systems, or by focussing on client-side security with things like threat detection functionality. One approach common to many was the deployment of server-side tagging functionality. This brought many advantages to tag managers, delivering for their users an implementation that was more reliable and private, as well as sites there were more secure and performant.
Unfortunately for those competitors, Google has just parked its tank on the server-side lawn too, with their recent launch of server-side containers for GTM, freely accessible — although not free to run — for all users of the platform. With this democratisation of access to server-side functionality, we’re on the cusp of undergoing another paradigm shift in how AdTech and digital analytics teams will implement their technologies. Thankfully, this is one that will benefit all interested parties, our clients’ customers but also analysts and IT teams looking to tighten up their front-end security.
Mostly these advantages stem from the enhanced level of control that GTM’s server-side option will make available, as well as enabling a slimming down of third-party code being loaded into the front end.
On top of that, it will also facilitate greater control over what is sent on to those third parties. As an example, IP addresses will be obscured by default, alongside other finger printing surfaces like the user agent string. With fingerprinting surfaces obscured, opaque, anti-consumer and intrusive identification techniques can be nipped in the bud at the source.
The removal of those third-party libraries is also going to make your site more secure. This is likely to happen from two sides.
The first is that it facilitates the adoption of a (stricter) content security policy (CSP) on your site, locking down what can be carried out on the front end. Most users of GTM these days likely either have no CSP or a very permissive one, with blanket exemptions like ‘unsafe-eval’ typically requested to enable the use of Custom HTML tags or Custom JS variables, thus rendering most of the cross-site scripting (XSS) protection from the CSP null and void. While the need for these exemptions can be mitigated using standard or custom templates in GTM, it’s not an approach that less technically adept users of the platform typically leverage (instead, favouring the copy-paste approach advocated by third parties who are looking to minimise the adoption friction for their technologies).
As the server-side option becomes more feasible, IT departments will gain more leverage to push back on weak CSPs and the copy-paste approach, so we ought to see CSPs being beefed up with fewer complaints from the analytics and marketing teams.
The other side of this will again come down to a reduction of trust in the system, by not having arbitrary third-party code executing on your site. While we can assume that the Googles and Facebooks of the world are likely to have good security, smaller vendors may not be quite so up to scratch, exposing you to risks like the data skimming attacks many high profile enterprises have suffered over recent years (resulting in a several hundred million pound fine in some instances).
Likewise, when it comes to performance, removing those third parties is going to have an impact on the speed your pages load at. Regardless of how much vendors protest that their snippet is asynchronous, that it’s heavily minified or that their CDN is super- duper- fast, the reality is that downloading and executing JS will always have a performance impact to at least some degree. When there are no alternatives, we need to live with this impact on page performance as the cost of doing business with the partner (or strike some middle ground and sacrifice functionality and ease, for example by implementing image tags for Facebook rather than using their JS library). With server-side, we can have an even happier middle and do an even more reduced amount in the front end but still get most of the data we need passed along to the locations its needed in.
Another advantage that server-side processing brings is the ability to clean up incoming data to improve its robustness. While many companies now have reliable data layers installed on their sites to power their tag manager, modifications to that as well as the configuration of the actual tags can introduce errors and defects over time. In the world of tag management, many companies sadly overlook the need for robust quality assurance in their TMS deployment processes. By having an intermediary between the front-end and the platform the data is intended for, data cleansing (and enrichment) should be far simpler for users of GTM.
What Next from The Competitors?
So how should we expect the rest of the TMS market to react? Well, for many of them, it’ll be more of the same, but with a redoubling of their efforts. A handful of the most prominent non-Google offerings have been repositioning themselves in recent years not just as a tag management solution, but as full-blown Customer Data Platforms (CDP). Likely, we’ll see them continue to invest in their AI/ML based augmentation of the data they’re collecting and storing, as well as further emphasis on their well-stocked cupboards of turn-key integrations with other platforms.
We’ll also likely see them continue to invest in their ‘consent management platforms’. While GTM and other measurement tools from Google are integrating more neatly with consent frameworks like the IAB’s TCFv2, the reality is that most clients’ needs go far beyond what is supported as of now.
If these TMS-first businesses can successfully convert their current – generally content – clients to their other features, then they have every chance of thriving over the coming years. If they do not adapt, then it’s possible they’ll be consigned to an ever-diminishing market share of the enterprise TMS market.
For others, on the other hand, the landing point with their clients is not their TMS offering but instead their analytics offerings. For those, I think we are unlikely to see much change in their product or go-to-market strategy because of this launch, although the general pivot to CDP functionality or focussing on privacy already forms a part of their strategies.
What Next for GTM Users?
If you’re leveraging GTM as your tag manager, you should consider migrating as much of your implementation as possible to this new method. Thankfully, the upgrade path is straightforward when it comes to your Google Analytics set up.
New server-side containers can be provisioned within the GTM UI using a simple set-up wizard, and the integrations with GA — both Universal Analytics as well as the App + Web variety that is scheduled to replace it — are rich and come with many added benefits not touched on above. Where it will become not so straight-forward, and where we at Merkle or GTM’s excellent community of contributors can step in, is around integrations with other third parties.
Here, you will need to find which technologies are possible to be migrated to the server (for example, your session-reply tool and A/B testing tools cannot be migrated). From there, you will need to translate these into tags within the GTM container using the templating tools available, translating the event data that you’ll most likely dispatch using the transport URL field in you GA implementation into the format the third party endpoint will expect.
If you are interested in learing more, or are looking for advice on getting started with server-side tagging, please get in touch with our Analytics team.