Server-side tagging with Google Tag Manager: what it really improves, and what it does not

Over the past two years server-side tagging has gone from specialist topic to standard line item in agency proposals. The trouble is that it is nearly always described badly: as a way to "recover lost data", sometimes even as a way to get round consent banners and ad blockers. Neither is a good reason to do it. There are good reasons, though, and they are worth separating carefully.

What it is, without the marketing

With traditional, client-side tagging, the visitor’s browser loads the Google Tag Manager container and each tag sends its data straight to its vendor: Google Analytics, Google Ads, Meta, LinkedIn and so on. Each vendor receives the request from the browser, along with everything the browser carries.

Server-side tagging adds a second container, of the server type, which runs on cloud infrastructure you control and answers on a subdomain of your site — say measure.yoursite.co.uk. The browser sends a stream of events to that server; the server receives them through clients (the components that parse incoming requests) and forwards them to vendors through server tags, deciding what to pass on and in what shape.

One detail that tends to get lost: the web container does not disappear. In the most common setup the browser still loads the Google tag, which simply sends its data to your server instead of to Google. Server-side does not replace the client side; it slims it down and brings it under control.

What it genuinely improves

First-party context and cookie lifetime

Safari’s Intelligent Tracking Prevention caps cookies set through JavaScript at seven days. A user who clicks an ad and comes back to buy ten days later is, as far as the tag knows, a new user: the conversion loses its link to the click. A cookie set by your own server through an HTTP header can last longer.

With a condition many projects overlook: since Safari 16.4, server-set cookies are also capped at seven days if the tagging server’s IP address does not match the first half of the site’s IP, or if the subdomain is a CNAME pointing to a third-party host. A container on Cloud Run attached to a site hosted elsewhere often fails that check. The cookie benefit is real only if the architecture is designed for it — for instance by serving the container on the same domain as the site, through the load balancer or CDN that already fronts it.

Control over what reaches vendors

This is the most underrated benefit and, to our mind, the most important one. In the client-side model every pixel receives IP address, user agent, full URL with whatever parameters it carries, and referrer, straight from the browser. In the server-side model you decide: strip parameters holding personal data that ended up in a URL by mistake, truncate the IP, drop fields a vendor has no need for, add product margin to the conversion value without exposing it in the page.

Page performance

Every third-party pixel you remove from the browser is JavaScript that no longer has to be downloaded and executed. If the site currently loads Google Ads, GA4, Meta, TikTok and LinkedIn, moving to a single stream to your server and distributing from there can materially lighten the main thread. If the site loads only Google tags, the gain is modest: do not expect miracles on Core Web Vitals.

Data quality for conversions

A server-side stream is also the natural home for vendors’ conversion APIs and for joining first-party data in an orderly way, which fits neatly with enhanced conversions and the Data Manager API. It does not conjure conversions out of nothing; it makes collection of the ones you already measure more reliable.

What it does not do, and should not do

• Consent Mode still applies. Consent state travels with the requests reaching the server, and Google’s server-side tags honour it. For other vendors’ tags, behaviour depends on the template: often it is on you to gate sending on consent state. This is where we see the most mistakes. The groundwork is in our guide to Consent Mode v2 and the DMA.
• GDPR still applies. IP addresses and cookie identifiers remain personal data. What is more, the server is an additional processing activity: you need a data processing agreement with the host, an EU region, an entry in your record of processing and a privacy notice that describes the actual flow.
• It is not an ad-blocker workaround. Some requests may get through because the domain is yours; building a strategy on that means ignoring an explicit user choice. That is not ground we take clients onto.
• It does not fix broken tracking. If the events in the dataLayer are incomplete or duplicated, the server will forward them incomplete or duplicated, with a hosting bill on top.

What it costs

Costs come in three parts: infrastructure, initial setup and maintenance. Only the first has a price list.

On Google Cloud Run, the option Google documents, the production recommendation is to keep at least two instances running to reduce the risk of data loss if a server fails. Each instance, at 1 vCPU and 0.5 GB of memory with CPU always allocated, costs roughly $45 a month according to Google. Autoscaling between two and ten instances handles, per the same documentation, 35 to 350 requests per second, depending on how many tags you run and what they do.

Alternatively there are managed providers that specialise in hosting server containers, typically priced on request volume. They remove the sysadmin work and often add useful tooling; in exchange you add another party to the processing chain, to be assessed contractually like any other processor.

The line nobody puts in the proposal is maintenance: updating the server image, checking vendor templates keep pace with their APIs, confirming after every site release that the event stream is intact. It is ongoing work, not a one-off project.

When it is worth it, and when it is not

It pays off when at least two of these hold:

• Ad spend is high enough that a few percentage points of better-measured conversions are worth more than a few hundred pounds a year of hosting and upkeep.
• You run several ad platforms beyond Google and want a single control point over what they receive.
• A meaningful share of traffic is Safari or iOS and purchase cycles run longer than a week.
• You have concrete data-minimisation needs towards vendors — in healthcare or financial services, for example.

It does not pay off, or not yet, when the site runs only Google tags, conversion volume is low and nobody in-house can look after it. In that case the alternative is Google tag gateway for advertisers: it lets you load Google tags from your own domain through your CDN, Cloudflare for instance, with no server to manage. It covers Google tags only, but for many accounts it is the right compromise.

Implementation checklist

1. Sort out client-side tracking first: events, parameters, values, deduplication. The server amplifies whatever it receives.
2. Choose hosting and region: an EU region — Milan or Frankfurt, say — and a data processing agreement with the provider.
3. Design the domain with Safari in mind: the same domain as the site, or a subdomain whose IP is compatible with the site’s, not a CNAME to a third-party host.
4. Set up production and preview as separate services, with a minimum of two instances in production.
5. Point the Google tag at the server via the server container URL setting, and check in preview that requests reach the GA4 client.
6. Handle consent tag by tag: confirm Google tags honour the state they receive, and explicitly gate every other vendor’s tag.
7. Apply minimisation: strip personal data from URL parameters, truncate IPs where not needed, send each vendor only what it requires.
8. Trim Cloud Run logging to the useful minimum, or logging will outcost the instances.
9. Compare numbers for two to four weeks against the previous setup and your back-office data before switching the old pixels off.

The mistakes we see most often

• Double counting: the old client-side pixel stays live next to the new server-side tag and conversions double. Smart Bidding is grateful, then gets every bid wrong.
• A single production instance to save $45 a month: events are lost at the first restart and nobody notices.
• "Server-side" cookies that still last seven days because the domain fails Safari’s IP check. You pay for the project without collecting its main benefit.
• Third-party tags ignoring consent, on the assumption that the server "handles consent on its own".
• No monitoring: the server is a production system, and if it stops, measurement stops with it. At the very least, set an alert on request volume.

Done well, server-side tagging is one of the few changes that improves data quality, control and compliance at the same time. Done to chase a promise of "recovered data", it is an added cost with added risk. In our free audits we check first whether you need it, then how to do it: you can see how we approach measurement and the answers to common questions in the site’s FAQ.