Server-Side GTM like a nuclear technology

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.

Source: https://developers.google.com/tag-platform/tag-manager/server-side/intro

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. 

Source: https://developers.google.com/tag-platform/tag-manager/server-side/intro

Is speeding up page loading time the only advantage?

Not.

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.

Someone will say - there is a privacy policy. I agree, but who will guarantee that what is written in the privacy policy takes place in reality?

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