Every analytics tool that measures from a script in the browser is subject to the same failure: if the script does not run, the pageview did not happen as far as your data is concerned. The visitor read the page. Your numbers say nobody was there.
The interesting question is not whether this happens. It is how much, on your site, this month — and that turns out to be a number you can measure rather than look up.
Why the published figures do not help
Search for a figure and you will find estimates from about 10% to about 40%. Both are probably accurate for the sites they were measured on, which is exactly the problem. The variance between sites is larger than the variance between studies, because blocking rate depends almost entirely on who your audience is.
The things that move it:
Audience technical level. A developer tool's audience blocks at rates that would be implausible for a florist. If your readers know what uBlock Origin is, a large fraction of them are running it.
Geography. Blocking is much heavier in Northern and Central Europe than in most of Asia or Latin America.
Device. Desktop blocks far more than mobile, because extensions are easy on desktop and awkward on mobile. A shift in your device mix moves your blocking rate without anything else changing.
Browser. Brave blocks by default. Safari's protections stop short of blocking most first-party analytics outright but interact with it. Firefox's strict mode blocks known trackers by list.
Your script's URL. This is the one people can act on and the one most often missed. Blocklists are lists of hosts and paths. A script served from a well-known analytics domain is on every list. A script served from your own domain, at a path that is not a known pattern, is on far fewer of them.
How to measure your own
The principle: count the same pageview twice, in two places that fail independently, and compare.
Count one is your ordinary tracking script, in the browser.
Count two is a count taken when the HTML itself is requested — before any script exists, at a layer no browser extension can reach. That means a server-side or edge-side count: a middleware in your app, a log pipeline, or a Worker in front of the site.
The gap between them is your blocking rate. Not an industry estimate — the actual proportion of your own real traffic that your script never saw.
Two things make this harder than it sounds, and they are worth naming because they are where naive versions of this go wrong.
Bots pollute count two badly. The request-level count catches everything, including crawlers, uptime monitors and scrapers. Compare the raw totals and you will get a wildly inflated "blocking rate" that is mostly bot traffic. The request-side count has to filter bots at least as aggressively as the script side, which is easier at the edge than at the origin because network-level signals are available there.
The same pageview must be recognised as one event. If both collectors fire for a visitor who is not blocking, and the system counts two, every number doubles. Deduplication has to happen on a shared identifier derived identically on both sides.
This is the whole reason the measurement is uncommon: it is not conceptually hard, it is fiddly to get right, and it needs both collectors to belong to the same system.
What to do with the number
If it is under about 5%, stop thinking about it. It is smaller than the seasonality in your traffic.
If it is 10–20%, it matters for anything you compute per visitor — conversion rate is being overstated, because conversions are typically measured by an event the same blocked script would have sent, but the traffic denominator is missing its blocked share unevenly.
If it is above 25%, your analytics is describing a subset of your audience with a systematic skew. The people you cannot see are disproportionately technical, desktop, European and privacy-conscious. Any conclusion of the form "our audience is mostly X" is suspect.
What actually reduces the gap
Serve the script from your own domain. The single biggest lever. First-party paths are on far fewer blocklists than known analytics hostnames.
Keep the filename unremarkable. A file called analytics.js or tracker.js matches pattern rules that a neutral name does not.
Do not fingerprint. Beyond the consent implications, behavioural blocklists increasingly detect fingerprinting directly rather than by URL, and being caught that way is much harder to escape.
Count in the request path. The only complete answer, because it does not depend on anything running in the browser at all. That is what edge measurement is, and it is also the only way to see crawler traffic, which is the same blindness with a different cause.
The measured gap beats the industry average every time. It is your number, it changes as your audience changes, and it is the only version of this statistic that should influence a decision.
Common questions
What percentage of visitors block analytics?
Published estimates run from about 10% to about 40%, and the spread is not measurement error — it genuinely varies that much by audience. Technical audiences, desktop users and Northern European traffic block heavily; general consumer and mobile traffic much less. Because the variance between sites exceeds the variance between studies, no published average is a useful input to your decisions. Measure your own.
Does self-hosting analytics avoid ad blockers?
It reduces the problem substantially but does not eliminate it. Serving the script from your own domain, at a path that is not a known analytics pattern, keeps you off most URL-based blocklists. It does not help against behavioural detection or against a visitor who blocks all scripts. The only complete answer is counting the HTML request itself, before any script is involved.
How can I tell how many pageviews I am missing?
Count the same pageview in two independent places — your browser script, and the request for the HTML — and compare. The difference is your real blocking rate. Two details decide whether the number is meaningful: the request-side count must filter bots at least as hard as the script side, and both counts must recognise a single pageview as one event rather than two.