hello@datascale.de+49 89 921 35 623tracked cookie-free · /openDEEN

Search services, integrations and blog posts.

DatascaleResourcesChecksReject respected

Check · C02 · Cookies & scripts before / after consent

Reject respected: what still sends after "reject"

The deep scan clicks "reject" and reads the network log. Every marketing or analytics request and every non-essential cookie after that is critical.

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.

The fix

Find every sender from the list in the source or in the tag manager and move it behind consent: consent trigger in the container, category in the CMP, plugin setting "only after consent". Then reproduce it yourself: fresh browser profile, load the page, click "reject", filter the network tab for collect, fbevents, pagead and your CMP's name. Whatever shows up there is the next entry on the list. What clean blocking with Usercentrics looks like all the way into the server container is covered in the guide Usercentrics + Server-Side GTM.

Matching template

CMP and GTM Consent QA Template

The repeatable test plan for default-denied, consent update and reject, across all four signals.

Get the QA template →

Check it yourself first

The Tracking Check tests this point along with all the others, in seconds.

Start the Tracking Check →
Our CMP blocks everything, but the scan reports requests after "reject". Who is wrong?

Usually neither. The CMP blocks what it knows; the request comes from a script that runs past the CMP: a hardcoded pixel in the theme, a tag in the tag manager without a consent trigger, a plugin that injects its own tracker. The list in the finding names the hosts. Each of them has a sender in the source the CMP has never seen.

Do the cookieless Consent Mode pings count as a violation?

Not in this finding. Google pings with a denied stamp (gcs parameter) are the behaviour of Consent Mode advanced and are reported in the finding Consent Mode: basic or advanced, not here. Whether those pings are permissible without consent is legally open; the decision belongs in writing, not left to the scan.

What happens when there is no reject button on the first layer?

Then the reject run is the state without a click. If marketing already fires there, the finding is critical. If nothing fires, the line reads "to review": supervisory authorities expect an equivalent reject button on the first layer, and all the scan can establish is that it found none. Some banners hide it from bots only; verify that in a real browser.

The fix, delivered

Wired up in days, not sprints.

Findings from the Tracking Check go into a ranked sequence with effort estimates in the Audit Sprint, every module with an acceptance criterion.