Proof your blocking actually works — with evidence.

Blocking a tracker is a promise. Leak detection is the receipt. It's the difference between "we block trackers until consent" and "here's proof that on your site, right now, they stayed blocked — and here's the one that didn't."

What leak detection is

ConsentPixel's core job is prevention: non-essential trackers are blocked by default until a visitor consents. Leak detection is a separate assurance and observability layer on top of that. Think of it as a CCTV camera watching your trackers, not a second gate: it doesn't try to block anything — that's the prevention layer's job — it watches for anything that fires when it shouldn't have, given the visitor's current consent state.

When it catches a tracker firing despite a "No" — say an advertising tag firing while ad-storage consent is denied — it records that as a leak event and surfaces it to you. That's a capability most consent tools simply don't have: they can promise blocking, but they can't show you evidence it's actually holding on your live site.

How the watchdog works

The watchdog is set up early — in the pixel's head stub, alongside the blocking logic — because to catch a tracker firing, you have to be listening before it fires. From there, all its checking runs asynchronously and continuously in the background. Mechanically, it uses a MutationObserver to watch for injected tracking tags (scripts, pixels, images) and matches what fires against known tracker signatures and your current consent state. If something fires that the consent state should have prevented, that's a leak — logged, and you're alerted.

The leak report

The output is the valuable part. In your portal, a per-site leak report tells you exactly which tracker leaked despite a visitor's choice, on which page, and when — so you can fix it (usually a stray tag added outside ConsentPixel) and confirm it's resolved. Each event records only what's needed for diagnosis: the tracker or vendor identity, what fired, the consent state at the time, the timestamp, and the page path. Deliberately no visitor identifiers, no personal data — the leak diagnostics are kept entirely separate from your consent audit log, which stays the clean source of truth for real consent decisions.

What it can and can't catch — honestly

We'd rather be straight with you than oversell this, because overclaiming here would be a compliance liability of its own. A client-side JavaScript watchdog catches a great deal — DOM-injected tracking tags and many script firings — which covers the common ways a tracker slips through after a site change. But it cannot catch everything: a determined first-party server-side call, or something firing inside a sandboxed context, can evade pure client-side observation.

So we position this accurately as leak detection and assurance — strong, continuous evidence that your blocking is working and an early warning when it isn't — not a guarantee of intercepting 100% of all possible trackers. It's the smoke detector that catches the fires that actually happen on real sites, paired with the block-by-default prevention that stops them starting.

Why it never slows your site

Assurance features are worthless if they hurt performance, so the watchdog is built to stay out of the way:

• Never synchronous, never in the footer. Its hooks are set up early so it's listening in time, but all checking and reporting run asynchronously — it never blocks parsing, rendering, or page load.
• Fail-open. If the watchdog itself hits an error, it fails silently and your consent banner and tracker-blocking continue uninterrupted. A bug in the camera never opens the gate.
• Batched and lightweight. Leak events are batched, carry no PII, and go to a separate diagnostics store — keeping both your site fast and your consent log clean.

Works with the rest of ConsentPixel

Leak detection is a client-side assurance and observability feature. It detects many but not all possible tracker firings; it is not a guarantee that every tracker is intercepted, and it is not legal advice. Use it alongside block-by-default enforcement, not as a substitute.