Ad Blockers and Tracking Loss
Date: 2026-08-16
A share of your events never arrive, and the share isn’t random. Blocked users skew technical, desktop and privacy-conscious — so the loss doesn’t just shrink your numbers, it tilts them.
What it is
Tracking loss is the gap between events that should have been sent and events that arrived. Blocking is the largest deliberate cause, alongside consent denial, delivery failure and network conditions.
Blockers work by domain and by URL pattern. A request to a known analytics or advertising host is cancelled before it leaves. It isn’t clever — it’s a list — which is why first-party endpoints defeat it.
Why it biases rather than merely reduces
If loss were random, you’d scale up and carry on. It isn’t:
- Blocker users are more technical, and skew towards desktop, certain browsers and certain age groups
- They behave differently. Different conversion rates, different basket sizes, different category preferences
- The rate varies by browser and market, so device and geography segments aren’t comparable with each other
- It varies by tag. A well-known advertising pixel is blocked far more than a first-party endpoint, so different tools lose different populations — which is a large part of why they disagree
In plain terms: you’re not measuring a smaller version of your audience. You’re measuring a version of your audience with a specific kind of person removed, and that person converts differently from the average.
[CHECK: blocking rates vary enormously by market, device and audience, and every published figure is either dated or from a vendor with an interest. Measure your own gap rather than quoting one.]
Measuring your own gap
The only figure worth having. Compare a signal that can’t be blocked against one that can:
orders in the order system 1,000 ← cannot be blocked
purchases in analytics 870 ← can be
gap 13%
That 13% is blocking plus consent denial plus delivery loss plus bots, combined. To separate them, compare a first-party endpoint’s event count against a third-party vendor’s for the same event — the difference between those two is closer to pure blocking.
Then segment by device and browser. A gap that’s 8% on one browser and 25% on another tells you where the loss lives, and is more useful than the aggregate.
Track the gap over time. A stable gap is a correction factor you can apply and explain. A moving one is an incident — Tool Discrepancies.
What reduces it
In order of effect:
- Server-side collection for anything transactional. An order webhook cannot be blocked, and it’s authoritative anyway — Client-Side vs Server-Side Tracking
- A first-party endpoint for client events, rather than sending to each vendor’s domain — Server-Side Tag Management
- Your own subdomain, not a vendor-provided one, since vendor-provided endpoints end up on blocklists too
- Fewer third-party tags, each of which is separately blockable — Third-Party Scripts
Where the line is
Worth being clear-eyed. Circumventing blocking is a spectrum, and the ends are different in kind:
- Reliable first-party measurement of your own site — ordinary, and what server-side collection is for
- Rotating subdomains to evade blocklists, or disguising third-party trackers as first-party — evasion, and it treats a stated user preference as an obstacle
The distinction that holds: are you measuring your own site, or are you sending data to third parties the user has declined? The first is defensible; the second is the thing blockers exist to stop, and doing it via a first-party proxy doesn’t change what it is. Consent obligations apply regardless of transport — Consent Management.
Living with it
- Reconcile against the order system and publish the gap, so nobody treats analytics revenue as truth — Guide - Auditing a Tracking Plan
- Use rates, not counts, wherever possible. Conversion rate is more robust to uniform loss than order count
- Never compare across tools without knowing each one’s loss profile
- Record the gap in the symptom list as a known quantity, so it isn’t rediscovered as a bug every quarter