The world of tracking is increasingly rapidly evolving. Data protection regulations change, platforms adapt, and with them the users.

Both the individual entrepreneur and the professional must therefore continually update themselves to comply with the rules and avoid steep fines but at the same time continue to take advantage of the full potential of these platforms.

Given the recent news (end of September) of Google announcing the release of Server Side Tagging in Google Tag Manager from Beta version I want to talk about this opportunity with Luca Sanità, content curator of the Data Enthusiast blog, to whom I asked a few questions to delve into a still unclear area.

And are you ready to change your point of view?

What is Server-Side Tag in Google Tag Manager?
In order to understand the context of server-side tracking using GTM, we need to link to some issues that are now well known among us industry professionals, namely the limitations on third-party cookies that in recent years not only Apple, but to wheel the major Browsers, are bringing forward.

The limitations that take place client-side, that is, right in the browser used by the user, are not the same as with server-side tracking. To understand, when we have the classic GTM container installed, each tag implemented makes calls to external servers, such as Google Analytics, Facebook etc., and these calls happen through the user’s browser.

For the tags to work properly, cookies are also created which, for the most part, are third-party cookies. With the constant restrictions that occur in Browsers, a lot of data, useful for digital analytics, is not passed to the tools we use every day such as Analytics or Facebook.

In the server-side context in GTM, things change because the information is not simply passed from the user’s browser to the third-party tools, but a new element is added which is the Server Container that is hosted on a server that, once set up, allows us to work in a first-party context.

How does server-side tracking work?
The operation is simple from a theoretical point of view, because the basic idea is to move HTTP requests to the server hosting the new container, handle them better there, only then send the data to the different service providers.

However, it is good to keep in mind that, this type of tracking, works with two containers. Yes, we don’t think we need to archive the client-side container. Basically, we will be dealing with the classic container we have always used and the new server-side container.

On top of that, we add a new element called the Client that is the key tool in the whole system, because it is the link that actually handles incoming HTTP requests and defines them so that they can be used by the tags to complete the request in the server and then send the data to the service providers.

Be careful, however: when we talk about client-side we are not saying the same thing as when I refer to “Clients.”

We talk about the client-side or web-side container when we refer to the container working through the user’s browser.

When I talk about “Clients,” I am referring to this new element, which is essential for server-side tracking to work properly.

What are the main advantages and disadvantages?
The advantages are several because by transferring the main management from the user’s browser to the server, which hosts the new container, first of all we have an improvement in site performance. In the client-side container, to make everything work properly, each tag goes and adds JavaScript libraries with an obvious impact on page loading.

In the server-side container, on the other hand, I can have fewer scripts load then manage the sending of the different information to the third-party tools. Data quality control: we can manage the information we send to different service providers by deciding what to send and what not to send. Increased security on the PII (Personally Identifiable Information) side: the credentials used by users browsing our website have an additional layer of protection because the management of the information goes, no longer through a browser, but through a server.

I can extend the cookie lifetime for users using iOS systems as the server becomes a first-party context. Reducing the impact of ad-blockers that, not infrequently, also impact requests sent to and from Google Analytics. As usual, not all that glitters is gold, and so the pros are also followed by several cons.

The main disadvantages of this solution concern the know-how in implementing the server instance on Google Cloud Platform or on AWS. Not everyone has this expertise and often the effort increases because it is necessary to refer to the IT department to which one has to explain the needs and reasons for implementing this solution.

There are server maintenance costs that vary depending on traffic volumes and service scalability (we are talking about deltas that can range from 50€ to 200€/month but can also go up. A cost guide can be found here).

While it is true that I told you earlier that you reduce the exposure of user credentials on the browser by adopting a server-side tracking solution, the downside is that, what happens on the server is less controllable and more opaque.

Spam risk and salty bill: another risk is that there can be hacked requests sent from the client to the server impacting the final costs (it is true that in the GCP, in the Billing > Budget&Alerts section, it is possible to insert alerts to monitor costs, however, it is important to be aware of the issue).

How do you implement and what might be the additional costs?
If I have to summarize the main steps of implementation for you, I can tell you that these are the main steps to follow:

  • creation of the server-side GTM container directly from Tag Manager;
  • verification and mapping of the server-side custom domain: at the beginning of the implementation you are provided with a domain, which hosts the server container, that belongs to Google (you recognize it because it has the name appspot.com). You will need to create a tracking subdomain tied to your domain (e.g., if my site is www.miosito.it the subdomain could be gtm.mysite.co.uk or data.mysite.co.uk)
  • create Clients to process incoming requests
  • update the GTM settings to send data to the server-side container
  • verify and test incoming requests
  • send the first data from the server-side container to the third-party providers
  • if using the Google Cloud Platform, upgrade to the App Engine Flexible environment
  • publish the container, monitor costs and increase tracking over time with the aim of running client-side and server-side tracking in parallel


Regarding costs, let’s say that, in addition to the above, we need to consider the effort to be devoted to the solution. You cannot think, that server-side tracking is something pre-packaged that you put in place and then let it go (actually, it cannot be that way for client-side tracking either).

You have to think about devoting the right resources to maintain it, analyze the data and the differences between the information collected client-side and server-side. This is a difficult to quantify but necessary cost/investment to consider.

In what cases should it be implemented?
As we have discussed, it is understood that the solution is not so difficult to implement, but at the same time not so simple either. It also requires planning the right resources over time. I would tell you that it is a solution that, starting with medium-sized entities, should be seriously considered.

There are a number of advantages that must be seen from a medium- to long-term perspective: the sooner we get our hands on the implementation, the sooner we can realize the potential and will be able to master the tool to offer solutions, in the company or to the client we follow, to the cookie-less future.

In addition, we definitely need to take advantage of these innovations to see with our own eyes the difference in the data collected through a client-side and server-side tracking architecture and the impact on web analytics and campaign management tools.

In short, we know that ours is an ever-evolving industry, and if we want to ride the wave and not simply get swept away, we need to start getting our hands on it now.