What we check
In the deep scan: the browser loads the page, waits for the banner and clicks the reject option on the first layer. After that, everything that still happens counts: requests to hosts the scan knows as marketing, analytics or tag manager, and cookies carrying known tracker names, _ga, _fbp, _gcl_au and relatives. If the list stays empty, the line is "ok". If anything is in it, the line is critical and names up to five senders.
Two special cases. Fetching gtm.js or gtag.js alone does not count, because Consent Mode advanced loads the container on purpose and only the pings decide. And if the browser finds no reject button on the first layer, it treats the state without interaction as the reject run; if nothing fires there, the line stays "to review" instead of "ok", because the scan does not hand out a pass for a button that was not there.
What the scan cannot see: requests that only appear after scrolling or a click, trackers behind unknown hostnames, and anything after the 28-second time limit. If the consent simulation does not run, this line is missing altogether.
Why it matters
A banner whose "reject" changes nothing hands over the complaint that is easiest to prove: screenshot of the click, screenshot of the network log, done. A complaint needs no more evidence than that. Technically the cause is almost always the same. The consent is stored but never bound to the tags; the CMP keeps the books, and the scripts run regardless. The deep scan sees that in seconds, because it does not read what the setup promises but what the browser does.
Common causes
- The tags were never tied to the consent status in the tag manager, the banner is effectively decoration.
- A pixel added after the CMP setup was never categorised and runs straight past the tag-blocking.
- Hardcoded tracking snippets in the theme or template fire outside the tag manager.
- The CMP stores the rejection correctly, but scripts already loaded simply keep running for the session.