Server-side tracking: how it works, and when it is worth the cost
Server-side tracking as it actually runs: the request path, what it recovers, what it leaves broken, and what it costs. I host Google Tag Manager server containers on my own infrastructure, carrying production traffic. Most of what follows comes from running them.
What is actually breaking in browser-side tracking
A browser-side setup rests on three assumptions, each of which now holds less often than it did:
- The vendor's JavaScript loads. Extensions and network-level filtering on a share of machines stop the script outright.
- The cookie survives. Safari's Intelligent Tracking Prevention has held cookies written by JavaScript to seven days since 2019, so a visitor returning outside that window counts as a new person and the first visit's source is gone. Firefox blocks known tracking hosts from a maintained list, removing cookie and request together.
- The request to google-analytics.com or facebook.com leaves the machine. The share of visitors dropping those calls varies by audience: a developer or privacy-conscious crowd loses far more than mainstream retail.
Consent sits apart from those three: a decline is the correct answer, not a fault, but those events do not arrive either. Tags report success throughout. The gap only shows when platform-reported conversions are put next to the order table.
How server-side tracking works, request by request
Server-side tagging moves where the vendor tags execute. The browser stays in the chain. Following one event through shows what changes.
The page still loads a container
In a Google setup, the web container or the Google tag, still client-side. An event hits the data layer, a trigger fires, JavaScript prepares a measurement request.
The request goes to the site's own hostname
The transport URL sits on the site's own domain, such as data.example.com, resolving to a machine the site owner controls. Same measurement request, new address.
A client claims the request
A client parses the request into an event object: event name, page data, parameters, consent state. GA4 and the Google tag have built-in clients; custom clients handle other shapes.
Server tags make their own outbound calls
Server tags read that event object and call each vendor directly, machine to machine: GA4, the Google Ads conversion endpoint, Meta's Conversions API. The browser takes no part.
The server sets the identifier
Cookies come back in the HTTP response, from the site's own server rather than a page script. Safari treats such cookies differently, covered below.
Step one is the constraint. The chain still begins with a request the browser has to make; only later steps become more durable.
Client-side and server-side, side by side
The two models are often presented as opposites. In practice a server-side setup keeps most of the client-side one and changes the last leg.
Where tags run
Client-side, every vendor tag in the visitor's browser. Server-side, one request out of the browser, tags running on a machine the site controls.
Who sets the cookie
Client-side, JavaScript writes it, exactly what Safari's seven-day cap targets. Server-side, an HTTP response from the site's own host.
What leaves the page
Client-side, a request per vendor, carrying whatever that tag collects. Server-side, one request to one hostname, payload set in the container.
What blockers see
Client-side, recognisable scripts and hostnames on public filter lists. Server-side, a first-party hostname that is harder to list.
Control of the data
Client-side, whatever each vendor's tag sends. Server-side, a payload that can be trimmed, hashed or dropped before it leaves the business.
Cost and upkeep
Client-side, no infrastructure, no bill. Server-side, a host to pay for, an image to update, a component that can fail unwatched.
What server-side tagging recovers, and what stays broken
The gains are real and narrower than the sales pages suggest:
- Cookie lifetime on Safari: a cookie set in an HTTP response by a genuinely first-party host escapes the script-cookie cap.
- Requests that filter lists would have dropped now go to the site's own hostname, and a proportion get through.
- Meta match quality, where the Conversions API is fed from the server and deduplicated against the browser event by ID.
- Enhanced conversions through the server container, attaching hashed customer details so Google can match the conversion to a click.
The list of things that do not change is longer:
- A visitor who declines consent has still declined. Sending their data from a server does not alter that.
- A blocker that stops the page container from running takes the whole chain with it.
- Apple's Private Relay still masks the IP address.
- Cross-device and cross-browser identity is no closer than it was.
- An event schema that was wrong stays wrong. The server forwards what it is handed.
Recovery quoted as a single percentage is marketing. What comes back depends on one audience's browser mix, blocker rate and consent rate. A measured parallel run is the only way to find the number.
Why the endpoint has to be genuinely first-party (the CNAME problem)
The cheap way to give a server container a first-party address is a CNAME: point data.example.com at a hostname the vendor operates, and the browser sees the site's own domain.
Safari closed this in version 14 (November 2020). A subdomain resolving through a CNAME to a host outside the site's own scope has its response cookies held to seven days, the exact limit the setup was bought to escape.
The durable arrangement points the endpoint at infrastructure the site owner controls, on the same registrable domain, setting its own cookies. Mine sit behind Cloudflare and nginx on my own machine, with DNS pointing at that machine and not at a vendor.
Stronger again is serving the endpoint from a path on the main origin, with no subdomain to inspect at all. That puts a proxy in front of the live site, and many teams will decline.
Establish this before signing anything. A managed product that asks only for a CNAME is describing the configuration Safari singled out.
The ceiling deserves sobriety too. A first-party cookie is not permanent, Safari applies further limits including bounce-tracking protection, and Chrome's position on third-party cookies has changed direction more than once.
What it costs: hosting, the container, and who maintains it
Three costs sit behind this, and the pages selling it tend to mention one.
The first is the build. Standing up a Google Tag Manager server container is configuration: the client, the tags, consent handling, and the testing that shows server events match browser ones. Fixed work, with an end.
The second is hosting, which is recurring and where the three common routes diverge sharply.
A small rented server
Mine runs on a single VPS behind Cloudflare, shared with other services, for single figures to low tens of pounds a month. The cheapest route; it assumes comfort with Docker, DNS and a reverse proxy.
Someone else runs the container
Several vendors sell hosted server-side tagging as a subscription. More than a VPS, no operational work; ask the CNAME question above before signing.
App Engine, the default route
Google's setup flow deploys to App Engine; its production guidance is a minimum of three instances, and the bill follows request volume. Easy to procure, easy to underestimate.
The third cost is upkeep, and it is the one that gets left off:
- Container images need updating.
- Certificates and DNS need to keep working.
- Something has to check the endpoint is still answering. A container that has quietly stopped forwarding looks exactly like a slow week in the ad account.
I have been running this setup for about seven months, including a Meta Conversions API gateway I wrote and maintain. The ongoing work is small and recurring.
Signs a business does not need it yet
For a good number of sites this is expense without a return, at least for now.
The volume is too small for recovery to show
A site converting a few dozen times a month gets back a handful of events, lost in week-to-week variance. Nobody can point at the improvement afterwards, and the hosting bill arrives either way.
The web container has not been sorted out
Duplicate tags, undocumented triggers and an unsigned-off event schema will be forwarded faithfully. Fixing the container first costs less and normally produces the larger correction.
Google is the only platform in play
Much of the case rests on Meta match quality and Conversions API deduplication. With the whole budget in Google Ads, consent mode and enhanced conversions carry most of the load with no new infrastructure. If Google hit delivery is the only complaint, the Google tag gateway route answers it from a CDN rule with nothing left running.
The audience is not the affected one
The browser report in analytics settles this quickly. A B2B audience on managed Windows machines loses far less to ITP than a consumer audience on iPhones. Argue the case from that data.
Nobody internally will own it
A server container is a live service with DNS, hosting and monitoring attached. Where no one will hold those after handover, the setup becomes a permanent dependency on whoever built it.
Consent and GDPR do not go away
Server-side tagging occasionally gets sold as a route around consent. It is not one. In the UK, PECR governs storing or reading information on a visitor's device; an identifier still has to live somewhere. The UK GDPR governs processing personal data; forwarding it from a server is processing. Moving execution off the page moves neither obligation.
Consent Mode still applies, and the consent state has to travel with the event into the server container. A container that gets no consent signal and forwards everything anyway is worse than the client-side setup it replaced. The decision is now demonstrably the site owner's.
There is a genuine privacy argument here, and it runs opposite to the usual pitch. In the browser, each vendor tag decides what to collect. A server container puts a checkpoint in the middle:
- IP addresses can be dropped before anything is forwarded.
- Identifiers can be hashed.
- Parameters that never needed to leave the business can be removed.
That is a more defensible thing to put in front of a DPO than a page full of third-party scripts.
What to have in place before a migration
The migrations that go badly open with the hosting decision. A more reliable order starts here.
An agreed event schema
Written down: event names, parameters, which of them the business reports on. A server only forwards what the page hands it.
A tidy web container
Duplicates removed, triggers documented, so what migrates is a known state, not a mystery inherited from three agencies ago.
Domain and DNS control
A subdomain on the main registrable domain and the ability to change its records. Where DNS sits with a supplier who no longer replies, settle that first.
A hosting decision with an owner
Which of the three routes, on whose account, paid by whom, and who holds the credentials after handover.
Consent wired and tested
The CMP signal reaching the container, and a documented check of what fires in each consent state before go-live.
A before reading
Four weeks of conversions per platform alongside order or CRM figures. Without a baseline, nobody can say whether the migration helped.
With those in place, the order is:
- Build the container.
- Run browser and server tags in parallel and compare the two sets of numbers.
- Stand the client-side tags down.
Where that reads as more effort than the recovered conversions justify, that is a legitimate conclusion, and one I reach fairly often. Where it is worth doing, what the work involves is set out separately.
Consent, enhanced conversions and the tag gateway each have a guide of their own.
Cost, ad blockers and parallel running
How much does a GTM server container cost to run?
Three bills sit behind it: the build, the hosting and the upkeep. Hosting is the recurring one, varying by an order of magnitude between a rented box and a usage-billed cloud deployment. Request volume decides most of the difference, so one site's monthly figure says little about another's.
Does server-side tagging stop ad blockers?
In part. Calls to a first-party hostname avoid the filter lists that catch vendor domains, so a share of events that used to disappear now arrive. A blocker that stops the page container from loading stops everything after it, and the default paths a server container ships with are being added to those lists in turn.
How long should browser and server tags run in parallel?
Long enough to cover a full reporting cycle including a month end, so the two sets of numbers can be compared on the basis the business already uses. A week rarely separates a genuine gap from ordinary variance.