GTM server-side is a version of Google Tag Manager that runs in a server container you host, rather than entirely in the visitor’s browser. The browser sends its data to your server first, and the server decides what to forward to GA4, Google Ads, Meta and any other tool.
How GTM server-side works
In a standard set-up, every tool’s script loads in the browser and sends data straight to its own servers. With a server container, the browser sends one stream of requests, usually from the GA4 tag in your web container, to a subdomain of your own site such as data.yourbusiness.co.uk. That subdomain points to your tagging server.
Inside the server container, three pieces do the work:
- Clients receive incoming requests and turn them into event data. The GA4 client is the most common.
- Tags take that event data and send it on to each vendor, for example GA4, Google Ads conversions or Meta’s Conversions API.
- Transformations and variables let you change or remove fields before anything leaves, such as stripping parts of the IP address or email addresses that have leaked into page URLs.
The server runs on a cloud platform, most often Google Cloud Run, or with a managed hosting provider. You choose where it runs, and a London region is available on the main platforms. Because the server sits on your domain, it can also set cookies in a response header, which browsers generally treat more generously than cookies written by JavaScript, though Safari applies its seven-day cap to these too when the tagging server’s IP address is unrelated to your main site’s.
Why it matters
The main benefit is control. You decide exactly what each vendor receives, and fewer third-party scripts in the browser can help page speed. It is also the usual route for Meta’s Conversions API and other server-to-server conversion feeds, which recover some conversions that browser-only tracking misses.
It does not change the consent rules. Under PECR, data still starts on the visitor’s device, so analytics and advertising measurement still needs consent, and the server container should respect the consent state passed from the browser through consent mode. Using a server to send data that the visitor has refused is the same breach by a longer route. Under UK GDPR, the vendors you forward to remain recipients of personal data, so hosting the server in London does not remove the need for proper transfer arrangements with them.
There are running costs. Unlike the free web container, the server bills monthly for hosting, and the bill grows with your traffic. Someone also needs to maintain it.
Common mistakes
- Treating it as a way around consent refusals or ad blockers.
- Hosting the server on a third-party domain, which loses the first-party benefit.
- Sending the same conversion from both the browser pixel and the server without a shared event ID, so platforms count it twice.
- Under-provisioning the server so requests are dropped at busy times.
- Setting it up and never checking the hosting bill or the error logs again.
How to act on it
First decide whether you need it. A small brochure site with modest ad spend rarely does. A business spending meaningfully on Google and Meta ads, running many tags or handling sensitive data often does.
If it is worth doing, audit your existing tags and consent set-up first, then create the server container on a subdomain of your site in a UK region. Route GA4 through it first, test in the server container’s preview mode, then add ad platform tags with deduplication. Planning and building that set-up is part of the tracking work in performance marketing, where reliable conversion data matters most.