What Marketers Need to Know About Server-Side Tracking

June 27, 2023
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:

  • Accurately track website engagement and outcomes (with the necessary consent)
  • Control the data sent to third-party services
  • Decrease website load time

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:

  1. Google Universal Analytics
  2. Google Analytics 4
  3. Mixpanel
  4. Mailchimp
  5. Hotjar
  6. Meta Pixel
  7. Google Ads Remarketing
  8. Google Ads Conversions
  9. Snapchat Pixel
  10. TikTok Pixel
  11. LinkedIn Pixel
  12. Twitter Pixel
  13. Bing Ads Pixel
  14. Pinterest Ads Pixel

Although it seems extensive, this is a relatively common list of services.

Part 1: All things hardcoded

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:

  1. The borders of the “website”. Think of this border something not only applicable to the website owner, but also “visible” to Web Browsers, and Browser Extensions (e.g. Ad blockers) that visitors use to access the website.
  2. I added the lines representing data transfers with orange, if they represent third-party calls. A third-party call simply means that the data point is sent to a hostname that is different from the hostname of the originating domain. This will be useful to compare later on.

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.

Part 2: Tag Manager Web Containers

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:

  • Initialising the Google Tag Manager library on every page on the website (usually done once in one “template” location in the codebase)
  • Firing a single script per action to track (e.g., Add to cart) through dataLayer.push

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:

  1. It decreased developer effort in implementing tracking. A new service could now be implemented quickly via a few clicks on the Google Tag Manager interface.
  2. It provided a single method and interface, where all tracking was consolidated consistently.

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:

Part 3: Server-Side Tag Manager

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:

What is “hardcoded” on the website

To send data from the website to the Server container, there are two main options:

  • (most common)The previous wGTM implementation is kept, but we utilise transport Tags to send data to our Server Container. These are usually GA4 or Universal Analytics (UA) tags, but instead of sending data to Google Analytics, they are configured to send data to our sGTM instead. This is the setup shown in the chart above.
  • We can skip wGTM completely, and instead implement a gtag script on our website that sends data directly to the Server Container.

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.

What does the Server Container do

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.

Where does the Server Container live

There are two options in terms of hosting your Server Container:

  • Automatic provisioning. GTM sets up a new Google Cloud Project project and an App Engine tagging server for you. You can also select an existing GCP project.
  • Manual provisioning on non-Google infrastructure

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.

1st Party Configurations

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”:

  • The website requests the gtm.js library from a 3rd-party domain, googletagmanger.com
  • The wGTM Transport tags send data to a 3rd party Server container, on an appspot.com host like the above.

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.