Academy · Google Tag Manager · Lesson
Server-side tagging: what it fixes, what it does not, and when to skip it
How a GTM server container works, why the first-party domain matters, what you gain on cookies, ad blockers and speed, what does not change about consent, what it costs and when a small business should wait.
The situation
You have done everything right in GTM. And yet a meaningful share of paid sessions is missing in GA4 compared with Google Ads clicks, on Safari returning users show up as "new" after a week, and the speed test complains about third-party scripts. Someone tells you "move to server-side". They are half right — and the wrong half costs money every month.
What it actually is
In classic (client-side) tagging, the visitor's browser sends data directly to Google Analytics, Google Ads, Meta. Each platform puts its script on the page and sends its own requests.
In server-side tagging, the browser sends the data once, to a server of yours: a GTM Server container hosted under your domain, for example data.yoursite.com. That server receives the event, cleans it, enriches it if you want, and distributes it itself to GA4, Google Ads, Meta Conversions API and anyone else. The browser only talks to you.
The full flow:
- The site does
dataLayer.pushas before. - The GTM web container sends the GA4 event not to Google but to
data.yoursite.com. - The server container receives the request through a client (the component that understands the GA4 format) and turns it into a common event.
- The tags in the server container (GA4, Google Ads, Meta CAPI) forward the data, from the server, to each platform.
- The server can set first-party HTTP cookies in its response to the browser.
What it fixes
- Cookie lifetime on Safari. Safari caps cookies set from JavaScript at 7 days. Cookies set by a server on your own domain can live longer — with a nuance: Safari also checks whether the server answers from an address close to the site's own, which is why some setups put a shared proxy or CDN in front. The result, when done well: returning users stay returning, multi-day attribution works.
- Ad blocker blocking. Many block the well-known domains of measurement platforms. An endpoint on your domain is not on their default lists. Not immunity — lists evolve — but you recover a significant share.
- Page speed. Fewer third-party scripts loaded in the browser, fewer requests from the visitor's device. The effect is real but moderate: it does not make a slow site fast.
- Data control. On the server you decide exactly which parameters go to each platform. You can drop fields, normalise, add data from your own systems (the real order value after discounts, customer status).
- One place for Meta Conversions API and other server-to-server APIs, next to the rest of the tags.
What it does not fix
Nothing else changes magically: if the events on the site are wrong (a form counted twice, purchase without a value), the server forwards them just as wrong, only more reliably. Fix client-side measurement first.
What it costs and where to host it
The server container is free in GTM. What you pay for is the server it runs on:
- Google Cloud Run — the path officially recommended by Google, with setup started from GTM. For production you need several instances for redundancy; cost grows with traffic, from a few tens of euros a month for a small or medium site.
- Managed hosting from a specialised provider — a fixed monthly subscription, no infrastructure to manage; some providers use global networks such as Cloudflare for the first-party route. For a business without a technical team, often the simplest option.
- Self-hosted on any infrastructure that runs the official Docker image, with a proxy or CDN (for example Cloudflare) in front for the first-party domain and certificates.
Add to the cost: implementation time (a few days for a complete setup with GA4, Google Ads, Meta CAPI and consent), maintenance (image updates, monitoring) and the subdomain (a DNS entry on your domain, with a certificate).
When a small business should skip it
Server-side is worth it when you have volume and money at stake: ad budget from a few thousand euros a month upwards, significant Safari and mobile traffic, a checkout or forms whose attribution genuinely changes budget decisions.
It is not worth it — yet — if:
- you have under a few hundred conversions a month; statistical noise is larger than what you recover;
- basic client-side tracking is not correct (see the tracking checklist);
- you do not have Consent Mode v2 configured properly — that is step zero and recovers more than you think, through modelling;
- nobody will maintain the server; a server container that is down means zero data, not "like before".
What to remember
- Server-side = the browser talks once to your server, which distributes onwards.
- It fixes cookie lifetime, part of the blocking and speed; it does not fix wrong events.
- Consent applies identically on the server. It is not a loophole.
- The real cost: server + implementation + monthly maintenance.
- A small business first gets events and Consent Mode v2 right, then server-side when volume justifies it.
Check yourself
Frequently asked
Does server-side mean I can track visitors who refuse cookies?
No. A refusal is respected regardless of where the data passes. What you can do legally is what Consent Mode allows: pings without identifiers and aggregated modelling, same as client-side.
If the server goes down, what happens to the data?
They are lost for that period, for all platforms at once. That is why production needs redundancy and monitoring, and someone must respond when something is wrong.
Want Valhalla to check this for your business?
Valhalla Pulse scans the public signals of your website for free, in seconds.
Sources
Related lessons