Consent activates measurement: does anything fire after "accept"

The deep scan clicks "accept" and waits for the first measurement ping. If none comes, every consent you are given is lost, and nobody notices.

What we check

In the deep scan: the browser clicks "Accept all" and records what happens next. Measurement means any request to a known analytics or tag manager host, any measurement ping (/collect paths and relatives), any request to a first-party endpoint with a measurement path, and any non-essential cookie that newly appears. One of those is enough for "ok". If nothing comes, the line reads note: no analytics measurement triggered. The line only appears when the static scan found measurement tools at all.

What the scan cannot see: tags with a delay or interaction trigger, measurement on subpages, and anything after the time limit. If the consent simulation does not run, the line is missing.

Why it matters

This is the quiet twin of "reject respected". There, too much fires; here, too little, and the second gets noticed less often: no reviewer complains, no user notices, only the numbers get smaller. A site with 60 % consent where nothing starts after the click measures like a site with 0 %. The campaigns then optimise on a fraction of the conversions, and the discussion turns to consent rates instead of the trigger that has not matched since the relaunch.

Common causes

The tags hang on triggers that never fire after opt-in. The consent update arrives, but no event releases the tags.
The CMP blocks scripts via a type="text/plain" rewrite, and after a relaunch the unblocking no longer matches the changed script paths.
Tracking deliberately runs server-side and the web trigger was removed, then the finding is expected and not an error.
Tags only fire on the production domain, but a staging or preview URL was scanned.

The fix

Reproduce it in Tag Assistant or the network tab: fresh profile, load the page, click "accept", wait for the first collect request. If none comes, walk the chain backwards: does the CMP's consent update fire (finding Consent Mode signal after update)? Does a trigger in the container listen to it? Do the tags hang on that trigger? With CMP text-blocking, match the script paths against the release list. Usually it is one line that stopped matching at the last deployment.

Matching template

Consent Mode Audit Checklist

Seven layers, each with a check, a failure signal and an owner. Covers this finding and the six around it.

Get the checklist →

Check it yourself first

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

Start the Tracking Check →

Asked often

Nothing fires after "accept". What is typically broken?

The wiring between banner and tags. The CMP stores the consent, but no trigger in the tag manager reacts to it, or the release of scripts served as text no longer matches after a relaunch. The tags are there, they just never get started. In the report that looks like a falling consent rate; in reality the measurement of the people who agreed is missing.

We measure server-side without a client tag. Is the note wrong then?

The scan also counts first-party requests, pings to an endpoint under your domain, and the cookies a server-side container sets. If everything really runs without browser involvement, the scan sees nothing and the note is expected. The tracking architecture finding is the better address then.

Why is this only a note and not critical?

Because the scan cannot reliably tell absence from timing. A tag that fires after a two-second delay or on the first scroll is invisible to it. The note says: evidence is missing here, check Tag Assistant. A critical would claim nothing measures, and the scan cannot know that.

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.

To the service Request an Audit Sprint