Google’s Server Side Tag Manager is a very exciting new product. We want to have a deeper look at the operating cost.
The new Google Tag Manager Server (a. k. a. server-side GTM) promises to maximize the control that website owners have over their analytics data. It helps in collecting important tracking information in a GDPR-compliant way. Those benefits come from shifting core analytics functionality from the users’ devices to a server that is controlled by the website owner – the server-side GTM.
While using the server-side GTM software is free, you will need to pay for the usage of the required cloud resources. Therefore, the additional control comes with a price tag that deserves closer analyses before diving head-first into this new piece of tech.
In this article, we will have a look at the cost for a server-side GTM deployment using Google Cloud’s App Engine Flexible Environment, which is Google’s recommended way of deployment. However, you can run it in any environment that supports Docker containers like Cloud Run or in AWS, Azure, or even on-premise.
How much will the server-side GTM cost for your website’s traffic? According to our Trakken field-research, we already saw a huge development in performance. When we started working with the server-side GTM it was able to serve around ~25 requests per second and instance for a standard Universal Analytics set-up and ~5-10 requests per second for a standard GA4 set-up. After some releases from Google, this improved a lot. Now it can serve up to 40 incoming requests per second with one instance for Universal Analytics and ~20 requests per second and instance for GA4. Very simplified you can imagine one instance as one virtual machine. A standard setup implies using the server-side GTM solely to receive and forward Google Analytics hits while aiming for a CPU utilization of 60 % per instance.
We are still a bit off from the 100 requests per second that Google claims in its documentation for the server-side GTM, at the time of publishing this article.
According to our findings, one instance running an entire month will be enough to serve a website generating up to 64,800,000 hits (25 hits * 60 seconds * 60 minutes * 24 hours * 30 days). In the Frankfurt data center, you pay 0.0675 USD per hour and instance (0.063 USD per core + 0.0045 USD for 500 MB of memory) that is running. This amounts to about 48 USD per month. 64.9 Mio hits sound like a lot but there are some things to keep in mind:
The standard setup will get you up to ~40 requests per instance and second. As soon as you add custom logic or more than one tag to your server-side GTM configuration, the performance will decrease noticeably. In a future article, we will elaborate on the impact of custom logic on the performance of your server-side GTM.
The App Engine scale slowly. It takes several minutes for the App Engine to create a new instance. For example, if your traffic grows by 50 % within a few minutes, the App Engine will not be able to serve the traffic growth until the required instances are created. This excess traffic will not be measured. To somewhat capture this, Google recommends running at least 3 instances at any time, regardless of your actual traffic.
In a real-world example, our traffic will not be distributed equally across a day. We will have peaks in the morning and afternoon. We will have almost no traffic at night. Realistically, the traffic curve of a website that never exceeds 25 (or now 40) hits per second that a single instance can serve might look more like the blue line in the chart below. The blue line corresponds to a monthly volume of 25 Mio hits per month. However, if you follow the recommendation of 3 instances running at all times, you will also pay for them, even if you have almost no traffic at all at night.
The importance of your traffic distribution and the minimum number of instances you have running at any time decreases with increasing traffic and will be negligible if your website always generates enough traffic to keep the minimum instances busy.
Egress is the data that your server-side GTM sends to the users’ browsers. It is billed per Gigabyte. A Frankfurt-gigabyte costs 0.12 USD. If you only respond to tracking hits from your server-side GTM the egress cost should be negligible. If you use the server-side GTM to serve files, like the gtag.js or the gtm.js, the cost will grow. For example, 1 GB of traffic is enough to serve a gtm.js of 100 KB 10,000 times.
If you do not disable logging every request will be logged. You can disable logging when deploying the server-side GTM to an App Engine. We observed around 7.5 GB Log Volume per 1 Mio Hits. This will cost you around 220 $ for 65 Million Hits. See Google documentation on how to disable it.
Google has released some major improvements regarding performance. It looks like the performance has increased significantly: With a GA4 set-up, it is now able to serve ~20 requests per second and instance, before only 5 -10. With a Universal Analytics set-up, it is now serving ~30 -40 requests per second and instance, before ~25. The auto-scaling behavior has improved a lot as well: We haven’t seen any errors anymore due to slow scaling. Before the update traffic peaks caused a lot of errors. We are all very excited about the upcoming releases of the server-side GTM.
Incorporate the update from 10.02.2021 into the article to have the newest performance observations included. And clarifying the performance numbers before and after the Google update.
|Hits Per Month|
|Egress Hit Size in byte|
|cost per egress GB||
|Cost per App Engine Instance per month||
|Request per sec per Instance|
|cost app engine (e-commerce curve)||
|Estimated total cost per month||