Server-side GTM
Server-side tagging moves tag execution off your users' devices and onto infrastructure you control. Done properly it recovers attribution the browser throws away. Done as a box-ticking exercise it just adds a hosting bill.
What it is
Normally, every tracking tag runs in your visitor's browser and sends data straight to the vendor — Google, Meta, whoever. The browser is doing the work, and the browser is increasingly hostile to it.
Server-side GTM puts a second Tag Manager container on a server you control, usually on a subdomain of your own site like sst.yourdomain.com. The browser sends one request to your endpoint; your server decides what to forward, to whom, and with what attached.
Three things change as a result. Data leaves from your infrastructure rather than your users' devices. Cookies can be set by your server rather than by JavaScript. And you get a filtering point between your site and every vendor, where you decide exactly what each one receives.
Safari's tracking prevention deletes cookies and other storage written by JavaScript after seven days of Safari use in which the visitor doesn't come back to your site, and caps them at 24 hours when a link carries tracking parameters. If your sales cycle is longer than a week, a meaningful share of your conversions can end up attributed to Direct instead of the campaign that earned them. Cookies set by your own server can last longer, provided the endpoint is set up properly: Safari applies its own seven-day limit to server-set cookies if the endpoint looks like a disguised third party, which is why the domain and hosting set-up matters.
Ad blockers are the other half. Many block requests to known tracking domains outright, so those conversions are never recorded at all. A first-party endpoint isn't on those lists by default.
The third benefit is quieter but often the one clients value most: you finally get to see, and control, exactly what data is being sent to each advertising platform.
One thing we'll always say up front: server-side tagging is not a way around cookie consent. Moving where a tag runs doesn't change your legal obligations — if you're storing or reading information on someone's device, or processing personal data for advertising, you still need a lawful basis and, in the UK and EU, consent for non-essential purposes. Anyone selling sGTM as a consent workaround is selling you a compliance problem.
How we help
We take your actual traffic and work out what running this will cost per month on Google Cloud Run, or on managed hosting if that suits you better. Then we set that against the conversions you're currently losing. If the numbers don't stack up, we'll tell you, and you'll have spent nothing.
A server container on a subdomain of your site, properly provisioned with autoscaling and a sensible minimum instance count so you're not paying for idle capacity or dropping requests at peak. SSL, DNS and monitoring configured and documented.
Not everything moves at once. We run client-side and server-side in parallel, compare the numbers until we're confident, and move tags across in a sequence that keeps your reporting comparable throughout. No reporting blackout mid-quarter.
Meta Conversions API, Google Ads, TikTok and LinkedIn server-side events — with proper event deduplication so you're not double-counting against the browser pixels, and with clear decisions documented about what data each vendor receives.
Consent signals carried through to the server container so a user who declined advertising cookies doesn't have their data forwarded anyway. This is the part most sGTM builds get wrong, and it's the part that matters if anyone ever asks.
Monitoring and alerting so you know if the container stops responding, documented runbooks for the things that go wrong, and a training session. Server-side tagging is infrastructure now — it needs an owner, and that owner should be you.
Process
Measure what you're losing now, model the running cost, and decide together whether it's worth doing at all.
Server container, subdomain, SSL, DNS, autoscaling and monitoring — built and documented.
Client and server-side running side by side, numbers compared daily until we trust them.
Tags moved in sequence, consent verified end to end, then documentation and handover.
Questions
No. Moving where a tag executes doesn't change your legal obligations. If you're storing or reading information on a user's device, or processing personal data for advertising, you still need a lawful basis and, in the UK and EU, consent for non-essential purposes. We build consent signalling through to the server container as standard.
It's an ongoing infrastructure cost, not a one-off. Google's own setup guidance puts each Cloud Run server at roughly $45 a month and recommends running at least two, so expect around $90 a month as a floor, rising with traffic. Managed hosting providers can be cheaper for smaller sites. We estimate your likely cost from your real traffic before you commit to anything.
It usually recovers some, and how much depends on your audience. Sites with a lot of Safari and iOS traffic, or a technical audience running ad blockers, see the biggest gains. If your traffic is mostly Chrome on Android and your consideration window is short, the gain may not justify the cost — and we'd rather say that before you spend than after.
Yes, in almost every case. The client-side container still captures the events and forwards them to your server container. Server-side tagging changes where tags execute and what leaves the browser — it doesn't remove the need to capture what people do on the site in the first place.
You do — it runs in your cloud account, on your domain, under your billing. That's deliberate. We'll set up monitoring and alerting and write the runbooks, and we can stay on retainer to watch it, but you should never be in a position where your conversion tracking lives somewhere only your consultant can reach.
We'll look at your traffic mix and tell you honestly whether the numbers stack up. Free, and there's no pitch at the end if the answer is no.