How do ad blockers affect analytics?

How do ad blockers block analytics?

Extensions like uBlock Origin and AdGuard, and browsers like Brave, apply filter lists such as EasyPrivacy that match known tracking domains, script paths and request patterns. If the analytics script or its endpoint matches, the request never leaves the browser. DNS-level blockers (Pi-hole, NextDNS) do the same for whole networks.

How much data do ad blockers cost you?

Estimated blocked share ≈ 1 − (analytics sessions ÷ server-log or Search Console visits for the same pages)

There's no single number — it depends on the audience. Developer and tech audiences block far more than general consumer audiences, and desktop more than mobile. Compare your analytics with a source blockers can't touch (server logs, Search Console clicks, payment counts) to estimate your own gap.

Ad blocker example

A developer-tool site gets 10,000 Search Console clicks in a month, but its analytics shows 7,400 sessions from Google. Some of the gap is normal (people who leave before the page loads, bots filtered out), but a large share is blocked scripts. The audience skews technical, so blocking is likely higher than on a consumer site.

Why it matters

• Undercounted traffic skews the absolute numbers, not just the trends.
• Biased segments: if desktop developers block more, your device and channel mix is distorted.
• Missing attribution: a visitor whose blocker stops the script has no visitor id, so their payment can't be matched to a source.

How to reduce the gap with VisitTrack

Server-side events — payments from provider webhooks and events sent to /api/track — are never blocked, so revenue totals stay complete even when attribution for a blocked visitor isn't possible. For the script itself, the revenue troubleshooting guide suggests serving it from your own domain (see first-party proxy). In your own code, call the tracker with optional chaining (window.visitrack?.("signup")) so nothing breaks when a blocker removes it — see custom events.