Consent Mode v2 Is Not Working
You can verify this in thirty seconds without any tooling, by reading one parameter on any outbound Google request. Most sites that believe they are compliant fail this check.
Get My Free Audit →Are you seeing this?
- Google Ads warns that Consent Mode is not detected or not correctly implemented
- Conversion modelling is unavailable in your Ads or GA4 reporting
- Tags appear to fire before the consent banner has been interacted with
- Rejecting all cookies makes no observable difference to network requests
- Your CMP is installed and displaying, but nothing downstream seems to respond to it
The thirty-second check
Every request Google's tags send carries a gcs parameter encoding the consent state at the time of the request.
1. Open your site in a fresh incognito window 2. Open DevTools → Network, filter for collect 3. Before touching the banner, look at the gcs value on any request
Before consent, you should see G100. If you see G111 before the visitor has agreed to anything, your default state is not being applied — that is the most serious and most common failure, and it is the configuration that attracts regulatory attention.
Then accept, and confirm the value changes. If it does not change, your CMP is not connected to your tags.
| Value | Meaning |
|---|---|
| G100 | ad_storage denied, analytics_storage denied |
| G110 | ad_storage granted, analytics_storage denied |
| G101 | ad_storage denied, analytics_storage granted |
| G111 | Both granted |
Why it happens
The default state is never set, or is set too late.
Consent defaults must be pushed before any Google tag loads. If the default command runs after gtag.js, or after GTM has already fired tags, the race is decided by network timing and you will not win it consistently.
The CMP is installed but never wired to the tag manager.
The banner displays, the user chooses, and nothing propagates. This is the most common configuration we find. The banner is doing nothing except creating a record of consent you are not honouring.
The v2 parameters are missing.
Consent Mode v2 added ad_user_data and ad_personalization alongside the original ad_storage and analytics_storage. Implementations built for v1 and never updated are missing both, which is what triggers Google's non-compliance warnings.
Individual tags do not have consent checks configured.
Consent Mode works at the tag level. A custom HTML tag or a third-party template with no additional consent settings will fire regardless of the consent state, quietly bypassing everything else you built.
Region targeting is misconfigured.
Defaults set for the wrong region list, or a global default that unintentionally applies restrictive settings to markets where they are not required — costing you data with no compliance benefit.
How to diagnose it
Step 01 — Run the gcs check above.
It tells you immediately whether you have a default-state problem, a propagation problem, or neither.
Step 02 — Use GTM Preview's Consent tab.
It shows the consent state at each step and which tags were blocked or allowed. This is the fastest way to find a tag with no consent configuration.
Step 03 — Confirm the ordering.
In Preview, verify the default consent command appears before any tag fires. If your CMP loads asynchronously and the default is inside it, you have a race condition that will fail intermittently — the worst kind of failure to diagnose later.
Step 04 — Check all four v2 parameters.
Confirm ad_user_data and ad_personalization appear alongside the original two in both the default and the update commands.
Step 05 — Test every path.
Accept all, reject all, and partial consent. Many implementations handle the first two and break on the third, because partial consent is the case nobody tests.
How to fix it
The default must run before everything, in the <head>, ahead of the GTM container:
<script>
window.dataLayer = window.dataLayer || [];
function gtag() { dataLayer.push(arguments); }
// Default denied for EEA and UK. Runs before any tag loads.
gtag('consent', 'default', {
'ad_storage': 'denied',
'ad_user_data': 'denied',
'ad_personalization': 'denied',
'analytics_storage': 'denied',
'functionality_storage': 'granted',
'security_storage': 'granted',
'wait_for_update': 500,
'region': ['EU', 'GB', 'CH', 'NO', 'IS', 'LI']
});
gtag('set', 'ads_data_redaction', true);
gtag('set', 'url_passthrough', true);
</script>Three parameters worth understanding rather than copying:
wait_for_update: 500 tells Google's tags to hold briefly for a consent update before proceeding. Without it, tags may fire on the default state before your CMP has restored a returning visitor's saved choice — so someone who consented last week is treated as denied.
ads_data_redaction: true removes ad click identifiers from requests when ad_storage is denied, so cookieless pings carry no identifiable data.
url_passthrough: true preserves click IDs through page navigation via URL parameters when cookies are unavailable, which recovers a meaningful share of attribution on denied traffic.
Then, on the user's decision, push the update:
<script>
function propulseConsentUpdate(granted) {
var state = granted ? 'granted' : 'denied';
gtag('consent', 'update', {
'ad_storage': state,
'ad_user_data': state,
'ad_personalization': state,
'analytics_storage': state
});
}
</script>Wire that to your CMP's callback. In Complianz and Cookiebot this is a documented event — do not attempt to detect consent by polling for a cookie, which reintroduces the race condition you just removed.
Finally, in GTM: open every tag and set its additional consent requirements. Any tag left unconfigured will fire regardless of consent state, and one such tag undermines everything above.
How to verify the fix worked
- Fresh incognito window — confirm gcs=G100 before interacting with the banner
- Accept — confirm gcs=G111 on subsequent requests
- Reject — confirm G100 persists and no identifiable data is transmitted
- Test partial consent and confirm the parameters reflect the actual choice
- Return as a repeat visitor and confirm the saved choice is restored, not re-defaulted
- Check Google Ads after several days for the consent warning clearing and modelling becoming available
When this needs more than a snippet
Multi-market stores need this verified per jurisdiction, and server-side setups need the consent state forwarded to the server container — otherwise the browser respects the choice and the server ignores it, which is arguably worse than not implementing consent at all.
That is what our Consent Mode v2 implementation covers, including documented data flows for your privacy policy.
Tell us about your setup. We respond within 24 hours.
Common
Questions
No. Consent Mode is the mechanism that carries the user's choice to Google's tags. You still need a CMP to obtain and record that choice. They are complementary, and neither works without the other.
Partially, and only if denied-consent pings are actually being sent — which is the part most implementations get wrong by blocking everything on denial. Modelling needs sufficient volume to work at all, so smaller sites see less benefit. It reduces the loss rather than eliminating it.
Google's requirement is driven by the audience you serve rather than where you are based. If you serve EEA or UK users at all, you are in scope. Other jurisdictions have their own rules that differ. Implement to what your legal counsel specifies rather than to geography.
Ready to Build Something That Works?
Book a free 30-minute strategy audit. No pitch deck, no pressure — just an honest look at your setup and what to fix first.
