Recently, the Google Tag Manager Server-Side (GTM Server-Side) tool has been gaining increasing attention. In this article, I'd like to share my initial observations and the early results from deploying GTM Server-Side for our client meblobranie.pl. We implemented this solution in early August, so the data presented here originates from an environment that has been operational for about three months.

How does Google Tag Manager differ from Google Tag Manager Server-Side?

In short, the Google Tag Manager (GTM) comes in two versions: Client Side and Server Side. In the Client Side version, tracking codes are executed directly in the user's browser, collecting data and forwarding it to various analytical platforms. On the other hand, with the Server Side version, codes run on the server, allowing for centralized processing and data dispatching. As a result, GTM Server Side can provide better privacy, data control, and performance compared to the Client Side version. For those unfamiliar with this topic, I recommend acquainting oneself with one of the many articles published recently or notes from Google, which explain this matter and discuss the pros and cons of this method.

Adopted Google Tag Manager Server-Side Configuration:

For the standard GA4, we send an average of about 300,000 events per day. To minimize costs and have the capability of easy scaling, we decided to implement in Google Cloud - Cloud Run. We chose the following settings:

  • Production: minimum 2 instances, maximum 5.
  • Preview: minimum 0, maximum 1.
  • Chosen region: Warsaw (europe-central2).
Screenshot of the Google Cloud Run container management panel. It includes settings such as CPU allocation, CPU boot time, concurrency, request timeout, and execution environment. Additionally, it presents auto-scaling options with a minimum and maximum number of instances.

Unfortunately, in the Warsaw region, the easy mapping feature of a custom subdomain to a Google Cloud Run application is not yet available. To avoid fees for the GCP Load Balancer (a tool that distributes web traffic over several servers to ensure the smooth and continuous operation of a website, in this case, it would direct traffic from the chosen subdomain to our Google Cloud Run instance), we used Firebase Hosting to map the subdomain address to Google Cloud Run (more information here).

Objectives:

We decided to test the readiness and performance of our solution by adding parallel signal dispatching from GTM Server-Side directly to BigQuery.

In addition to the existing GA4 instance, we deployed an additional GA4 service (referred to as GA4 Server-Side), to which signals were only delivered by GTM Server-Side. Both solutions operated simultaneously, allowing us to compare results. Events for GA4 and GA4 Server-Side were initiated by the same triggers. We decided that cookies and identifiers for GA4 Server-Side would be managed by the server, not by the JavaScript code.

Preliminary Results:

For the analysis, I selected data from September 1st to October 31th. This should make the number of returning users in GA4 Server-Side more comparable to the results from the traditional GA4 service. Moreover, the impact of server-managed cookies will become more noticeable. After a month of testing, we can observe the following benefits from deploying Google Tag Manager Server-Side:

  1. Better visibility of user behavior using Safari. In standard GA4, the average time from seeing an ad to making a purchase for our client is about 5 days. Meanwhile, in GA4 Server-Side, this time extended to 7 days, approaching the behavior of users not using Apple products.
  2. Smaller discrepancy between data from CRM and GA4 Server-Side compared to the data discrepancy between CRM and standard GA4. This gap reduced by 2%. Although for our client the differences in data between CRM and GA4 were not significant, I know that for others it can be crucial, and GTM Server-Side might be the solution.
  3. Registration of a larger number of active users and sessions. GA4 Server-Side recorded a 23% increase compared to standard GA4. Preliminary analysis indicates that these might be users using various ad blockers.
  4. Higher percentage of returning users. In traditional GA4, it was 23%, whereas in GA4 Server-Side it reached 30%. This provides deeper insight into the behavior of users with more complex purchasing paths.

Costs:

At peak traffic moments, a maximum of four production instances were running (this happened twice), but for the majority of the time, only two instances were operational. This resulted in an average monthly cost of about 100 euros.

Chart showing the number of active instances in the Google Cloud Run container where GTM Server Side was operating. The data shows that in September 2023, the maximum number of active instances was 4, reached only once.
Chart showing the number of active instances in the Google Cloud Run container where GTM Server Side was operating. The data shows that in October 2023, the maximum number of active instances was 4, reached only once.

Summary:

Based on initial observations, I can conclude that the Google Tag Manager Server-Side is a tool with tremendous potential. It allows for a better understanding of user paths, reduces discrepancies in data from different sources, and increases information about users. To fully confirm these conclusions, a thorough data analysis is necessary. In upcoming publications, I'll present more detailed information and conclusions.

What's Next?

Soon, I'll share experiences related to the implementation of GTM Server-Side in a Kubernetes cluster. On one hand, we don't incur additional costs as the client's platform is placed in the cluster. On the other, we safeguard against the latest announcements from Apple, stating that if the IP addresses of the analytical subdomain significantly differ from the main domain, data from 1st party cookies might be blocked.

If you're interested in deploying GTM Server-Side in your company but lack the resources – feel free to contact us. We'll gladly assist at every stage of the project.