Real benefits, just promises and risks of using sGTM

Dear Data-Traveller, please note that this is a LinkedIn-Remix.
I posted this content already on LinkedIn in October 2022, but I want to make sure it doesn’t get lost in the social network abyss.
For your accessibility-experience and also for our own content backup, we repost the original text here.
Have a look, leave a like if you like it, and join the conversation in the comments if this sparks a thought!

Link to Post

Screenshot with Comments:

Screenshot of Timo Dechau's post on LinkedIn with text about server-side Google Tag Manager

Plain Text:

It’s Monday, so let’s talk a bit about server-side Google Tag manager.

The sGTM is pretty likely on a lot of online marketing salvation lists. Because it promises solutions to the loss of data these groups have experienced over the last years. So what is beyond these promises, and are these promises at all?

What is sGTM:
Compared to the “normal” client-side GTM, this tag manager is deployed on a server. A server that you run. In the automatic setup, this will be an AppEngine Server in a Google Cloud Project. But sGTM comes as a Docker container so that you can run it everywhere you can run Docker containers (yes, also on a Raspberry Pi).

What are the real benefits:
– Control over data sent out – JavaScript tags you add to your website can live on their own when they invoke different other scripts and basically share your website data with the world. In sGTM, you have complete control over the data you send out.

– Control over privacy aspects – you can mask or remove personal data before you send it out to other destinations – this became famous in the whole Google Analytics discussions.

– Remove sensitive data from the frontend – do you have some interesting data in the frontend like Customer Lifetime, Margins, and Stock information, you need to send them to your analytics. With sGTM you can move the enrichment to the server and away from bots scanning them (yes, they do such things).

– clean up your clients – 300 tags, great idea. And also great at loading the GTM data and handling all these requests in a browser currently running on a low 4G connection. sGTM can move payload and requests away from shaky frontends.

What are just promises:
– You get more data – yeah, you might get a bit more data when you do the setup using your domain because some AdBlockers now might ignore you (as always a matter of time, since GA requests look like GA requests). And trust me, 5-10% more data often does not change the segments a lot for random analytics.

– Consent does not apply to server-side > Yes, I heard that quite often already. Consent is a legal topic and is not bound to specific tech like a browser. Of course, consent applies to the server side (also to the data you collect at your summit booth).

What are the dangers:
– Moving tracking away from the frontend to the backend makes a lot more things invisible (Rick Dronkers covers this a lot in his podcast). So wild west again? For some people, yes. So this introduces more responsibilities to the people implementing it. And to anyone who likes to play rouge here (and ignore any consent) – things come out at some point. They always do.

So – Big question – Should we move to sGTM?
At some point, most likely. But make it a step-by-step process. Remember, you have to run a server. App Engine (the standard way) is pretty solid, but if something is not working, your tracking is still not working. And it’s on your end.