If a privacy extension only partially blocks our tracking, should we detect that and route around it, or respect the intent?
Short answer
Detecting a partial block is a legitimate, separate engineering task from deciding whether to route around it - you need the detection regardless, just to know your data is undercounted, but actively rebuilding delivery specifically to defeat a tool a visitor deliberately installed is a distinct decision with its own reputational and, in some jurisdictions, regulatory considerations. This is an engineering read of the tradeoffs, not a compliance determination - route the routing-around decision through your own legal/privacy review before shipping it, separately from the detection work itself.
Why this happens
A "partial" block typically means some of your tracking gets through and some doesn't - for example, a standalone Google Analytics tag is blocked by a filter list, but the same events also fire through a Google Tag Manager container whose own container script isn't on the list, so part of your picture survives while another part silently doesn't. This creates an uneven, hard-to-characterize data gap rather than a clean all-or-nothing loss.
There are two defensible engineering positions once you've measured that gap, and they lead to different amounts of downstream work: measure and report the gap honestly (cheaper, no adversarial relationship with the visitor's chosen tooling), or actively re-architect collection to reduce what gets blocked (more effective at closing the gap, but a meaningfully bigger decision than adding a detection script).
Fix it
- 1
Build detection as a self-contained, reviewable unit
Implement the block-detection logic (see the ad-blocker-detection and ERR_BLOCKED_BY_CLIENT pages) as its own module that only measures and reports state - it should not, on its own, change what loads or how anything is delivered to the visitor.
- 2
Tag whatever data does get through with the block state
Attach a block-state flag or dimension to the events/sessions that do arrive, so downstream reporting can separate "this number is complete" from "this number is missing an unknown fraction of blocked visitors" instead of presenting both the same way.
- 3
Treat any decision to route around a block as a separate, reviewed change
If the business decides the data gap is worth closing through a technical workaround (first-party proxying, renamed endpoints, server-side collection), scope and approve that as its own initiative with privacy/legal sign-off - don't let it ship as an incidental side effect of adding detection.
- 4
Document the reasoning, not just the code
Whichever position is taken, write down why - this is exactly the kind of design choice that gets scrutinized later (by an auditor, a privacy reviewer, or your own team six months on), and "we measured the gap and decided X because Y" is a very different position to be in than an undocumented default.
How to verify it worked
Confirm detection alone changes no user-facing or data-delivery behavior - compare a build with detection instrumented against one without it and confirm identical network requests fire in both.
Confirm the block-state flag appears correctly set to true/false in whatever downstream report or table consumes it, tested against both a blocked and an unblocked session.
If a routing-around change ships, confirm it went through its own separate review record rather than riding in on the detection module's changelog.
Related
Still stuck, or want this checked against your specific setup?
We scope every engagement in discovery, before implementation - no assumptions about your stack.