Ad blockers block analytics, not just ads. Every major blocker (uBlock Origin, AdBlock Plus, Ghostery, Brave’s built-in blocker) carries google-analytics.com, googletagmanager.com, and most third-party tracking domains on the same filter lists it uses for ad servers. When one is active the tracking script never loads, so the visit, the session, and often the conversion are absent from your reports entirely.
On a typical site that removes roughly 15-30% of visitors from analytics, and the share is far higher for developer, gaming, and privacy-conscious audiences. The loss is not random. Ad blocker users skew younger, more technical, and higher income, which means the segment missing from your data is disproportionately the segment that buys.
Three questions decide what to do about it. What exactly disappears, and is it missing at random? What do the standard recoveries actually recover, and what stays out of reach? And how large does the gap have to be before it justifies changing an architecture rather than adding a footnote?
The newsletter
Join our KISS newsletter
One short read a week on what actually moves revenue, in a free email. Read by 10,000+ operators and founders.
No spam. Unsubscribe in one click.
I.The loss is selective, not just large
Blocking removes a group defined by the same traits that predict how people buy, so the error does not shrink as traffic grows.
A.What the block does, and to what
The mechanism is a domain filter. Blockers subscribe to lists such as EasyList and EasyPrivacy, which carry google-analytics.com, googletagmanager.com, and connect.facebook.net next to the ad servers. A request to a listed host is cancelled in the browser, so nothing arrives to be counted. This is why the effect is categorical rather than partial: there is no session row with a gap in it, there is no row. No pageview, no first-touch source, no conversion unless something on your server wrote one.
Domain filtering is the cheap layer, not the only one. Blockers also match on request paths and on script contents, so a library that has been self-hosted or renamed can still be caught if it keeps a recognisable global object, endpoint shape, or payload format. Self-hosting is a real improvement in odds, not an exemption.
The scope is the part teams underestimate. The same lists cover advertising pixels (Meta, LinkedIn, TikTok), session recording (Hotjar, FullStory, Clarity, LogRocket), experimentation platforms (Optimizely, VWO), and client-side CDP libraries (Segment, mParticle, RudderStack). For a blocked visitor the entire client-side stack goes dark at once, which means the tools you would use to sanity-check each other fail together and agree perfectly.
Reported adoption sits near 30% of internet users globally and roughly 37% on desktop, but the interesting figures are the extremes: above 40% in Germany, 50-60% among developers and IT professionals, below 10% among users over 55.
Reported ad blocker adoption, by audience
Metrics view| Audience | Reported blocking rate | Why it matters |
|---|---|---|
| All internet users | ~30% | The number most benchmarks quote |
| Desktop users | ~37% | Where longer research sessions happen |
| Germany | above 40% | Regional spread is wider than the global average suggests |
| United States | ~27% | Rising with state privacy legislation |
| Developers and IT | 50-60% | The buying committee for most technical products |
| Users over 55 | below 10% | The segment your data over-represents |
B.Why the missing set is correlated with the answer
The share is the least interesting part of the problem. Losing 20% of visitors at random is a sample size question, and it resolves itself with time. Blocking is not random. The traits that cause someone to install a blocker (technical fluency, privacy preference, browser choice, and the income bracket that correlates with both) are the same traits that predict which channel they arrived from, which device they used, and what they buy. The result is a biased estimate, and more traffic makes a biased estimate more precisely wrong rather than more accurate.
Four specific distortions follow, and each has a direction. Funnel shape is the most visible. A blocked visitor who completes the entire journey either never appears, or appears at whichever step your server happened to record, which produces a funnel where a later step has more people in it than the step before. If every step is client-side, you get the quieter failure: an inflated drop-off at step one, from visitors who did not drop off at all. Either way you optimise a leak that is a measurement artefact. Our guide to building a first funnel covers the step definitions this depends on.
Conversion rate then moves in whichever direction your instrumentation is asymmetric. Client-side sessions with server-side conversions means the numerator survives blocking and the denominator does not, so the rate inflates. Both sides client-side, and the rate looks entirely plausible while the volume behind it is wrong, which is the more dangerous case because nothing appears broken. Check which side each half of your conversion rate came from before comparing it to anything.
Attribution is distorted because blocking rates vary by source. Traffic from developer communities, aggregator sites and technical newsletters blocks heavily; traffic from email and mainstream social blocks far less. Budget allocated on attributed conversions therefore drifts away from the channels that reach the most technical buyers. Traffic sent by AI assistants compounds it: those visits usually arrive with no usable referrer and land in the direct bucket, and the audience that uses ChatGPT, Claude, Gemini and Perplexity for vendor research overlaps heavily with the audience that runs blockers. The LLM Acquisition report exists to pull those humans out of direct so the channel can be sized at all.
Experiments break last and worst. If the testing script is blocked, the excluded users are not a smaller sample of the same population, they are a different population. A winning variant is a winner among people who do not block, and nothing in the test tells you whether it holds for the rest.
A funnel with one server-recorded step
Funnels report viewII.What recovery actually recovers
First-party collection, reverse proxies and server-side capture defeat different layers of the block. None of them defeats all of it, and one of them is maintenance rather than architecture.
A.Same origin, and a different origin entirely
First-party collection serves the tracking endpoint from your own domain, ideally as a path on the main hostname rather than a dedicated subdomain, since a subdomain named after analytics is itself a pattern. The request no longer matches a third-party domain rule, so the cheapest and most widely applied layer of the block does not fire. A first-party analytics tool does this natively, and the data stays in a first-party context rather than being routed through a third party you then have to disclose. Our privacy-first analytics guide covers the consent plumbing that goes with it.
A reverse proxy is the same move retrofitted onto an existing vendor: requests go to a host you control, which forwards them to the vendor’s collector. It recovers a similar share without changing platforms, which is why it is popular. The difference is what happens after the recovery, since a first-party tool stores the data as yours while a proxy relays a third-party request through your infrastructure. That is a disclosure difference as much as a technical one.
Server-side capture is not a variation on either. It does not ask the browser to cooperate, because the record is written by code the visitor cannot modify: the page render, the form post, the API call, the payment webhook. A blocker operates inside the browser and has no mechanism to remove an event your server already committed. This is the only one of the three that is structurally immune rather than currently effective.
B.Where each one still fails
Pattern matching erodes the first two. Filter lists are maintained by people looking for exactly this, so a proxy path that becomes common gets added and a self-hosted script that keeps its original request shape gets matched on the shape. The recovery therefore has a decay rate, and the maintenance is not a one-time configuration but a standing commitment to notice when the rate drops. That is a reasonable interim position and a poor permanent one.
Server-side capture fails in the opposite direction: it is blind to everything that never reaches the server. Scroll depth, clicks that do not navigate, form field abandonment, hesitation before a submit, time actually spent reading. A server log cannot tell a visitor who read the whole page from one who left the tab open. So the realistic architecture is split rather than chosen: the server owns the events revenue depends on, the client owns behaviour, and you accept that behavioural data describes the non-blocking population. A tracking plan is where that split gets written down before anyone implements it.
The third limit is the one that is not technical. A blocker is a refusal expressed in software; a consent banner is a refusal expressed in law, and they are independent. Recovering a blocked visitor’s pageview does not create a lawful basis for profiling a visitor who declined consent, and a first-party record tied to a person identifier is personal data whatever domain it was collected on.
III.Size the gap before you rebuild for it
The gap is a quantity you can measure in an afternoon, and its size and evenness decide whether this is a correction or an architecture.
A.How to measure it honestly
The method is a comparison against a source the browser cannot suppress. Take server access logs or CDN request logs, filter to HTML document responses, and compare the count with your client-side session count for the same pages over the same range. The ratio is your gap. A second method works alongside it: fire a small server-side beacon when the analytics tag fails to initialise, which converts the gap from an occasional audit into a standing metric you can watch by page and by source.
Two refinements decide whether the number is usable. The first is bot filtering, and it is where most attempts go wrong: server logs contain crawlers, uptime monitors and scrapers that never executed JavaScript, so an unfiltered comparison attributes their requests to ad blocking and overstates the gap, sometimes by a lot. Filter by user agent and by request pattern before you compute anything. If you are already fighting this, our note on bot and spam traffic applies directly.
The second is segmentation. A site-wide percentage is the least useful form of this number, because everything downstream depends on whether the gap is even. Compute it per traffic source and per page template.
Client-side sessions as a share of server-recorded sessions
Metrics viewB.What each size justifies
If the gap is small and roughly even across sources, it is a scale error, not a measurement failure. Ratios are unaffected: conversion rate, step-to-step drop, and channel share all survive a uniform undercount, because the missing visitors are missing from both sides of the fraction. Apply the correction only where absolute volume is the point, which is forecasting, capacity planning and revenue per visitor, and leave the rest alone. Rebuilding collection to recover a uniform 8% is engineering spent on a number you can simply divide by.
If the gap is uneven, no scalar fixes it. Each channel needs its own factor, the factors drift as audience mix changes, and any comparison across channels inherits the error. This is the case that justifies moving revenue-critical events server-side and the collector first-party, and the order matters: server-side first, because it is the part that cannot be eroded, then first-party collection for the behavioural layer on top.
There is a third case where none of this is a repair. If your audience is majority technical, client-side measurement is not a source of truth at any level of investment, and treating it as one produces a confident number about a minority of your users. The defensible primary record there is the server’s, with client-side data demoted to what it actually is: a description of the visitors who allowed it.
Verdict
You do not know how much traffic you are losing, including after reading the range at the top of this page, and the measurement that would tell you takes an afternoon. Run the server-log comparison, filter the bots properly, and break the result out by source before you accept any published figure as yours. Almost every argument about ad blockers is conducted without this number, which is why it goes nowhere.
Once you have it, the decision is not close. Put the events revenue depends on server-side, where blocking has no mechanism to reach them, and serve behavioural collection first-party so the browser layer recovers what it can. Treat a reverse proxy as a stopgap with an expiry date rather than an answer, because you are committing to maintain a workaround against people who update their lists weekly. And publish the gap next to any absolute count you report. A recovered number presented as complete is a worse error than the blocked one it replaced, because it arrives with more confidence attached.
One analytics idea a week
Short, specific, written by the team building the product. No digest, no roundup.
Continue Reading
How to Audit GA4 for Data Accuracy (And What to Do When the Numbers Don't Add Up)
If you have ever compared GA4 numbers to your backend and found a 20-40% gap, you are not alone. This guide provides a systematic audit process to identify where your data is leaking and what to do about it.
Read articlePrivacy-First Analytics: The Complete Guide to GDPR-Compliant Tracking
The analytics landscape has fundamentally shifted. Third-party cookies are dying, regulations are tightening, and consumers are paying attention. This guide shows you how to build an analytics practice that respects user privacy while still delivering the insights you need to grow.
Read articleWhy Google Ads Shows 200 Clicks But GA4 Records Only 10 (And How to Fix It)
The gap between Google Ads clicks and GA4 sessions is one of the most common complaints in digital marketing. This guide explains the 7 causes of the discrepancy and gives you a framework to diagnose and quantify each one.
Read article