Ad blockers and tracking prevention: the traffic your analytics never sees

Home / Everything About / Everything About Analytics / Ad blockers and tracking prevention: the traffic your analytics never sees

Your site gets 10,000 visitors a day according to your analytics. Your server logs show 14,000 requests. The gap between them is visitors your analytics code never captured.

Ad blockers and tracking prevention are the culprit. Users with tracking blockers enabled visit your site, but your analytics code doesn't fire. You never see them in your reports. They're invisible.

How tracking blockers work

Ad blockers prevent tracking code from loading

Ad blockers block requests to known tracking domains. Google Analytics, Facebook Pixel, Mixpanel—these domains are on blocklists. When a user with an ad blocker visits your site, the tracking code loads but the request to the tracking server is blocked. Your code never fires.

Privacy browsers block tracking

Browsers like Brave and DuckDuckGo have built-in tracking prevention. They block requests to tracking domains by default. Firefox has Enhanced Tracking Protection. Safari has Intelligent Tracking Prevention. These are browser-level blocks that no website can override.

Tracking prevention lists block known trackers

Services maintain lists of tracking domains. Browsers and browser extensions consult these lists and block requests to listed domains. EasyList, EasyPrivacy, and similar projects maintain the blocklists that power most tracking blockers.

Server-side blocking blocks tracking domains by hostname

Some advanced users block at the DNS level, preventing any request to tracking domains. Tracking code doesn't even try to load because the DNS lookup fails.

How much traffic is affected by tracking blockers

Blockers are widespread

Adoption varies by audience, but blockers are common. In developed countries, 30-50% of users have some form of ad blocker or tracking prevention enabled. In some countries it's higher.

Desktop vs. mobile differences

Desktop tracking blockers are more common than mobile. Desktop adoption is 40%+ in developed countries. Mobile is lower, around 20-30%, because it's harder to install extensions on phones.

Audience segment differences

Tech-savvy audiences have higher blocker adoption. Business and finance audiences have higher adoption. Consumer audiences typically lower. Your specific audience determines what percentage you're missing.

The impact of missing data

Undercounting traffic

Your real traffic is higher than what analytics shows. If 40% of users have tracking blockers, your analytics undercount by 40%. 10,000 reported visitors might be 16,600 actual visitors. You're making decisions on incomplete data.

Skewed audience composition

Users with tracking blockers aren't a random sample. They skew technical and privacy-conscious. Your analytics show you an audience that's less technical than your actual audience. Tech-focused features look less popular than they really are.

Biased conversion data

If blockers affect some traffic sources more than others, your conversion attribution gets distorted. Paid traffic might have higher blocker adoption than organic. Your attribution model credits organic more than it should.

False trends

When blocker adoption increases, your traffic appears to drop. No campaign changed. No real decline happened. But blockers caught more users and your analytics numbers declined. You might misinterpret it as a real problem.

What you can do about tracking blockers

Acknowledge the bias in your data

The simplest step: know that your traffic numbers are undercounted. This doesn't change your data, but it changes how you interpret it. Your real audience is larger than analytics shows. Your conversion rate is likely higher. Adjust your thinking accordingly.

Use server-side tracking

Server-side tracking code runs on your servers, not the user's browser. It can't be blocked by ad blockers or tracking prevention. The user's browser sends data to your server. Your server forwards it to analytics tools. This bypasses browser-level blocks.

Server-side tracking requires more setup but provides more complete data. It's increasingly common for high-value tracking like conversions.

Measure at multiple points

Track conversions in multiple places: your analytics tool (client-side), your payment processor (server-side), your CRM (data import). Use the more complete source for analysis.

Cross-check against server logs

Server logs show all traffic including blocked requests. They're not perfect, but they show a truer picture than client-side analytics alone. Compare the two to estimate your blocker percentage.

Can you prevent blockers from blocking tracking

You can't reliably block the blockers

You can hide tracking code using obfuscation or custom domains, but blockers keep updating their lists. It's an arms race you'll lose. Trying to work around tracking blockers usually just annoys users without solving the problem.

Better approach: accept it and adapt

Rather than fighting blockers, accept that some traffic won't be tracked and adjust your strategy. Use multiple measurement methods. Rely less on client-side analytics and more on server-side data. Build redundancy into your measurement system.

Frequently asked questions

What percentage of traffic do ad blockers really block?

Should I block users with ad blockers?

Does server-side tracking completely solve the blocker problem?

Why do browsers block tracking by default?

How do I know if blockers are affecting my data?

Is obfuscating tracking code a good idea?

DEVELOPMENT VERSION