Server-side tracking: how it works, and when it is worth the cost
This page describes server-side tracking as it actually runs: the request path, what it recovers, what it leaves broken, and what it costs to keep going. 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 a few assumptions. The vendor's JavaScript will load. The cookie it writes will still be there next month. The request to google-analytics.com or facebook.com will leave the machine. Each of those assumptions now holds less often than it did.
Cookie lifetime went first. Safari's Intelligent Tracking Prevention has held cookies written by JavaScript to seven days since 2019. A visitor who comes back outside that window arrives with a fresh identifier, so one person is counted twice and the acquisition source of the first visit is gone. Firefox blocks known tracking hosts from a maintained list, which removes the cookie and the request together.
Then the requests themselves. A share of visitors run extensions or network-level filtering that drops calls to the well-known analytics and advertising hostnames before they are made. The share is not a constant. A developer or privacy-conscious audience loses far more than a mainstream retail one, which is why a single industry-wide figure for this is worth ignoring.
Consent is the third piece, and it is not a fault. A visitor who declines has given the correct answer, and the events still do not arrive.
Tags report success throughout and the reports keep populating. The gap becomes visible 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. It does not remove the browser from the chain, and following a single event through makes clear which parts change and which do not.
The page still loads a container
In a Google setup that is the web container or the Google tag, and it still runs client-side. An event is pushed to the data layer, a trigger fires, and JavaScript on the page prepares a measurement request.
The request goes to the site's own hostname
Tags are configured with a transport URL on the site's own domain, such as data.example.com, resolving to a machine the site owner controls. The payload is the same measurement request, addressed somewhere else.
A client claims the request
Inside the server container, a client parses the incoming request into an event object: event name, page data, parameters, consent state. GA4 and the Google tag have built-in clients, and custom clients handle other payload shapes.
Server tags make their own outbound calls
Tags in the server container read that event object and call each vendor directly, machine to machine: GA4, the Google Ads conversion endpoint, Meta's Conversions API. The visitor's browser takes no part in any of them.
The server sets the identifier
The container returns cookies in the HTTP response, so the identifier comes from the site's own server and not from a script on the page. Cookies set that way are treated differently by Safari, which the section below goes into.
Step one is the constraint on all of it. The chain still begins with a request the browser has to make, and only the steps after that request 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 of the journey.
Where tags run
Client-side, every vendor tag executes in the visitor's browser. Server-side, one request leaves the browser and the vendor tags execute on a machine the site controls.
Who sets the cookie
Client-side, JavaScript writes it, which is precisely what Safari's seven-day cap was aimed at. Server-side, it arrives in an HTTP response from the site's own host.
What leaves the page
Client-side, a separate request per vendor, each carrying whatever that vendor's tag decided to collect. Server-side, one request to one hostname, with the payload set in the container.
What blockers see
Client-side, recognisable script and hostnames that sit on public filter lists. Server-side, a first-party hostname that is harder to list, though the default server container paths are themselves being listed.
Control of the data
Client-side, whatever each vendor's tag chooses to send. Server-side, the payload can be trimmed, hashed or dropped before it reaches anyone outside the business.
Cost and upkeep
Client-side, no infrastructure and no bill. Server-side, a host to pay for, a container image to update, and a component that can fail while nobody is watching.
What server-side tagging recovers, and what stays broken
The gains are real and narrower than the sales pages suggest. Cookie lifetime improves on Safari, because a cookie set in an HTTP response by a genuinely first-party host is not covered by the script-cookie cap. Requests that filter lists would have dropped now go to the site's own hostname, and a proportion of them get through. Meta match quality improves where the Conversions API is fed properly from the server and deduplicated against the browser event by ID. The same argument covers enhanced conversions through the server container, which attaches hashed customer details to the conversion so Google can match it 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 the position. A blocker that stops the page container from running takes the whole chain with it, endpoint or no endpoint. Apple's Private Relay still masks the IP address. Cross-device and cross-browser identity is no closer than it was. And an event schema that was wrong to begin with stays wrong, because the server forwards what it is handed.
Recovery quoted as a single percentage should be read as marketing. What comes back depends on the browser mix, the blocker rate and the consent rate of one specific audience. Measuring before and during a parallel run is the only way to find the number for a given site.
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 in the request. Safari closed this in version 14 (November 2020). Where a subdomain resolves through a CNAME to a host outside the site's own scope, cookies set in those HTTP responses are held to seven days, which is 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, with that server setting its own cookies. Mine sit behind Cloudflare and nginx on my own machine, with the DNS record pointing at that machine and not at a vendor. Stronger again is serving the endpoint from a path on the main origin, so there is no subdomain to inspect at all, although that means putting a proxy in front of the live site and many teams will decline.
This is worth establishing before signing anything, because a managed product that asks only for a CNAME is describing the configuration Safari singled out. It is also worth being sober about the ceiling. A first-party cookie is not a permanent one, Safari applies further limits including bounce-tracking protection, and Chrome's position on third-party cookies has changed direction more than once. Browser policy has moved several times over the period this architecture has existed.
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 work: the client, the tags, the consent handling, any transformations, and the testing needed to show that server events line up with the browser ones. It is a fixed piece of 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, sharing the machine with other services. That box costs single figures to low tens of pounds a month. It is the cheapest route and it assumes somebody is comfortable with Docker, DNS and a reverse proxy.
Someone else runs the container
Several vendors sell hosted server-side tagging as a subscription. It costs more than a VPS, removes the operational work, and is where the CNAME question above needs asking directly before any contract is signed.
App Engine, the default route
Google's setup flow deploys to App Engine, and its own guidance for production is a minimum of three instances. The bill follows request volume from there. Easy to procure, and easy to underestimate before the first invoice.
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 that the endpoint is still answering, because a server 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
Server-side tagging is sold as an upgrade every site should want. For a good number of them it is expense without a return, at least for now.
The volume is too small for recovery to show
Where a site converts a few dozen times a month, the slice server-side brings back is a handful of events against ordinary week-to-week variance. Nobody will be able to 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 event schema nobody signed off will be forwarded faithfully by a server. Fixing that comes first, costs less, and normally produces the larger correction to the numbers.
Google is the only platform in play
A large part of the case rests on Meta match quality and Conversions API deduplication. Where the whole budget sits in Google Ads, consent mode and enhanced conversions carry much of the load without new infrastructure. If delivery of those Google hits is the only remaining complaint, the Google tag gateway route answers it from a CDN rule with no service left running afterwards.
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, and the case should be argued from that data.
Nobody internally will own it
A server container is a live service with DNS, hosting and monitoring attached. Where no one on the client side 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, and the reasoning is not subtle. In the UK, PECR governs storing information on a visitor's device or reading what is already there, and an identifier still has to live somewhere. The UK GDPR governs the processing of personal data, and forwarding it from a server is processing. Moving execution off the page leaves both of those obligations exactly where they were.
Consent Mode still applies, and the consent state has to travel with the event into the server container, not stop at the browser. A container that receives no consent signal and forwards everything anyway is a worse position than the client-side setup it replaced, because the decision is now demonstrably the site owner's.
There is a genuine privacy argument for this architecture, and it runs opposite to the way it is usually pitched. When vendor tags execute in the browser, each one decides for itself 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, and 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 are the ones that open with the hosting decision. A more reliable order looks like this.
An agreed event schema
Written down: event names, parameters, and which of them the business reports on. A server can only forward what the page hands it.
A tidy web container
Duplicates removed and triggers documented, so what gets migrated is a known state and 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 once the project is handed over.
Consent wired and tested
The CMP signal reaching the container, and a documented check of what fires in each consent state before any of it goes live.
A before reading
Four weeks of conversions per platform alongside the order or CRM figures. Without a baseline, nobody can say afterwards whether the migration helped.
Then the container itself, then a parallel period where browser and server tags both run and the two sets of numbers are compared, then the client-side tags are stood down. Where that reads as more effort than the recovered conversions justify, that is a legitimate conclusion, and it is the one I reach fairly often. Where it is worth doing, what the work involves is set out separately.
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 and it varies by an order of magnitude between a rented box and a usage-billed cloud deployment. Request volume decides most of the difference, so a monthly figure quoted for one site says very little about another.
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. Where a blocker prevents the page container from loading at all, nothing further along the chain runs either, 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.