Chapter 6
The server container in Google Tag Manager
 "Zoran Artmagic")
Table of contents
The server container is the foundation of the setup. This is where it is decided which data arrives, how it is cleaned and which platform receives what. Small errors in this foundation affect every single measurement.
What exactly does the server container do?
The server container is a separate container type in Google Tag Manager. It runs on the tracking server and acts as the receiving point: the web container in the browser sends its events there, so-called clients in the server container receive them and convert them into a uniform format. Triggers then fire the tags that pass the data on to GA4, Google Ads, Meta and other platforms.
Which building blocks are part of the setup?
Set up the subdomain: A DNS record connects a subdomain such as data.yourstore.com to the tracking server.
Create the server container and connect it to the hosting.
Adapt the web container: The Google tags in the browser send their data to the subdomain instead of directly to Google.
Configure clients: Usually the GA4 client, plus others for additional data sources or webhooks where needed.
Create tags and triggers: Tags per platform with the right events, parameters and consent conditions.
Clean the data: Truncate IP addresses, remove or hash personal fields, drop unnecessary parameters.
Test in the preview mode of both containers before anything goes live.
Where do most errors occur?
Our audits of existing setups keep revealing the same weak points:
Consent is only respected in the browser. The server container should receive the consent status and evaluate it itself. Otherwise, data protection depends on a single point.
Missing event IDs. Without a shared ID, Meta cannot merge browser and server events and counts purchases twice.
Incomplete user data for Enhanced Conversions. Google and Meta attribute conversions better when they receive a hashed email address, phone number and address, provided consent has been given. Without this data, the server forfeits much of its benefit.
Missing referral exclusions. Payment providers appear in GA4 as the referral source for purchases.
Preview was never checked against live operation. What fires in preview mode does not automatically arrive in the ad account.
How does the server container relate to the Tag Gateway?
If you use the Google Tag Gateway, you can combine it with the server container. Google scripts are then also loaded via your own domain, and measurement data reaches the server via a path on the main domain. In Safari, this improves the chances of longer-lived cookies set by the server. Whether the extra effort pays off depends on your share of Safari users and your existing setup.
Who should set up the server container?
Companies often manage the setup themselves up to a certain point. After that it gets demanding: configuring the clients, the consent logic on the server, deduplication and passing on user data all require experience with every system involved. Errors rarely show immediately; they surface weeks later as distorted numbers. If you set it up yourself, have the result reviewed by someone who has seen many such containers.
Server container checklist
Subdomain set up with the hosting provider and in DNS
Server container created and connected to the tracking server
Web container sends to your own subdomain instead of directly to Google
Consent status is passed to the server container and evaluated there
Tags for all ad platforms set up with event IDs for deduplication
Hashed user data passed to Enhanced Conversions and the Meta Conversions API where consent is given
IP addresses and unnecessary parameters cleaned before forwarding
Frequently asked questions
The web container runs in the browser and captures events; the server container runs on the tracking server and distributes them to the platforms. In a server-side setup, the two work together.
The web container, yes; it gets adapted. The server container is created in addition.