ad blockers
Ad blockers are browser tools that stop ads and tracking scripts from loading, which means ordinary analytics setups can badly undercount real visitors and leads.
An ad blocker is any piece of software sitting between a visitor’s browser and the internet that decides which requests get through. Most people install one to make ads disappear, and that part works as advertised. What most people do not realize is that the same lists these tools use to spot ad networks also catch a lot of ordinary analytics scripts, Google Analytics prominent among them, because the two are built the same way and often served from the same domains.
The result is a quiet, invisible undercount. A visitor arrives, browses, calls the business, books a job, and none of it shows up in the analytics dashboard, because the script that was supposed to record the visit never ran. You are not looking at bad data exactly, you are looking at a filtered slice of your real traffic, filtered specifically by whoever is most motivated to avoid being measured, which is not a random sample.
Why it matters to you
Every decision about advertising budget, which pages are working, and which campaigns to cut runs on the assumption that the numbers in front of you reflect reality. If a meaningful share of your actual leads never make it into the report, you can end up cutting a campaign that was working, or crediting a channel that got lucky with a less blocker-heavy audience. The bias is not evenly spread across your traffic sources, either, since some audiences run privacy tools far more often than others.
What I do about it
I do not accept the default installation of Google Analytics as good enough on its own. Where the setup calls for it, I route analytics through Zaras, Cloudflare’s server-side tooling, so the measurement request never touches a domain a blocker is watching for. On top of that, I wire lead tracking so that a phone tap, a form submission, or a booking click gets recorded directly as an event, rather than relying entirely on a pageview script that a blocker might have already stopped.
The combination matters more than either piece alone. Server-side loading closes the gap on general traffic counting, and direct lead events give you a backstop specifically for the numbers that actually pay the bills: calls, forms, and bookings, tied into conversion tracking so the advertising account sees them too.
What it looks like in practice
You will notice the fix in the shape of your reports, not in anything a visitor sees. Traffic and lead counts sit closer to what your phone log and booking calendar already show, instead of trailing behind them by a wide, unexplained margin. If you have ever compared a marketing report against your own gut sense of how busy the business has been and felt like the numbers were lying to you, this is usually why, and it is fixable without touching how you advertise at all.
Questions I get about this
- How many of my visitors are actually running an ad blocker?
- It varies by audience, but on an ordinary consumer site it is common for somewhere between a fifth and a third of visitors to have some form of blocking active, whether that is a dedicated extension, a privacy-focused browser, or a setting built into the phone itself. That is not a rounding error in your reports.
- If someone blocks my ads, do they also block my analytics?
- Usually yes, because the same lists that block ad scripts also block the most common analytics scripts, Google's included. That is the exact overlap that makes standard analytics installs undercount, since the tool measuring your traffic gets caught by the same net as the ads it is meant to be judging.
- Does fixing this mean I have to change how I advertise?
- No. It changes how the measurement is delivered, not how the ads themselves work. You keep running the same campaigns, you just get a truer picture of what they produced.
Want this set up properly for your business?
This is the kind of thing I build every week. Grab a time and we will talk through what fits.