Common server-side tracking misconceptions agencies should address before implementation

Here's my theory after watching a lot of these go well and a few go very much not well: almost every server-side tagging implementation that ends badly ended badly in the kickoff call.

Not in the container. Not in the transformations. Not in some exotic Meta CAPI deduplication edge case at 11pm. It ended in the twenty minutes where somebody said something slightly wrong out loud, everyone nodded, and nobody corrected it. Then that slightly wrong thing slowly grew into an expectation, and the expectation went into a deck, and the deck went to a CMO, and now you're four months into explaining why GA4 still doesn't match Shopify.

So let's talk about that gross looking server-side elephant in the room. Here are the misconceptions worth addressing before anybody touches a DNS record, the ones your client causes, and then the more uncomfortable ones your own team causes.

This is the big one, and it usually gets discussed through undertones with something more polite, like "so this basically fixes our data loss, right?"

What's true: these are two completely different things. Recovering a user who consented to tracking and then got their pixel eaten by uBlock Origin is measurement. Tracking a user who declined to be tracked is evasion and morally sucks. Server-side gives you the first one. It absolutely should not give you the second one, and if your setup does, that's a bug with legal implications.

Consent state travels with the event to your server container and your server honors it. Consent Mode is not a formality you configure once and forget. A user who says no on the client says no on the server, and that’s not something you should mess with.

What to say: "It recovers conversions from people who already agreed to be measured but whose browser blocked the tag. It doesn't change what happens when someone opts out - that stays a no."

Make sure that’s understood and perhaps put it in the SOW. You will occasionally lose a deal to somebody willing to promise more. Let them have it. Know the type of people you’d be working with if that’s the kinda business they want to run.

Somebody once told your client that server-side means perfect data. That person is a monster and messed it all up for the rest of us.

What's true: you're closing a gap, not eliminating one. Client-side-only setups typically miss somewhere in the 15–40% range depending on traffic mix, and a solid server-side deployment brings back a meaningful amount of it. Not all of it. iOS traffic behaves differently than Android. A B2B SaaS audience full of privacy-conscious developers on Firefox is a very different recovery story than a DTC brand selling to Chrome-on-Windows shoppers.

Your platforms will still disagree with each other afterward. GA4 and Meta and your CRM count different things at different moments with different attribution windows. That doesn't stop being true when you move to the server. You get more data but it is a different win than "the numbers all match now."

What to say: "You'll recover a significant share of what you're currently losing, and I'll show you exactly how much with a before-and-after. The platforms still won't perfectly agree with each other but that’s the way that it is. 

Under-promise the number. Over-deliver the proof of server-side tracking ROI.

Clients hear "infrastructure" and think "one-time build," like a deck or a logo.

What's true: it's a living system that sits between their website and every dollar of ad spend. The site gets redesigned. The form platform gets swapped. A vendor changes their API. Consent rules shift in a market they just expanded into. Somebody on the client's team adds a tag directly in the web container on a Friday because they were in a hurry.

I wrote a whole separate piece on form tracking failures largely because of how quietly this stuff breaks. Broken tracking doesn't throw an error. It just goes silent, and you find out six weeks later when sales asks why leads fell off a cliff during a month when leads did no such thing.

What to say: "The build is the beginning. There's a monthly line item for monitoring and QA, and I’d always recommend getting tag insurance."

A question that sounds good in theory.

What's true: Google walked back cookie deprecation in July 2024, confirmed in April 2025 that it wouldn't ship a standalone choice prompt, and then in October 2025 retired ten Privacy Sandbox APIs outright, Topics, Protected Audience, Attribution Reporting and friends (who’s friends…not sure about that one). Third-party cookies live on in Chrome with no deprecation date. Pretending we are still pushing towards a “Cookieless world” makes you look like you haven't read the news since 2023 (this happens a lot).

But: your client's attribution problem was never “a fix for Chrome”. Safari's ITP has been capping cookie lifetimes for years. Firefox blocks by default. Ad blockers don't consult Google's timeline. The pressure that's actually deleting data has been applied continuously the whole time, entirely independent of the announcement cycle.

What to say: "The deadline went away. The data loss didn't. Let me show you your Safari conversion rate next to your Chrome conversion rate."

That comparison closes more deals than any slide I've ever built.

These are less fun because they cost you margin instead of costing the client sleep.

The seductive one. Same GTM interface, same tag names, how different could it be.

What's true: it's a different model wearing the same UI. The server has no browser. It doesn't know the screen resolution, the referrer, the user agent, or the page title unless you deliberately forward them. GA4's automatically collected events aren't automatic anymore. Meta CAPI needs event IDs that actually match the browser event or you'll double-count everything and then get to explain that. User data needs hashing before it goes anywhere.

What to do about it: Scope it appropriately. It’s not a point and click. You’ll need to explain the ROI but don’t under scope what it costs to get there.

This is the technical misconception I see most often in agency proposals, and it's the one most likely to embarrass you in month two.

What's true: Safari is looking specifically for this. If it detects CNAME cloaking, it caps those cookies at seven days exactly like third-party ones. Since autumn 2022 it also compares IP addresses - if your tagging subdomain resolves to an IP range that doesn't substantially match your main site's, it gets treated as third-party regardless of how first-party the URL looks. Known click ID parameters can get cut to 24 hours.

So "we're on a subdomain, therefore two-year cookies" is not a thing you can promise. You need a genuine first-party setup - a proper custom domain - and for Safari traffic specifically, something like Cookie Keeper doing the restoration work when the caps hit anyway.

What to do about it: validate cookie lifetimes in Safari during QA, not in a Chrome tab where everything looks beautiful. Test on a real iPhone.

The container build is maybe 30% of it.

What's true: the hard part is the surrounding work. Consent platform integration. Cross-browser QA. Getting the client's dev team to prioritize setup. Deciding, in advance and in writing, which number becomes the source of truth when the platforms disagree. And then the conversation in week six when reported conversions jump by double digits and somebody's monthly performance report suddenly looks like it was wrong before because it was, but that's a delicate thing to explain to a VP who's been reporting those numbers upward all year.

What to do about it: put the discrepancy conversation on the calendar before launch. Snapshot the baseline. Announce the shift ahead of time. A jump in conversions is a great outcome and a terrible surprise.

Server-side tracking is one of the highest-leverage things an agency can do for a client, and the technology is the easy part now - Stape has made the deployment side genuinely boring in the best possible way. What's left is expectation management, and expectation management is just misconception management performed early enough to still be cheap.

Kill the myths at kickoff. Write down what you're actually promising. Then go build it.

Nobody has ever gotten fired for promising slightly less and delivering considerably more. GO FORTH AND BE ANNOYINGLY HONEST.