A sophisticated lie

When Google came a long with the serverside Google Tag Manager (SGTM) I was hyped.
Finally we could avoid sending the same data multiple times from the users browser to different platforms like GA4 or Facebook.
Sadly this wasn’t really the case. In reality the amount of pixels and tags did not really change. Clientside GTMs looked bloated like before.

Long life the cookie

Secondly GTM users faced the problem that Apple was reducing the lifetime of marketing cookies like the _ga cookie to 7 browser days. Consequential markteers looked for ways to make these cookies as persistent as before.
And here SGTM was a valid solution for more then a year until the intelligent tracking prevention from Safari was updated and a subdomain alone wasn’t enough anymore to circumvent restrictions to the cookie lifetime.
As of now the ip address of the SGTM server setting the cookies in the reponse must match at least 2 octetts of the ip address of the webserver providing the website.

Much business value, much wow

Another reason for using SGTM was the potential option to enrich data reaching the server with Firestore. As a non-sql databse Firestore is better solution then BigQuery, or other SQL based databases. So what is the catch? There are so little use cases, why you would need to do enrichment on the server. For most scenarios doing the enrichment in the browser is not only possible but preferred. You would save money, because we don’t need to pay for the infrastructure for the SGTM nor the Firestore usage. An exception would be, if you have sensitive data you don’t want to expose to the client. But even then you need to ask yourself the question, if the enrichment is really needed before the data is saved. Still not convinced? Let’s look at the integration of Firestore in SGTM. Is it really that good? From my perspective it isn’t. The problem with it is the way how variables are being dealt with by GTM. You would think that when a request reaches the server and we have several different tags using that event as a trigger, that the variable is only evaluated once. This is not the case. In reality the variable is processed for every tag seperatly. If the variable is used in another variable there will be another evaluation. You already see where this is going: A crazy high amount of Firestore read operations are triggered, because everytime the variable is newly evluated a new read operation is executed. Firestore can handle that in most cases, but can your wallet? The free tier of Firestore is exhausted relativly fast. Let’s look at an example: We have only use Firestore for SGTM enrichment for GA4, Google Ads and Facebook. For every request we would have 3 tags running then. This GA4 property has 770.000 events per day. We have 3 Firestore variables we want to read and add to our request but we do something with them in another variable which hook up to the tags So that would mean that we would have 770.000 x 3 variables x 3 tags x 3 referencing variables x 3 reads per variable = 62.937.000 reads / 0.03 per 100.000 requests = 18.88€ per day.