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, and most product analytics platforms use domains that 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?
It depends on your audience. Tech and business audiences: 40-50%. Consumer audiences: 20-30%. Check your own data by comparing analytics to server logs to know your specific rate. With WEMASY's website builder, you can set this up directly on your website.
Should I block users with ad blockers?
You can, but most don't. Aggressive blocking frustrates users. If you do require disabling blockers, you'll lose that 30-50% of traffic. Not usually worth it.
Does server-side tracking completely solve the blocker problem?
It solves it for your analytics. But users with tracking prevention in their browser still prevent data collection at the browser level. Server-side helps, but doesn't eliminate the problem entirely.
Why do browsers block tracking by default?
Privacy and user control. Users increasingly want to prevent tracking. Browsers are responding by building in privacy protection. It's not against analytics—it's users exercising privacy preference.
How do I know if blockers are affecting my data?
Compare your analytics traffic numbers to your server logs for the same period. The difference is roughly your blocker percentage. Also check for unexplained traffic drops over time—increasing blocker adoption might be the cause.
Is obfuscating tracking code a good idea?
It's an arms race. Blockers update constantly to detect obfuscated tracking. It works temporarily but loses value over time. Better to build measurement redundancy than to fight blockers.