The erosion happened gradually
Web analytics worked largely the same way from the early 2000s until about 2017. A JavaScript snippet loaded on the page, collected user interactions, and sent them to a third-party analytics platform. It was imprecise — it had always been imprecise — but it was consistent enough to be useful.
Then several things happened in quick succession. Apple introduced Intelligent Tracking Prevention in Safari in 2017. Firefox followed with Enhanced Tracking Protection. The GDPR came into force in 2018, establishing consent requirements for tracking in Europe. The CCPA followed in California. Ad blockers went from a niche tool used by technical users to a mainstream default on mobile browsers. Chrome started phasing out third-party cookies.
Each individual change was significant. The cumulative effect is a browser environment where client-side tracking is fundamentally compromised for a substantial portion of any website's audience.
What the numbers look like
The signal loss varies significantly by audience. A consumer news site with a general audience might see 20–25% signal loss from ad blockers and ITP alone. A developer-focused site, a SaaS product targeting technical users, or any site with significant European traffic can see 35–50% or more. When you add consent mode declines on top of that, the client-side picture becomes increasingly incomplete.
The specific numbers are hard to pin down precisely — that is part of the problem. You cannot measure exactly what you are not measuring. But the order of magnitude is clear, and it is large enough to affect business decisions that are made based on analytics data.
Server-side measurement is the structural response
Server-side tagging — routing measurement events through a server you control rather than sending them directly from the browser to third-party platforms — addresses several of these problems simultaneously. Events sent from your server are not blocked by ad blockers targeting third-party domains. First-party cookies set by your server are not subject to the same ITP restrictions as third-party cookies. The data passes through infrastructure you own before going to GA4, Meta, or wherever else it needs to go.
It does not solve the consent problem — users who have declined tracking should not be tracked regardless of where the tracking happens. What it does is improve the quality of data from users who have consented or who are in a market where consent is not legally required.
The Measurement Protocol fills the remaining gaps
For events that happen entirely on the server — payment confirmations, backend conversions, API events — the Measurement Protocol allows you to send data directly to GA4 without any browser involvement at all. A purchase that completes on the server can be recorded in GA4 regardless of whether the user's browser would have blocked the confirmation page tracking.
This is particularly important for e-commerce and lead generation, where conversion events are the most critical data points and also the ones most likely to be affected by ad blockers and ITP (since they often happen after a redirect that breaks cookie chains).
What this means practically
For small sites with low ad spend and no significant European traffic, the overhead of server-side tagging may not be justified yet. For anyone running paid campaigns where conversion data drives budget decisions, anyone with significant European traffic, or anyone building a serious measurement infrastructure — it is no longer an advanced option. It is where reliable measurement now lives.
The shift has been gradual enough that many teams are still operating on a browser-only measurement stack without fully accounting for what they are missing. The gap between what their analytics report and what is actually happening is likely larger than they think.