Why you should consider Server-Side GTM

Not another migration!?

I know, I know, “not another piece of technology for web analytics,” you cry, “I just got done migrating to GA4, setting up Consent Mode, and exporting my data to BigQuery!” you plead. Despite my bias toward a fascination with tech in this space (I am an engineer, after all), I understand your frustration. Finding your way to meaningful analysis and ROI can be challenging when you need to play a game of neverending whack-a-mole with emerging tracking technologies.

At what point can you sit back and reap what you have sown? Why does the web/marketing analytics technology stack seem to be in such a state of metamorphosis? I would put this shift into two buckets. Bucket 1 is the war of attrition against the 3rd party cookie, and bucket 2 is the ever-changing, ever-confusing world of privacy and security legislation.

Both buckets can, will, and have profoundly affected how data is collected and how you can use it. Server-side Google Tag Manager (sGTM), the reason I have gathered you all here today, helps to solve some of these emerging and established issues and is perhaps something you should seriously consider. It also comes with a new set of learnings and complexities that need serious thought. So, what on earth is it, and why should you perhaps plan for one more migration?

What is it?

I am not going into aching levels of detail here, the technology has been around for a while, and many people have done a better job than I could do explaining how it all works. But in a nutshell, a standard GTM container does its processing, JavaScript downloading and parsing, data wrangling and forwarding from the user’s browser. Third-party tracking scripts collect the data you expect and a little you might not. It is all familiar, warm, a possible drain on-site load times, and a source of a growing list of data governance headaches.

Server-side GTM moves all of the above to a server under your control. Think of it as a go-between, grabbing data sent by your site and processing everything before it is sent out to any analytics or marketing endpoints. In most cases, the server exists as a set of App Engine or Cloud Run instances, scaling up and down depending on the requests being received (nothing is forcing you into a Google Cloud Platform (GCP) hosted server other than its simplicity).

It can help solve many of the site load, data governance and security problems we have already hinted at, which I’ll go into more detail on. Check out the below diagrams to get a visual idea of how sGTM and browser-based containers differ.

Figure 1: Traditional client-side (browser side) GTM architecture (from Google documentation)

Figure 2: sGTM architecture (from Google documentation)

What use is it?

We know what it is and some of the problems it is looking to solve, so let’s go into more detail on what it offers and why you may be tempted to bite the bullet.

Granular control over data

With sGTM, all tracking data is sent to a server you own before being forwarded to any 3rd parties. You have complete control over what format that data is sent in. For example, you may wish to ensure any personally identifiable information (PII) data received is encrypted before sending it to its destination. Likewise, you may want to ensure a specific 3rd party receives no PII data.

By the server acting as a fully-controlled intermediate step, you can ensure the data you want, in the format you wish, is sent to external marketing and analytics partners. This granular control helps shore up any nasty PII leaks and gives you a complete picture of what data you are sending out.

Cleaning up CSPs

Another benefit from a data governance perspective is the clean-up of content security policies (CSPs). The CSP is a security feature that helps protect websites from cross-site scripting (XSS) attacks and other types of injection attacks. It specifies a list of approved domains from which the website can load resources, such as scripts, style sheets, and images.

Unfortunately, when a tag management system (TMS) such as the client-side version of GTM (cGTM) is implemented on the client side, each tag typically requires its domain to be listed in the CSP to function correctly. This need can lead to many domains being recorded, making it more challenging to maintain and update. With sGTM, the CSP need only contain the domain of the server (assuming you can move that piece of functionality over) and makes managing which sites and applications have permissions much more straightforward.

First-party cookies and server-managed Client IDs

Server-side GTM, Google Analytics 4 (GA4) and Universal Analytics (UA) client templates facilitate the implementation of a server-managed Client ID. When this option is enabled, the server response writes a first-party cookie with the HttpOnly flag called ‘FPID’.

This flag means the browser cannot remove or manipulate the cookie, which is how Safari’s ITP has affected the lifespan of JavaScript cookies in the past. However, Apple has closed this loophole by redefining first-party cookies as those set by the specific IP of the site. Although the server is on the same domain, it doesn’t share the IP, so the cookie may still be degraded as before.

Despite this, an argument could be made for the benefits of first-party trust. Since first-party cookies are set by the website that the user interacts with, a direct trust relationship exists between the user and the website. In contrast, third-party cookies are set by a different website, raising privacy concerns from the user’s perspective. However, these advantages could be diminished by browser restrictions and privacy regulations.

Another potential advantage of first-party cookies is security. They are often encrypted and transmitted over secure HTTPS connections, helping to protect them from interception and tampering. Third-party cookies, on the other hand, can be vulnerable to interception and manipulation by malicious actors, which may compromise the user’s privacy and security.

Improved site performance

As mentioned, the user’s browser is doing a lot of heavy lifting when it comes to marketing and tag-related JavaScript. One of the main benefits of sGTM is that it can improve a website’s performance. Tags and tracking scripts are loaded from the server instead of the user’s browser, which can help reduce page load times and improve the user experience. These improvements depend on the number and type of tags, and not all sites will see significant performance improvements.

Another potential benefit is that as the volume of data and the number of tags increase, the performance of cGTM can be impacted, leading to slower page load times and potential errors. sGTM can help address this issue by offloading some of the processing and handling of data to the server, allowing for improved scalability and performance.

Take advantage of conversion APIs

Transitioning to sGTM allows users to leverage powerful tools such as Facebook’s Conversions API (CAPI) and Google’s Enhanced Conversions. These features enable businesses to optimise their advertising efforts by securely sharing conversion data directly from their servers, bypassing browser-based tracking limitations.

