Server-Side GTM like a nuclear technology
Some time ago I listened to a podcast from the Technical Marketing Handbook series from Simo Ahava, whose guest was Adam Halbardier from the Google Tag Manager product team. During the conversation, the topic of transparency of data handled by the Server-Side container appeared.
So I thought that server-side tag technology is like nuclear power. On the one hand, it is an excellent convenience for humanity in the form of cheap energy, and on the other hand, it is a considerable threat - like an nuclear bomb.
One technology, two sides of the same coin.
Note: The topic concerns the entire technology of serving tags (scripts) on the server side - not only Google Tag Manager.
What is the main difference between Server-Side and Client-Side Tag Management?
So far our containers have been 100% browser-side (Client-Side). This means that all scripts operated on the level of such a container made contact and sent information directly to the end client, e.g. Google Analytics, Google Ads, Facebook, etc. Each tool implemented using a client container establishes a separate interaction that consumes the computing power of our web browser.
Although such scripts are usually asynchronous, i.e. not calling them does not stop the remaining tracking, their processing takes up the memory of our device anyway. Less memory means slower page loading, especially content for the user. This is especially important with a slower internet connection.
Server-side technology changes the approach and instead of multiple requests to different end clients, one request comes from our device - to our server. As part of this request, all information is passed, which is then parsed in the server-side container. From there, they are sent to individual end customers. Thanks to this, the "burden" of serving many end customers rely on our server. The more end customers we serve, the more important it is to speed up the service on the server side. Of course, we speed up the page loading time at the expense of server support, which we will have to bear on our side.
Is speeding up page loading time the only advantage?
In the era of privacy-first measurement, building solutions that communicate only "with our" resources is critical, in the so-called privacy-centric measurement. The fact that the browser communicates only with the server that belongs to us is also significant in the case of adblocks and solutions that block the so-called third-party data. From the point of view of cookies, we can also create server cookies that are important in selected (as of today) browsers. Generally - they are more durable and treated as less dangerous.
Another argument from the point of view of privacy is control over the data that we pass on to end customers. In the case of the Client-Side container and the tags deployed with it, we have no control over what the deployed scripts actually download from the browser and pass on. If all information is sent to us on the server first, we can "clean" it with our own key and only then pass it on to end customers. We have full control over it.
Where is the said threat then?
Reading the above arguments, you are probably wondering where is the other side of the coin? Server-Side for a source of cheap energy - pure goodness.
Well, the problem is privacy and what is actually passed on to end customers. As a rule, the container owner should comply with the GDPR rules and not provide personally identifiable information (PII) to third parties.
How sure are we? Unfortunately none.
That's what offices are for! All right, but which office is supposed to check what really comes out of the server about us? Apart from technological competencies in state administration. As a web analyst myself, I cannot say that.
In the case of Client-Side, I had the opportunity to see what exactly is sent to individual endpoints - for example, using the Network tab in the browser console.
If data is sent from our server, i.e. outside the user's device, the user cannot see what is going out. He can only see the establishment of communication between the browser and our server. However, he does not know what is happening on the server itself - whether this data is somehow enriched.
It's all based on a little bit of trust. Just like today (apart from the political situation) - we are not sure if some unpredictable person will not use nuclear technology against another nation. I leave the effects of such action to your imagination.
I honestly admit that I underestimated the topic after listening to the podcast but when I opened the discussion on our AnalyticsLab group my eyes opened. That's why I'm sharing it here.
Translated from polish to english by Anna Bacciarelli-Ulacha
If you enjoyed the content please share it:
If you have any question about this topic feel free to comment or react below.
Facebook conversion tracking on the server side gives you oportunity to minimize usage of java script libraries on the client side and may reduce page load time. Running facebook conversion tracking codes on the server side may gives you better security for your clients data. You can have also more control over the data and decide which you want to send to facebook. Additional feature is that this solution minimizes the impact of ad blockers.
Implementation of Google Ads server side tracking has couple of advantages:
- it may help to improve your page load time by reducing the amount of code you have to run on client side
- it may reduce the impact of ad blockers
- you will have more control what kind of data you sending to external vendor
The standard, default Google Tag Manager implementation of GA4 is client side tracking. It means that client, in this situation: users browser like Google Chrome or Mozzila, is responsible for launching GTM/GA4 scripts and sending them to Google.
Environment - is a set of necessary elements of technical / software infrastructure, which is the basis for the operation of a given website/application. Google Tag Manager environments are simply multiple versions of the same container. When we have a website with a different version for development, testing, production and QA, instead of creating separate GTM containers for each version, we can set up separate environments in the same container that will work independently in each version.
If you plan email marketing campaigns you are interested in the same as with other campaigns, to measure their impact on your business. When you are starting with this topic it is good to know that without additional effort you will not be able to access this impact. You will see no results because Google Analytics will treat traffic from the email campaigns as direct traffic (when users are using your own app) or as referrals (when users are using web email clients).
Why now is the time to migrate to Google Analytics 4? Moving to Google Analytics 4 as soon as possible is essential in order to generate the necessary historical data before Universal Analytics stops processing new activities.