What Consent Mode v2 does
Consent Mode v2 is Google's API for receiving a user's consent state and adapting Google tags to that state. Instead of treating a missing cookie as the only signal, Google receives an explicit purpose-level choice. That lets GA4, Google Ads, Floodlight, and related products understand whether they can store identifiers, use analytics storage, send user data for advertising measurement, or personalize ads.
Basic mode means Google tags are blocked until the user grants consent. Before consent, there are no Google requests. This is the simplest compliance posture for many EU teams because denied users do not trigger Google network calls. The tradeoff is measurement: Google receives less behavioral context, so diagnostics, modeled conversions, and audience eligibility can be limited.
Advanced mode lets Google tags load before consent, but they run with denied defaults and send consent-aware cookieless pings. After the user grants consent, tags update and can use the allowed storage or data purposes. The four core signals are ad_storage, analytics_storage, ad_user_data, and ad_personalization. Advanced mode can improve modeling and diagnostics, but it requires tighter legal review and a cleaner technical implementation because denied traffic still creates limited Google requests.
The EU deadline
Google began enforcing the updated EU user consent requirements in March 2024 for EEA traffic, with UK and Swiss implementations commonly treated under the same regional controls. The practical effect was immediate for advertisers using Google Ads, GA4 audiences, Customer Match, remarketing, enhanced conversions, or uploaded user data. If Google did not receive the right consent signals, governed users could no longer be used for key advertising and measurement features.
Enforcement started. Google expected Consent Mode v2 signals for EEA users where ad measurement and personalization relied on user consent.
GA4, Google Ads, CMP vendors, GTM templates, and partner integrations added upgrade paths. Teams with old v1 setups often discovered that ad_storage and analytics_storage were not enough.
Consent Mode v2 is no longer a launch checklist item. It is part of production tracking hygiene, destination governance, and conversion quality monitoring.
If you do not have it, the breakage is rarely a clean outage. Audiences may exclude EU users, remarketing lists can shrink, enhanced conversions may stop contributing in governed regions, conversion diagnostics can show missing consent, and modeled reporting may never mature because Google receives too little eligible signal. The most expensive failure is inconsistent enforcement: the CMP blocks browser tags, while server-side APIs keep forwarding the same user's event without consent context.
The 4 signals in detail
Treat the four signals as separate controls. A user can allow analytics but deny advertising, or allow ad measurement but deny personalization. Your implementation should preserve that difference from the banner through gtag, GTM, TrackLayer, and every downstream destination.
| Signal | Controls | Default | What changes if denied | Required in EU |
|---|---|---|---|---|
| ad_storage | Advertising cookies, click identifiers, remarketing storage, and ad conversion storage. | Denied in EU regions until consent | Google tags send cookieless pings where eligible; ad cookies and click storage are not written. | Yes |
| analytics_storage | Analytics cookies and GA4 measurement storage, including visitor and session identifiers. | Denied in EU regions until consent | GA4 can receive consent-aware pings, but analytics cookies are not stored and reporting may rely on modeling where eligible. | Yes |
| ad_user_data | Whether user data can be sent to Google for advertising measurement use cases. | Denied in EU regions until consent | Enhanced conversions, tag-based conversion tracking, and uploaded user data cannot use that user data for ad measurement. | Yes |
| ad_personalization | Whether Google can use the data for personalized advertising, audiences, and remarketing. | Denied in EU regions until consent | Audience membership and remarketing use are restricted; conversion measurement may continue only where the other required signals allow it. | Yes |
Step-by-step setup
Set defaults before any analytics tag fires
The default command has to run above Google Tag Manager, gtag.js, GA4, Google Ads, and any wrapper that can emit a Google request. If a tag fires first, Google may see the hit as missing consent rather than denied consent, and diagnostics become noisy.
window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments);}
gtag("consent", "default", {
ad_storage: "denied",
analytics_storage: "denied",
ad_user_data: "denied",
ad_personalization: "denied",
wait_for_update: 500
});
gtag("js", new Date());
gtag("config", "G-XXXXXXXXXX");Wire your CMP to update consent after the user chooses
Your CMP should map granular purposes into Google signals and call the update command when the banner is accepted, rejected, customized, or changed later in preferences. Do not depend on page reloads for consent changes.
function onCmpConsentChange(consent) {
gtag("consent", "update", {
ad_storage: consent.marketing ? "granted" : "denied",
analytics_storage: consent.analytics ? "granted" : "denied",
ad_user_data: consent.marketing ? "granted" : "denied",
ad_personalization: consent.remarketing ? "granted" : "denied"
});
}Forward consent to TrackLayer event bodies
Browser consent has to travel with the event envelope. TrackLayer expects explicit purpose-level consent so it can evaluate every downstream destination using the same state Google saw in the browser.
await fetch("https://api.tracklayer.io/v1/events", {
method: "POST",
headers: {
"content-type": "application/json",
"authorization": "Bearer TRACKLAYER_WRITE_KEY"
},
body: JSON.stringify({
event: "Purchase",
event_id: "ord_10492_purchase",
value: 129.95,
currency: "EUR",
consent: {
ad_storage: "granted",
analytics_storage: "granted",
ad_user_data: "granted",
ad_personalization: "denied"
}
})
});Let TrackLayer enforce consent downstream
TrackLayer passes consent state to Google destinations and applies destination policy before forwarding to Meta, TikTok, Pinterest, Klaviyo, and other server-side APIs. That prevents the common split-brain state where browser tags respect consent but server events keep flowing.
{
"destination": "google_ads",
"consent": {
"adUserData": "GRANTED",
"adPersonalization": "DENIED"
},
"dispatch": "measurement_allowed_personalization_blocked"
}Test with Google Tag Assistant and an EU VPN
Test from an EU, UK, or Swiss location, then repeat from a non-governed region if your defaults are regional. Watch the first network request, not just the final purchase event.
Checklist:
1. Open an EU VPN session
2. Clear cookies and local storage
3. Load the page with Tag Assistant connected
4. Confirm default consent is denied
5. Accept analytics and marketing
6. Confirm the update changes all four signalsMonitor GA4 Realtime and the TrackLayer dashboard
After launch, compare consent-mode diagnostics in Google with TrackLayer consent distribution by destination. A healthy setup shows explicit granted and denied states, not a large bucket of missing or unknown consent.
Production checks:
GA4 Realtime → DebugView → Consent state
Google Ads → Diagnostics → Consent mode
TrackLayer → Dashboard → Consent by region
TrackLayer → Destinations → Suppressed eventsCMP vendor compatibility
Most mainstream CMPs now provide native Consent Mode v2 support. Native support does not remove the need to test. You still need to verify load order, regional defaults, category mapping, checkout pages, and whether consent state reaches your server-side event layer.
| Vendor | Native support | Manual wiring required | Implementation note |
|---|---|---|---|
| Cookiebot | Yes | No | Enable Google Consent Mode in the Cookiebot integration and verify purpose mapping. |
| OneTrust | Yes | No | Use the Google Consent Mode template or OneTrust script callbacks for custom builds. |
| iubenda | Yes | No | Supports Google Consent Mode with category mapping for advertising and analytics. |
| Usercentrics | Yes | No | Native templates cover Google services; custom dataLayer setups still need validation. |
| Didomi | Yes | No | Purpose and vendor consent can be mapped into the four Google signals. |
| Termly | Yes | No | Use the Consent Mode integration and test regional defaults in Tag Assistant. |
| Osano | Yes | No | Policy categories can drive consent updates after banner interaction. |
| Complianz | Yes | No | Common on WordPress and WooCommerce; verify GTM container order. |
| CookieYes | Yes | No | Enable Consent Mode v2 in settings, then confirm all four signals are present. |
| Pandectes | Yes | No | Common on Shopify; test checkout and post-purchase pages separately. |
Consent modeling + conversion modeling
When users deny consent, Google cannot use the same identifiers or storage it would use for a fully consented visitor. Consent Mode gives Google a structured denied signal instead of silence. Where eligibility requirements are met, Google can use observed behavior from consented users, aggregate patterns, and campaign context to model the conversions that are likely missing from unconsented traffic.
Modeled conversions are not a row-level reconstruction of denied users. They are aggregate estimates designed to reduce reporting bias while respecting the user's denied state. The cleaner your defaults, update timing, conversion action setup, and event taxonomy are, the more likely Google can evaluate the traffic consistently.
Volume matters. For planning, use a 1,000-click minimum threshold per relevant country and domain grouping before expecting stable modeled conversion reporting. Smaller accounts may still send Consent Mode correctly, but modeled conversions can be delayed, sparse, or absent when the system does not have enough eligible signal.
The basic vs advanced decision tree
Do you have legal approval for cookieless pings before consent?
No → Deploy Basic mode.Yes → Continue.Can you guarantee denied defaults before every Google request?
No → Deploy Basic mode until load order is fixed.Yes → Continue.Does your CMP update all four v2 signals on every consent change?
No → Fix CMP mapping before launch.Yes → Continue.Does server-side tracking receive consent with every event?
No → Add TrackLayer consent forwarding before launch.Yes → Advanced mode is technically viable.Do you need the most conservative EU posture for a high-risk market?
Yes → Basic mode may still be the right business choice.No → Advanced mode can improve diagnostics and modeling.Troubleshooting
Consent bugs usually hide in timing and transport boundaries. The banner looks correct, but one tag fired too early, a checkout page used another domain, or a server integration never received the user's updated state.
Consent is denied, but data still flows anyway
Check server-side routes, GTM server containers, direct Meta CAPI sends, and ecommerce webhooks. Browser consent does not automatically govern backend dispatch unless the consent state is attached to each event.
Modeled conversions are not appearing
Confirm Consent Mode pings are received, conversion actions are eligible, traffic volume is sufficient, and reporting has enough time to process. Use roughly 1,000 eligible ad clicks as a planning threshold before expecting stable modeled reporting.
The CMP breaks gtag or overwrites consent
Search for duplicate default commands. The earliest default should set denied state, and later CMP callbacks should call update rather than reinitializing the Google tag.
Consent states differ across domains
Audit domain, subdomain, checkout, and payment return pages. Persist consent with a shared CMP configuration and pass consent through redirects when storage boundaries prevent automatic sharing.
Tag Assistant shows missing ad_user_data
Upgrade old Consent Mode implementations. v1 setups often include ad_storage and analytics_storage but omit the two v2 advertising signals.
TrackLayer suppresses more events than expected
Open the destination log and compare region, CMP source, timestamp, and purpose mapping. Most over-suppression comes from unknown consent being treated as denied for governed regions.
FAQ
Is Consent Mode v2 the same as GDPR compliance?
No. Consent Mode v2 is a technical way to communicate consent choices to Google and your tracking pipeline. GDPR compliance also depends on your legal basis, banner language, record keeping, vendor disclosures, retention, and user rights process.
How does CCPA differ from GDPR here?
GDPR usually centers on opt-in consent for EU personal data use. CCPA and CPRA often center on notice, opt-out, sale or sharing restrictions, and sensitive personal information rules. A serious implementation supports both by region rather than treating one banner rule as global truth.
How does this relate to iOS 14.5 ATT?
ATT is Apple's app tracking permission framework. Consent Mode v2 is Google's consent signaling framework for Google tags, apps, and uploads. They can both affect the same user journey, but they are different controls and should not be mapped as if one automatically grants the other.
Can consent be shared across subdomains?
Usually yes when the CMP cookie is configured on the parent domain and every subdomain loads the same CMP project. Checkout domains, embedded payment pages, and country-specific domains need separate testing.
What happens when a user changes consent dynamically?
Call gtag consent update immediately and send the new state with future TrackLayer events. For destinations that store audience data, also follow the platform process for removing or excluding user data when withdrawal requires it.
How should server-side CAPI handle consent?
Server-side APIs should receive explicit consent with every event. TrackLayer can then suppress, transform, or forward the event per destination, so Meta CAPI, Google Ads, TikTok Events API, and GA4 do not drift away from the user's current choice.