By utilising sGTM, advertisers can maintain accurate conversion tracking and attribution, even in the face of increasing privacy regulations and browser restrictions. Furthermore, sGTM enhances data security and accuracy by reducing the risk of data loss or tampering associated with client-side tracking.

Data Enrichment

As our sGTM server is (probably) hosted in a GCP project, there are opportunities to utilise other GCP services to enrich data. One example of this available now is the Firestore look-up table. Where Cloud Firestore is a flexible, scalable, and fully managed NoSQL database service provided by Google for web and mobile app development. This server-side variable can be added to the server container and will look up and return values from a Cloud Firestore document.

One possible example of its use could be looking up product data. For example, an e-commerce event could send over just a product ID to the server. The lookup table could then use this ID to retrieve additional information about the product, such as type, stock level, or colour, and add this information to the event before it is sent to Google Analytics or any other endpoint.

Is it a no-brainer?

The unsatisfying answer is of course ‘it depends’. It depends on what your aims are as a company/site owner. If you are striving for a temple of gold-standard data governance and privacy, then the added granular control over what data is sent where is undoubtedly a pillar. Or you may want to do all you can to speed up site load times on an application with escalating tracking complexity. In that case, moving away from browser-based processing has obvious advantages.

But there are a few more things to consider with sGTM that make it a much more complex beast than its younger counterpart, cGTM. Before embarking on any sGTM project, it is critical to ensure that you understand what it is and how it works. Below are some things you need to be cognisant of to ensure success. Your company may need more internal resources to effectively and safely manage this type of technology in the immediate term.

A new way of thinking about GTM

Many will be well used to cGTM by now. Its UI, tag, trigger, and variable set-ups, and its methods for previewing and debugging. With sGTM, things are different. The UI looks similar, and the concepts of tags, triggers and variables remain the same, but there are new concepts to get your head around.

New ideas like ‘clients’ (used to capture, parse and respond to HTTP requests), HTTP-only first-party cookie settings, and different processes for preview and debugging may be noodle scratchers. I have no doubt anyone with knowledge of cGTM will be able to find their way around with some learning, but don’t be surprised to be a little lost at times.

Provisioning scalable cloud architecture

You caught me; I made that sound as scary as possible. What I mean by scalable cloud architecture is the technology your tagging server is built on. I made it sound so complex because it needs serious thought, and it is far too easy to overlook, especially as it is not something you have had to think about previously.

When you set up a new sGTM container, Google will offer to automatically build the necessary App Engine infrastructure to host your tagging server, which is nice. But therein lies a problem; it is never clear if that is that. Sure, you can do your due diligence and comb through the documentation, but considering the consequences of a poorly thought-out set-up (data loss, escalating costs), it should be more explicit.

For example, Google will spin you up a single instance of App Engine ‘flexible environment’ – which is fine for testing. But for most live deployments, work needs to be done to figure out how much things need to scale. A heavy hand when configuring scaling could cause unnecessary costs, and a cautious one could cause critical data loss.

These considerations are before we examine alternative GCP solutions for tagging servers, namely Cloud Run. Many, including myself, argue this is the better option and could work out cheaper for some. (see our blog on Using Cloud Run for sGTM here).

All of this is to say there is a large piece of additional expertise you may need in your company to get everything configured correctly.

Paying for analytics?!

For any GA360 customers out there, this won’t be a foreign concept, but for a large percentage of people who have been utilising the free version of Google Analytics and cGTM only, there has never been anything to pay. With a move to sGTM, this will change.

To be clear, you are paying for the services your tagging server sits on (App Engine or Cloud Run), and the cost varies depending on the amount of traffic your sites receive. Measurelab has seen monthly spending for our clients ranging from $25 for low-traffic sites to $300 for high-traffic sites (100 million events + per month). This cost depends on which solution you are using and if you have additional levels of redundancy in place, such as load balancing.

So when considering a move, do your due diligence and understand what this will cost.

Maintenance

If you have researched and configured your tagging server architecture to ensure it scales how it needs to, you will feel rightly proud of yourself. It may be tempting to pat yourself on the back and lose yourself in all those lovely sGTM advantages we discussed earlier. However, I urge caution on ever leaving a deployment on the shelf like that.

Firstly, it takes time to see how the ebbs and flows in your traffic affect your configuration and if it is genuinely fit for purpose. Secondly, consider growth; I will go out on a limb here and say most businesses aim to grow.

Growth leads to higher and higher levels of traffic and could start to push the limits of your set-up. Left unchecked, this could lead to a loss of data. The nature of new traffic could even warrant a rethink of the entire architecture. Perhaps your traffic has grown globally and now needs a load balancer; maybe you were previously scaling to 0 with Cloud Run to save money, but now your traffic has increased, and you want to add a layer of redundancy. These are all critical questions that need to be thought about continuously.

Conclusion

Server-side GTM presents a compelling case for those seeking enhanced data governance, privacy compliance, performance, and the ability to leverage powerful conversion APIs. While the transition to sGTM comes with complexities and requires a shift in mindset, the potential benefits make it a worthwhile consideration for organisations striving to stay ahead in the ever-evolving landscape of web analytics.

As you embark on this journey, it is crucial to understand the intricacies of sGTM, the associated costs, and the need for ongoing maintenance to ensure optimal results. By embracing sGTM, businesses can better navigate the challenges of third-party cookies, privacy regulations, and site performance while maintaining accurate tracking and attribution in their marketing efforts.

Measurelab has created the UPDATE framework to try and help the process of managing a sGTM migration. We are also happy to talk about helping you to make a move and maintain things moving forward.

So to answer the first question, “not another migration!?”…well, maybe just one more.