What Marketers Need to Know About Server-Side Tracking
on
June 27, 2023
by
Jason Spanomanolis
Server-Side Google Tag Manager (sGTM) is often considered the next step in developers, marketers, product managers, and analysts’ journey to achieve the following goals:
At the same time, sGTM requires the implementation and maintenance of owned infrastructure to run the server(s) that receive and forward data, with subsequent cost. Additionally, it comes with a whole new set of entities and processes for operators to onboard. So let’s try to understand how we ended up here, and show the full picture so you can decide whether to invest in implementing sGTM or not.
To understand this evolution, let’s say a website, after getting appropriate visitor consent, wants to send Pageviews and Events to the following destinations:
Although it seems extensive, this is a relatively common list of services.
Before Tag Management platforms like Google Tag Manager, all these 3rd party platform scripts needed to be implemented separately, by the website developers, directly into the website code. So for example, when an “add to cart” event happened on the website, the developer would have to manually fire 10+ scripts, each for a different service.
Additionally, on the above and subsequent charts, notice:
So for example, an Ad blocker, or browser level setting, might see a call made to Facebook Ads and just block it from going through.
With the advent of Google Tag Manager for Websites (wGTM), developers could simply add a single tracking implementation in the website’s code. This is achieved by:
Then, anyone could use the Google Tag Manager interface to transform the data and fire any number of third-party scripts, without requiring additional effort from developers.
This was great, because it meant that:
However, these 3rd party scripts still ran from the website, which means that our website still has to fire 13 separate scripts each time a page loads. Even though Google Tag Manager fires tags asynchronously, this still can affect the user experience, and it means that these 3rd party scripts get huge freedom in what they can track from our visitors interacting with our website.
And of course any of these can still happen:
Google Tag Manager Server-side introduced the possibility of sending data to downstream destinations, not directly from the browser, but through an owned server.. As you’ll see below, along with this, the complexity of the implementation and tech-stack increased dramatically:
To send data from the website to the Server container, there are two main options:
The website now just sends data to a single destination: our server-side container, instead of having all the tracking service scripts initiated from the browser.
Apart from the offloading of the additional scripts, effectively the browser suddenly becomes blind to what the website is tracking, and where it is sending the data. This is a really important point, so lets go through a case:
Let’s say you are a privacy-minded person (or a regulator or consent lawyer), and you want to audit what a website is doing with your data.
Without server-side tracking, you were be able to interact with the website and it’s consent options, and observe what scripts the website was firing, to which destination. Everything was visible. You could see that when you make a transaction, the website is sending a “Purchase” event to the Facebook Pixel, that includes all the product information, along with (hashed) values for the first name, last name, phone number, email, address advanced matching parameters.
Now the only thing you can see is that the website is sending events and parameters via the two mentioned methods above.
This means that there is a huge responsibility on Website owners and operators, to make sure to comply and manage visitor & customer data in a compliant, consent driven manner. The decreased visibility is not a cart blanche to drop compliance practices.
Without getting into much technical detail (not the scope of this post), the Server Side container utilizes special adapters called Clients, which receive the requests from the wGTM transport tags (or the hardcoded gtag), transform them into events, and then run containers that fire server Tag to 3rd party (or 1st party) destinations.
There are two options in terms of hosting your Server Container:
By default, the Server container is hosted on a default appspot URL, like https://gtm-pm66dddmxw-yjy23r35m.uc.r.appspot.com.
The initial configuration is free, but once upgrade to a production environment, you can expect $30-50 per server per month. Large traffic amounts may increase this cost.
As you might have noticed above in the first Server-side container chart, there are still a few orange lines that cross the browser “borders”:
To improve on this, you can “map” a first party subdomain of your website, for example track.mywebsite.com, and point your sGTM server to it. Additionally (and here is where things get really confusing), you can ask your sGTM container to load the gtm.js library, instead of it loading from googletagmanager.com. Here is how a setup like this looks like conceptually:
The advantage here is that as seen above, there are literally no 3rd party tracking related calls made from or to the browser. Everything is 1st party context.
This does not necessarily mean that there is no chance that a tracking call might get blocked. A browser might not support JavaScript, or an Ad blocker might block any call that has contains “gtm.js”. But theoretically, accuracy should be improved.
The adoption of server-side Google Tag Manager (sGTM) offers a compelling opportunity to streamline your site’s data tracking while improving page load times. However, with its advantages come complexities, an increase in implementation efforts, and added costs.
Before embarking on the transition to sGTM, consider the scale of your current tracking needs and your organization’s technical capabilities. Can you afford the added expenditure for the server? Do you have the expertise to manage this system effectively? Is the potential gain in data accuracy and the control over data sent to third-party services essential for your business strategy?
Furthermore, the shift to sGTM brings a heightened responsibility for data management. With less visibility into tracking activities, website owners and operators must prioritize compliance and consent-driven data practices more than ever before.