Find out what your tracking actually does — in a real browser, under real consent

1. We open your page the way a visitor does

A headless browser loads the URL you gave us with a clean profile — no extensions, no prior consent state, no logged-in session. That matters, because most tracking bugs only exist in the state your own team never tests from: a first visit, on a cold browser, with a consent banner in the way.

2. We run three passes, not one

The scan is consent-aware. It observes what fires before any consent decision, then what happens when consent is granted, and then what happens when it is refused. A single pass cannot tell the difference between a tag that respects consent and a tag that is simply broken — both look like silence.

3. We compare what should have happened with what did

Two engines run over the observations. The findings engine looks at each signal on its own: is this event present, is it firing at the right moment, is it carrying the parameters it needs. The divergence engine looks at the gaps between passes — the places where your setup contradicts itself, where behaviour after consent does not match behaviour before it, or where a vendor keeps receiving data it should no longer be getting.

4. You get a scored report

Findings come back grouped by severity, in English or French, with a share link and a PDF export. You can re-scan later and diff the two runs, which is the part most people end up using — it turns "I think we fixed it" into a before-and-after you can send to a client or a manager.

The scan is deliberately narrow. It checks behaviour a browser can observe, and it says so when it cannot see something.

• Tag and container behaviour — which tags load, in what order, and whether the container is doing what its configuration implies.
• Event integrity — whether key events are present, when they fire, and whether they carry the parameters a downstream platform needs to actually use them.
• Consent behaviour — which consent platform is in place, what it signals, whether that signal reaches your tags, and what changes between accept and refuse.
• Consent Mode state — what consent state is communicated and whether it updates when the visitor answers.
• Vendor detection — which measurement and advertising vendors are present on the page, including ones nobody on the current team remembers adding.
• Server-side indicators — the browser-observable side of a server-side setup: what leaves the browser, and where it goes.
• Divergence between passes — the contradictions that only appear when you compare the three runs.

What it cannot see

A browser-based scan sees the browser. It cannot read your server-side container, your platform's back end, or your CRM. It cannot confirm that a conversion arrived — only that the browser tried to send one. And it scans the URL you give it, so a checkout bug on a page the scanner cannot reach without a cart is outside its range. Where the scan cannot observe something, the report says so instead of guessing.

Most audit tools hand you a number and leave you to interpret it. A finding here names one specific thing, in plain language, on your specific page: which signal, on which pass, behaving how, and why that particular behaviour costs you something.

The free result shows you one real headline finding — the actual sentence, not a teaser — plus your severity counts and the consent platform and vendors we detected. You will know what is wrong before you decide whether to give us an email.

The email unlocks the detail: the evidence behind each finding, what we observed on each pass, the remediation for each one, and the PDF.

Lock the detail, not the existence

We never hide that a finding exists. You always see the full count and the full severity breakdown, free. What sits behind the email is the evidence and the fix — the part that takes work to produce. No countdown timers, no fake scarcity, no "3 critical issues found, enter your email to see if they are serious". You already know if they are serious, because we told you.

Tracking failures rarely announce themselves. Nothing goes down. No customer complains. The reports keep arriving on schedule, and they keep containing numbers. That is precisely the problem: a broken measurement setup does not produce an error, it produces a plausible number.

The consequences show up somewhere else. Ad platforms optimise against the conversions they receive, so a signal that silently drops after a consent change teaches the algorithm the wrong lesson, and it keeps learning it for as long as nobody checks. Attribution shifts toward whichever channel happens to still be measured correctly, which usually means the channel that gets credit is the one with the healthiest tags rather than the one doing the work. Budget follows attribution. Decisions follow budget.

And the longer it runs, the more expensive the correction becomes — not because the fix is harder, but because months of decisions were made on top of it.

The reason we built a scanner rather than a checklist is that this class of failure is invisible to inspection. Your container can be immaculate and your data still wrong, because the failure lives in the interaction between the tag, the consent platform, and the browser — three things that are each individually configured correctly and collectively contradictory.

What the scan does to your site

It loads your page. That is the entire footprint. The scanner requests pages the way any browser does, at the pace of a single visitor. It does not submit forms, does not create accounts, does not place orders, and does not attempt to get past anything that is deliberately blocking it. If your site runs bot protection that refuses the scanner, the report tells you that is what happened — and, if it is your site, the remedy is to allow our scanner in your own bot-protection console. We build no bypasses.

What we store

The URL you scanned and the observations from the scan, so the report and its share link work and so a later re-scan can be compared against this one. If you unlock the detail, we store the email you gave us and use it to send the report.

Marketing consent is separate

The report email is transactional — it goes out whether or not you agree to hear from us again, and it contains no marketing. The marketing opt-in is a separate, unticked box. If you leave it unticked, nothing about you enters our CRM.

Embedding on this page

The scanner runs in a frame served from our own subdomain, and the connection goes from your browser to our scanner directly. Your scan is not routed through this WordPress site.

The scan is built for the setups we work on daily: European and MENA e-commerce and lead-generation sites on WooCommerce, Shopify, or a custom stack, running GA4 and GTM with a real consent management platform in front of them. Agencies use it as a first pass before quoting on somebody else's setup.

It is less useful if you have no analytics at all — there is nothing to find a contradiction in — or if your measurement lives entirely server-side with no browser component, since a browser scan sees the browser.

If the report turns up something you would rather hand to somebody, that is the work we do. Our engagements start at €1,500 and we are the right fit for sites above roughly €25,000 in monthly revenue.

We did not build this to sell a tool. We built it because we run the same checks by hand on client work — server-side tracking, Meta CAPI, GA4, Consent Mode under CNIL and GDPR conditions — and the manual version of this scan was the first hour of every engagement.

• IMS-BCV (Open-Bar) — 35 working-day build
• Meca Express — ROAS 380% → 580% peak → 520% sustained
• BrightBid — ~10–15 sites/month, 2023–2024