Every new client of mine gets the same tracking build in the first fortnight, before I touch a bid or write a single ad. A server-side Google Tag Manager container on their own subdomain, GA4 and Meta’s Conversions API routed through it, click IDs captured and stored on the server, and one event ID shared between the browser and the server. That is the handover. I have built it enough times that it stopped being a project and became a checklist.
The argument for it is narrower than the marketing around it. Server-side tagging is not a privacy product and it will not rescue a bad offer. It fixes one specific thing: a client-side setup measures conversions using an identifier the browser is entitled to delete, and increasingly does.
What breaks without it
Start with cookie lifetime, because it is the leak that never appears in a report. Google documents the GA4 _ga cookie as expiring after 2 years. Safari disagrees. Since Intelligent Tracking Prevention 2.1, WebKit caps “all persistent client-side cookies, i.e. persistent cookies created through document.cookie” to “a seven day expiry”. ITP 2.2 went further, capping those cookies to “one day of storage” when a visitor arrives through a cross-site navigation carrying a query string or fragment, which is a precise description of a paid click.
Google documents the _ga cookie as lasting 2 years. Under ITP 2.2, a cookie written through document.cookie is capped to one day of storage. The number in the documentation and the number in the browser have not matched since 2019.
Safari's cap on a cookie written through document.cookie
Shortening the lookback window does not recover this; only a cookie the server writes outlives the cap. Source: WebKit, 2019.
That gap only matters at volume, and it is at volume. Safari accounted for 16.47% of worldwide browsing in July 2026 by StatCounter’s count, against Chrome’s 68.22%. Roughly one visitor in six arrives in a browser that expires their identity long before a considered purchase cycle closes, and on most of the accounts I run, that visitor skews toward the higher order value.
Browser market share worldwide, July 2026
Safari sits far behind Chrome and is still large enough that its cookie rules set the ceiling on how long any client-side identity survives. Source: StatCounter GlobalStats, 2026.
The second leak is the familiar one: content blockers strip the request before it ever leaves the page. Backlinko’s compilation of GWI’s Q2 2025 data puts ad blocker use at 32.5% of American internet users. Not all of those extensions block analytics, but enough block the Meta pixel specifically that a Meta-heavy account is optimising from a partial sample.
The third is duller and costs more than either: the browser is an unreliable place to run business logic. Tags race the unload event on checkout redirects. Single-page apps fire an event twice or not at all. A consent banner that resolves slowly drops whatever fired before it. None of that surfaces as an error. It surfaces as a conversion rate that is quietly wrong, which is the expensive kind, because it still looks like a number.
What is actually in the box
The handover is seven items and I do not vary them much between accounts:
A server-side GTM container on a subdomain of the client’s own domain, so the requests are genuinely first-party rather than first-party-looking.
The GA4 client running inside that container, so measurement traffic terminates on their hostname instead of Google’s.
Meta’s Conversions API tag firing from the server, with action_source set honestly and the fbclid forwarded rather than reconstructed.
A visitor cookie written by the server with Set-Cookie and HttpOnly, which is the exact thing Safari’s client-side cap does not reach.
First-touch capture of gclid, gbraid, wbraid and fbclid, stored on the server side and re-attached to whatever converts later.
Consent state passed into the container as a parameter, so the server decides what to forward instead of the page deciding what to fire.
One event ID, minted once per conversion, carried by both the browser tag and the server tag.
That last item is where most of the implementations I inherit have already broken.
The deduplication detail that separates a clean build from a broken one
Meta’s rule is easy to state and easy to violate. The pixel’s eventID has to equal the Conversions API’s event_id, the pixel’s event name has to equal the server’s event_name, and the part that gets missed: Meta only deduplicates events received within 48 hours of the first event carrying that ID. Two events with different IDs are two conversions. Two events sharing an ID that arrive three days apart, because a retry queue backed up over a weekend, are also two conversions. The window is not a formality, and nothing in either interface tells you when you have missed it.
A lead-gen client of mine arrived with a setup another agency had already built. Server container live, Conversions API connected, everything green in Events Manager. The browser pixel generated an event ID at page load. The server tag generated its own. The two had never once matched, so every form submission had been counted twice for months. Reported cost per lead dropped by roughly half in the week the migration finished, which is the arithmetic of double counting rather than evidence of anything working, and budget had been scaled against that reading. The CRM row count had not moved. The fix took an afternoon: mint the ID once in the dataLayer push, pass the same string down both paths, then send a handful of test submissions and confirm each lands in Events Manager once instead of twice.
That is now the first thing I check on any inherited account. If reported conversions jumped at the migration and the CRM did not, the build is double-counting, not recovering.
What it costs to keep running
I quote Google’s own numbers here, because the client can go and read them. Google’s server-side tagging documentation puts a Cloud Run instance at approximately USD 50 per instance per month and calls for a minimum of 3 instances to support production traffic. Autoscaling between 3 and 6 instances is documented to handle 50 to 200 requests per second, which covers every account I have run outside of a flash sale.
So the honest floor is around $150 a month, plus network egress, plus whatever the build costs in my time. Against the $80K+ a month in media I currently manage, that is a rounding error. For an advertiser spending low four figures a month it is a visible line item, and my answer there is to wait: Meta’s one-click Conversions API integration now covers a useful fraction of this for nothing, and selling that advertiser a container would be selling infrastructure instead of results.
Where I might be wrong
My position, stated plainly: the case for server-side tagging is durability of identity and control of the collection point. It is not privacy, it is not consent compliance, and it is not an uplift anyone should bank before it shows up. Meta reports that advertisers with a Conversions API setup for web events saw an “average 17.8% lower cost per result” against those without one. I do quote that figure to clients, always with a caveat attached, because the advertisers who implement the Conversions API are also the advertisers who implement everything else properly. Selection bias is doing real work inside that number.
Here is the part I could lose. I still build the container for every account of mine running five figures a month or more, because owning the collection point is the one piece of this stack a platform cannot deprecate out from under a client. The scenario that proves me wrong is already in motion: the platforms keep improving their zero-configuration paths, and if a one-click integration ever matches a tuned container on match quality and event completeness, then what I have been charging for is complexity rather than outcome. I do not believe that day has arrived. I re-test it about every six months, and I would rather learn it from my own testing than from a client.
If a container is already running on your site, the useful question is not whether it fires. It is whether the same event ID reaches both ends of the pipe inside the window.
