Your real traffic is almost certainly higher than your analytics says. If your audience is technical — developers, crypto, privacy-minded users — you could be missing 20–40% of visits. For a general audience it's often 10–20%.
The cause is ad blockers and privacy tools quietly blocking your analytics. This guide explains exactly why it happens, what that scary ERR_BLOCKED_BY_CLIENT console error means, and how to recover most of the lost data.
Quick answer: Ad blockers match analytics requests against filter lists and cancel them in the browser before they're sent. You can't stop this completely, but a lightweight first-party tracker plus server-side revenue attribution recovers most of the undercount — and means the metric that matters most (money) is never lost.
Why ad blockers block analytics
Ad blockers (uBlock Origin, AdBlock, Brave Shields, Privacy Badger) and DNS blockers (Pi-hole, NextDNS) use filter lists. Those lists target:
- Known analytics domains — e.g.
google-analytics.com,googletagmanager.com. - Obvious paths — anything that looks like
/analytics,/track,/collect,/pixel. - Heavy third-party scripts — large vendor tags loaded from another domain.
If your tracker matches any rule, the request is killed in the browser — it never even reaches your server. The visit simply doesn't exist in your reports.
What "ERR_BLOCKED_BY_CLIENT" means
If you've seen this in your browser console or a PageSpeed report:
Failed to load resource: net::ERR_BLOCKED_BY_CLIENT
…it means the browser itself (the "client") refused to send the request — almost always because an ad blocker or privacy extension matched it. Key facts:
- It is not a bug in your site or your server. The page loaded fine.
- It does not hurt your performance score or Core Web Vitals — it lives under the "Best Practices" console audit, not Performance.
- It usually shows up when a test (like Lighthouse) runs in a browser with a blocker active, or the request matched a built-in filter.
The only real effect: that one visit (or sale) wasn't recorded. Annoying — but fixable.
How much traffic are you actually losing?
It depends entirely on your audience:
| Audience | Typical analytics loss |
|---|---|
| Developers / tech / crypto | 25–40% |
| SaaS / B2B | 10–20% |
| General consumer | 8–15% |
| Older / non-technical | 5–10% |
If you sell to developers, assume your "real" numbers are meaningfully higher than your dashboard.
How to fix the undercount
You can't beat every blocker — but you can recover most of the loss.
1. Use a tiny first-party tracker
A small script (under ~1 KB) loaded from a normal path is far less likely to match filter lists than a heavy, recognizable vendor tag. Tools built for privacy (Piqo, Plausible, Fathom) are lighter and less targeted than Google Analytics.
2. Proxy tracking through your own domain
Serve the tracker and its endpoint from your domain instead of a third-party one. When the request goes to yoursite.com/... instead of a known analytics host, blockers have nothing obvious to match. This is the single most effective technique — most privacy analytics tools document a proxy setup.
3. Make revenue attribution server-side
This is the big one. Even if a visit's pageview is blocked, the payment still happens on your server. If your analytics attributes revenue from the payment webhook (not a browser event), you never lose a sale to an ad blocker — only some top-of-funnel pageviews.
4. Stop using obvious endpoints
Avoid script and request paths that contain words like analytics, track, or ads. Generic paths slip past more filters.
What you can't (and shouldn't) fix
Be realistic: no analytics tool can capture 100% of blocked visitors, and you shouldn't try to defeat genuine privacy choices. The goal isn't to spy — it's to stop under-counting real humans who simply run a blocker.
The honest, ethical fix is first-party + server-side:
- You count visits on your own domain, with no third-party tracker.
- You confirm revenue from the payment, server-side.
- You store no personal data and respect consent.
That recovers most of the undercount without crossing any privacy lines.
How Piqo handles it
Piqo is built first-party from the ground up:
- A ~1 KB first-party tracker — small and unobtrusive, so it dodges far more filters than a heavy vendor tag.
- Server-side revenue attribution — sales are attributed from the payment webhook (Stripe, Creem, Paddle, Polar, Dodo), so the money is counted even when a pageview is blocked.
- No third-party trackers, no fingerprinting — nothing for blocklists to flag, and nothing creepy.
You'll still lose some blocked pageviews (everyone does), but your revenue numbers stay accurate — and that's the metric that pays the bills.
Frequently asked questions
Why does my console show ERR_BLOCKED_BY_CLIENT?
An ad blocker or privacy extension in that browser blocked the request. It's a client-side block, not a server error, and it doesn't break your site.
Does this error affect my SEO or PageSpeed score?
No. It appears under "Best Practices," not Performance, and doesn't touch Core Web Vitals or rankings.
Can I completely stop ad blockers from blocking analytics?
No tool can guarantee 100%. First-party tracking and proxying through your own domain recover most of the loss; the rest is the cost of respecting users who block on purpose.
Is it legal to "bypass" ad blockers with first-party tracking?
First-party analytics isn't a sneaky bypass — it's measuring visits to your own site without third-party scripts. Stay compliant by storing no personal data and honoring consent and Do Not Track.
Will first-party tracking hurt my visitors' privacy?
It shouldn't. Privacy-first tools store anonymous, first-party data only — no cross-site profiles, no PII.
Conclusion
If your dashboard feels low, it probably is. Ad blockers hide a real slice of your audience — and the more technical your users, the bigger that slice.
You can't capture everyone, but you can recover most of it:
Tiny first-party tracker + own-domain proxy + server-side revenue attribution = accurate numbers you can trust.
Tired of guessing your real traffic? Try Piqo free — a featherweight first-party tracker with server-side revenue attribution, so your sales are never lost to an ad blocker.
Further reading: What Is Cookieless Analytics? · Track Stripe Revenue by Source · Cookieless Affiliate Tracking