Consent Mode v2 in 2026: an EU checklist that holds up

Google has required consent signals, including the two Consent Mode v2 parameters, for EEA traffic for some time, so most sites have something in place. The problems that remain are quieter: defaults set too late, a v2 parameter that never updates, or a CMP that still writes old consent strings. On top of that, 2026 changed how consent signals govern GA4 data. This checklist covers what Google currently requires, what changed this year and how to verify a setup in a way that will stand up to a client or an auditor.

What does Google require for EEA traffic?

Google's page "Updates to consent mode for traffic in European Economic Area (EEA)" sets the baseline. If you measure EEA users with Google tags, you must collect consent for the use of personal data and pass it to Google. This applies to measurement and to ad personalisation and remarketing. Google ties it to stricter enforcement of its EU user consent policy (EU UCP).

The consent mode API carries four parameters, each granted or denied:

The last two are the "v2" additions. Google's consent mode reference says ad_user_data is needed for measurement use cases such as enhanced conversions and tag-based conversion tracking. Both ad_user_data and ad_personalization must be granted for personalised advertising.

Basic or advanced: which one are you running?

Google describes two implementations, and many sites don't know which one they have.

• Basic. Google tags are blocked until the user interacts with the banner. Nothing is sent to Google before that, not even the default consent state.
• Advanced. Google tags load on every page, before the banner, and adjust their behaviour to the consent state. When consent is denied they set no cookies and send cookieless pings with the consent state and limited functional information.

Google says the cookieless pings contain items such as timestamp, user agent and referrer, plus aggregate signals like whether an ad click happened. Ad click identifiers such as GCLID are redacted. The pings go through a different domain so that previously set third-party cookies are not sent.

The practical difference is modelling. Google says advanced mode supports an advertiser-specific conversion model, while basic mode relies on a general model. In GA4, behavioural modelling uses the behaviour of consenting users to estimate the behaviour of users who declined analytics cookies.

Which one to use is partly a legal question, because advanced mode sends pings before consent. Decide it with whoever owns privacy for the site, write the decision down, and make sure the implementation matches it.

Tracking Whisper

What changed in 2026?

Two changes this year affect consent setups, and a third is still to come.

GA4 now follows Consent Mode for Google Ads identifiers (15 June 2026). Google's page "Updates to Google Analytics Data Controls" says that from 15 June 2026, Google Analytics uses Consent Mode as the single control for collecting Google Ads cookies and IDs. From the same date, the Google signals setting in GA4 admin and the Google signals API only control whether GA4 data is associated with signed-in user information for behavioural reporting. If you relied on switching off Google signals to limit advertising data, that switch no longer does what it did. Your consent signals do.

Ads personalisation for linked properties (later in 2026). The same page says that, later in 2026, the ad_personalization consent signal will exclusively control whether GA4 data in a linked Google Ads account is used for personalisation. Google's stated principle is that for linked properties Google Ads settings govern Ads data, and GA4 settings govern data used for behavioural reporting in GA4. Check the help page for the current status before you change property settings.

TCF v2.3 (28 February 2026). If your consent platform uses the IAB Europe Transparency and Consent Framework, Google's help pages say TCF v2.3 is mandatory for TC strings generated from 28 February 2026. A v2.3 string must contain the Disclosed vendors section, and Google expects to find Google Advertising Products (vendor ID 755) there. On the publisher side, Google reports a missing, malformed or Google-less section as error 1.4, and such ad requests may fall back to Limited Ads.

The checklist

Work through it on a staging copy if you can, otherwise in a Tag Manager workspace with Preview mode.

Defaults and timing

1. A default state is set before any Google tag fires. In GTM, the tag that sets defaults (usually the CMP template) fires on the Consent Initialization - All Pages trigger, which each web container has by default and which runs before all other triggers.
2. Defaults cover all four parameters. A default that only sets ad_storage and analytics_storage leaves the v2 parameters unset.
3. EEA defaults are denied. Unless you have a documented legal basis for something else, all four parameters default to denied for EEA visitors.
4. The default comes before the config. In a gtag.js setup, the consent default call appears above the Google tag snippet.

