---
title: "Partial Tracking Blocks: Detect vs. Route Around"
canonical_url: https://ot.webclat.com/qa/detect-and-respond-to-partial-tracking-blocks
description: "Detecting a partial tracking block and deciding whether to circumvent it are two separate engineering decisions - here's how to build the detection cleanly and where the judgment call belongs."
source: Webclat | OneTrust Solutions (OneTrust partner, independent consultancy)
---

# 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

- [What's a reliable, current method to detect that a visitor is running an ad blocker?](https://ot.webclat.com/qa/detect-ad-blocker-reliably)
- [How do I gracefully handle (or measure the impact of) ERR_BLOCKED_BY_CLIENT on my tracking requests?](https://ot.webclat.com/qa/err-blocked-by-client-tracking-requests)
- [Why do Snowplow tracker requests get silently blocked in the browser, and how do I detect it?](https://ot.webclat.com/qa/snowplow-requests-blocked-by-browser)

Contact: ot@webclat.com | (813) 694-4451 | https://ot.webclat.com/#contact