Consent Mode v2 signals are configured

Why this matters

Consent Mode v2 became required for advertising into the EEA. Without the signals, Google models the conversions you lose to consent refusals, and remarketing audiences shrink sharply.

How this tool detects it

The tool looks for the four signals Consent Mode v2 requires: ad_storage, analytics_storage, ad_user_data and ad_personalization.

All four present means the check passes. One to three means consent signals exist but are incomplete, and the report names exactly which ones it found. Only analytics_storage and ad_storage belong to v1; ad_user_data and ad_personalization were added in v2. Only when none of the four appear does the tool report that no consent configuration was found at all.

It also looks for the signature of a known consent management platform — OneTrust, Cookiebot, Iubenda and similar. That tells you whether consent signals could be firing without a CMP behind them.

Where this check can mislead you

Static analysis has limits. These are the cases where this particular check will report a result that does not match reality — worth knowing before you act on it.

• Detecting a signal is not the same as it being updated. The tool confirms the four signal names appear in source; it cannot verify that clicking Reject actually moves the state from granted to denied. That has to be tested in a browser.
• Whether the CMP actually blocks tags is not verified. A broken CMP can show consent options in the interface while letting tags fire regardless. Nothing static reveals this.
• Cannot confirm consent state is passed downstream correctly. A tag may receive the signal and ignore it, which is runtime behaviour.

Examples

<script>
gtag('consent', 'default', {
  'ad_storage': 'granted',
  'analytics_storage': 'granted',
  'ad_user_data': 'granted',
  'ad_personalization': 'granted'
});
gtag('js', new Date());
gtag('config', 'G-1A2B3C4D5E');
</script>

<script>
gtag('consent', 'default', {
  'analytics_storage': 'granted',
  'ad_storage': 'granted'
});
</script>

How to fix it

1. Establish which CMP you use. If none, start with a mainstream one — most send the v2 signals automatically.
2. In GTM, add a Consent Mode configuration (if you use GTM): set the default state to denied, then let the banner interaction change it to granted.
3. If you hard-code gtag, make sure the gtag('consent', …) call appears before every tag.
4. Scan with this tool and confirm all four signals are detected.
5. In GTM Preview, accept consent and confirm each tag shows "requires additional consent".
6. Fire a pageview in GA4 DebugView and confirm the outgoing request carries consent parameters.

Verify it worked

After making changes, confirm delivery rather than assuming. These steps require your Google login, which is exactly why this tool stops short of them.

• Open GTM Preview and browse once with consent accepted and once with it refused, comparing which tags fire. This is the only reliable way to confirm the CMP works.
• In the browser Network panel, filter for /g/collect or /collect and check whether the gcs and gcu values change with consent state.
• Confirm events arrive in GA4 DebugView and check that they carry consent parameters.
• Use the Tag Assistant browser extension from Google — it shows the consent state live on every tag fire.

Related checks

• Cookie consent banner present — Consent signals normally come from a CMP. Finding signals with no CMP present is worth asking who set them
• Advertising pixels are present — When advertising into the EEA, failing this check directly degrades performance with no visible cause in reporting
• Server-side tracking in place — Server-side tagging needs the consent state passed through too; a server-side misconfiguration cancels out a correct client-side setup