Server-side tagging doesn't beat ad blockers. What it recovers

Short answer: server-side tagging is a change to how data travels and what you're allowed to do to it in transit. It is not a way to see users who blocked you, and it is not a way around consent. The one thing it genuinely fixes is cookie durability for people who consented and came back — Safari and every other browser that caps JavaScript-set cookies at seven days. That bucket is real, it's measurable, and it's the one nobody puts in the pitch deck, because "your returning Safari customers stop looking like new visitors" sells worse than "recover your lost conversions".

The pitch works by adding three unrelated problems together into one "lost data" number. Split them apart and the decision gets easy.

Bucket 1: blocked users are mostly gone, and the overlap isn't what you were told

If a browser extension refuses to load your measurement script, a tagging server doesn't change that. The request never leaves the page. You can move the endpoint, and we'll come to how far that gets you, but there is no architecture in which a client that declines to send you a hit sends you the hit.

The usual consolation is that it doesn't matter, because someone blocking your tracking also blocked your ad, so there was never a click to attribute. That's true for part of the population and not for the rest, and the difference is worth understanding before you size the bucket.

Ad blocking and tracker blocking are separate mechanisms with separate lists. EasyList and EasyPrivacy are maintained as different files; a user can subscribe to one and not the other. Firefox's Enhanced Tracking Protection blocks trackers from the Disconnect list — social trackers, cross-site cookies, fingerprinters, cryptominers — and is not an ad blocker. So a meaningful share of "we can't see them" users saw your ad, clicked it, paid you money, and then vanished from your reporting.

That's the honest version of bucket 1: the truly ad-blocked slice has near-zero recoverable commercial value, because you never bought that impression. The slice that blocks measurement but not advertising is a real loss — and it's mostly a browser-defaults problem, which is bucket 2, not an extension problem.

Bucket 2: the seven-day cookie cap on people who already said yes

This is the bucket that pays for a tagging server, and it has nothing to do with anyone refusing you.

WebKit's Intelligent Tracking Prevention caps the expiry of every cookie created through JavaScript at seven days. It applies the same cap to cookies set in what it calls third-party CNAME-cloaked HTTP responses — defined as a first-party subresource resolving through a CNAME that differs from the first-party domain (WebKit, 12 November 2020). A _ga cookie written by document.cookie is on that clock.

The consequence is quiet and expensive. A customer consents, browses, comes back a fortnight later and converts. Their identifier expired in between, so they're a new user with a new session and no memory of the campaign that brought them. Nothing was blocked. Nothing was refused. Your data is just wrong about who they are, and the error runs one direction: it inflates new users, deflates returning ones, and strips attribution from exactly the long-consideration purchases you most want to bid on.

A tagging server on your own domain, reached without a CNAME to somebody else's infrastructure, sets that cookie from the server instead of from the page. Google's own documentation is explicit about the mechanism — cookies "can be made more secure and durable because they are set on your own domain and are not set by the JavaScript on the page" — and its custom domain guide puts the same point in a table: on the default cloud provider domain your server "can only set Javascript cookies", while a subdomain or same-origin path gets "full access to security and durability benefits".

So the honest sales line is: server-side tagging repairs identity continuity for consenting users on privacy-default browsers. Whether that's worth a monthly server bill plus setup — we priced the hosting options separately — depends on how much of your traffic is Safari and how long your consideration cycle is. If most of your conversions happen in the first session, the effect is small. If people research for three weeks, it isn't.

Bucket 3: the users who said no are not an engineering problem

If someone declined consent, the reason you have no data is that you asked and they answered.

A tagging server makes this easier to get wrong rather than harder, because the browser-level enforcement everyone implicitly relies on stops applying once a hit reaches your server. Consent state has to be carried into the container and honoured there deliberately. Nobody's blocklist will save you from a server-side tag that forwards a refused user to Google, and the fact that it's technically possible is the reason this bucket is where people get themselves into trouble.

We've written elsewhere about what Google Tag Gateway does and doesn't change; the same rule applies to both. Changing how the data travels never changes whether you were allowed to collect it.

A custom subdomain does not make your tags unblockable

The durability claim in most sGTM pitches assumes blockers work on hostnames. They also work on paths, request patterns and, in some lists, on individual sites that somebody noticed.

You can check this yourself. EasyPrivacy — version 202607280800, published 28 July 2026 — contains generic patterns matching /gtm.js, /gtag/js?, ://ssgtm. and ://sgtm.*.js? regardless of which domain serves them. It also contains rules naming specific companies' own first-party tagging endpoints: ||sgtm.tennis-point.de^, ||sgtm.tagmanageritalia.it^, ||sgtm.cmoa.jp^, and /g/collect? rules pinned to four individual sites' own domains.

Read the scale honestly, in both directions. Seven hand-written site rules out of 56,000 lines is not a systematic campaign against server-side tagging, and moving your endpoint genuinely does raise the cost of blocking you. But the list demonstrably does add first-party tagging hosts by hand once someone spots them, and it does match on path patterns that survive any hostname you choose. "Ad-blocker proof" is a claim about a filter list that updates every four days, not a property of your architecture. Treat it as a rate change, not a fix, and re-measure occasionally.

Nobody has published an independent number, and that's the finding

That gap is the most useful thing to know before you buy. Any specific uplift figure you're shown either came from a vendor's marketing or from a case study with no control group. Ask which, and ask what the measurement looked like before the change — nine times in ten the "before" number was collected by the very setup being replaced.

How to decide, per bucket

The pattern in that table: server-side tagging is worth buying when you have data you're allowed to use and can't currently get where it needs to go. It's a poor purchase when you're trying to see people who took steps not to be seen.

If that's the version you want built — the durability and routing wins, with the consent layer intact rather than quietly stepped over — that's what we do.

Sources

1. 1.Google — Server-side tagging fundamentals: what is server-side tagging (cookies 'set on your own domain and not set by the JavaScript on the page') · Checked 2026-07-28
2. 2.Google — Custom domain configuration for server-side tagging, including the default-domain row: 'Can only set Javascript cookies' · Checked 2026-07-28
3. 3.WebKit — CNAME Cloaking and Bounce Tracking Defense (ITP caps CNAME-cloaked and JavaScript-set cookies to 7 days) · 12 November 2020, checked 2026-07-28
4. 4.EasyPrivacy filter list, version 202607280800 — contains rules naming individual first-party tagging subdomains and /g/collect paths · List version 28 July 2026, downloaded 2026-07-28
5. 5.Mozilla — Enhanced Tracking Protection in Firefox blocks trackers from the Disconnect list · Checked 2026-07-28