<script>
  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'
  });
</script>
<!-- Google tag (gtag.js) snippet goes after this block -->

Updates from the banner

1. Every banner choice sends an update. Accept all, reject all and each granular save push a consent update. Rejecting is a choice too and should be recorded as denied, not skipped.
2. The v2 parameters are mapped. Check how your CMP maps its categories (often "marketing" or "advertising") to ad_user_data and ad_personalization. A mapping that only updates ad_storage is the most common v2 gap.
3. Returning visitors get their stored choice at once. On a second page view, the CMP should set the stored state before tags fire, not after a delay.

// What a CMP should run when the user accepts advertising and analytics
gtag('consent', 'update', {
  'ad_storage': 'granted',
  'analytics_storage': 'granted',
  'ad_user_data': 'granted',
  'ad_personalization': 'granted'
});

Tag configuration in GTM

1. No tag sits under "Consent Not Configured". Open Tags > Consent Overview. Google tags have built-in consent checks. Every other tag should require the additional consent it needs, under Advanced Settings > Consent Settings.
2. Non-Google marketing tags are gated. Meta, LinkedIn and similar pixels don't read Google's consent state by themselves. Require ad_storage (and, where your policy says so, ad_user_data) as additional consent, or trigger them on a consent event from your CMP.
3. Basic mode really blocks. If you chose basic mode, check that no Google tag fires before the banner interaction, including tags hard-coded in the theme.

Verification

1. Check Tag Assistant. Google's troubleshooting guide uses Tag Assistant to check the consent state per event. You should see the default on the first event and the update after the banner interaction.
2. Check the requests. Consent state travels in request parameters. gcs carries the ad_storage and analytics_storage state, and gcd encodes the full consent choice and is sent whether or not consent mode is active. Compare the values before and after accepting.
3. Check the reports. In Google Ads and GA4, look at the consent status shown for your tags and properties. After the June 2026 change, review GA4's consent settings page and make sure it reflects what your banner does.

Downstream

1. Enhanced conversions follow ad_user_data. If user-provided data is sent while ad_user_data is denied, that is a mismatch to fix in the tag or the trigger.
2. Offline and server-side uploads carry consent. Data you send outside the browser, such as Customer Match lists or imported conversions, needs its own consent handling. Google publishes separate consent guidance for Customer Match.

Tracking Whisper

How do you keep it from breaking again?

Consent setups rarely fail at launch. They fail months later when someone updates the CMP, adds a tag without consent settings, or the theme changes and the default call moves below the Google tag. Three habits help:

• Re-test after every CMP or theme release. Run the verification steps 11 to 13 on your key templates.
• Review Consent Overview at every container publish. Any new tag under "Consent Not Configured" should block the publish.
• Monitor consent rates. A sudden drop in the share of granted analytics consent, or a jump to 100%, usually means a broken mapping rather than a change in users. Automated tracking monitoring catches this faster than a monthly report.

If you are also looking at the new Google tag setup in Tag Manager, read our note on Google tag and GTM destinations: optimising a container is a good moment to re-check consent settings on every Google tag. The consent mode glossary entry has the short definitions.

Tracking Whisper

Key takeaways

• EEA traffic needs all four consent parameters, including ad_user_data and ad_personalization, set by default before any tag fires and updated from the banner.
• Basic mode sends nothing before consent. Advanced mode sends cookieless pings and supports advertiser-specific modelling. Choose deliberately and document it.
• Since 15 June 2026, Consent Mode, not the Google signals setting, controls the collection of Google Ads cookies and IDs in GA4. Ads personalisation for linked properties follows ad_personalization later in 2026.
• CMPs using IAB TCF had to move to v2.3 by 28 February 2026, with Google (vendor 755) in the Disclosed vendors section.
• Verify in Tag Assistant and in the gcs and gcd request parameters, and re-test after every CMP or theme update.

Tracking Whisper checks key pages in a real browser, including the consent state, the dataLayer and the hits that leave the page. It also monitors tracking and raises an alert when something stops working.