Server-side tracking after the cookie: what we actually measure

Sometime in the last three years, most marketing dashboards quietly became fiction. Not wrong by a little; wrong by a third. The pages still loaded, the campaigns still ran, but the measurement layer underneath had been hollowed out.

What disappeared

Browser-side tracking is now blocked by default for a large slice of every audience: ad-blockers, Safari's tracking prevention, iOS privacy prompts, cookie-banner rejections. Each one removes a different band of visitors from the data, and they are not a random sample. The most privacy-conscious segments are often the most valuable ones.

The result is a dashboard that undercounts revenue, misattributes conversions to "direct", and tells you to cut the channels that are actually working.

The stack we run instead

We moved the measurement off the browser and onto a server container we host ourselves. The browser sends one first-party signal; everything else (enrichment, deduplication, forwarding to ad platforms) happens server-side, on infrastructure we control.

The second half is offline conversions: when a lead closes in the CRM weeks later, that revenue is posted back to the ad platform against the original click. The platforms optimise against real revenue, not form fills.

If the number in the dashboard cannot survive an ad-blocker, it is not a number; it is a guess.

What came back

On our own properties and on client accounts, the pattern repeats: roughly a third of the sessions that browser-side tracking lost are visible again. Attribution moved out of "direct" and back to the channels that earned it. Two campaigns we would have cut on the old numbers turned out to be the best performers on the account.

This is the stack we deploy in the Growth practice: audited first, then installed, then measured against the old baseline so the recovery is a number rather than a claim.