GA4 and Consent Mode v2 in the EU: what it is, how to implement it and how it affects your data

Why Consent Mode v2 exists

In the European Union, storing or reading cookies and identifiers on a user's device for analytics or advertising purposes generally requires their prior consent. That obligation comes from the ePrivacy rules (transposed in Spain by Article 22.2 of the LSSI) and is read together with the GDPR. Spain's data protection authority, the AEPD, publishes guidance on the use of cookies that is worth reviewing, as it is updated to stay aligned with European criteria; other EU regulators publish their own equivalents.

Separately, Google has for years maintained an EU user consent policy requiring anyone using its advertising and measurement products to obtain valid consent from users in the EEA. When the Digital Markets Act (DMA), which designated Google as a "gatekeeper", began to apply, Google tightened those requirements. From March 2024, Google started requiring advertisers who want to keep using ad measurement, personalisation and remarketing features with EEA users to send it explicit consent signals. Those signals are what version 2 of Consent Mode introduces.

Consent Mode is not a cookie banner and does not make you compliant on its own. It is a technical mechanism that passes the decision the user makes in your banner (your consent management platform, or CMP) on to Google's tags.

The consent signals

Consent Mode works with consent types that can be in a granted or denied state. The four that matter for GA4 and Google Ads are:

Signal	What it controls	Since
analytics_storage	Storage of cookies and identifiers for analytics purposes (for example, the GA4 cookie)	Version 1
ad_storage	Storage of cookies and identifiers for advertising purposes	Version 1
ad_user_data	Whether user data may be sent to Google for advertising purposes	Version 2
ad_personalization	Whether data may be used for personalised advertising, such as remarketing	Version 2

There are other types (functionality_storage, personalization_storage, security_storage) that some CMPs use for non-advertising cookie categories, but they do not affect how GA4 or Google Ads behave.

The key idea in version 2 is separating two different questions: may I store cookies? (ad_storage) and may I use this person's data for advertising and personalisation? (ad_user_data and ad_personalization). Your banner must collect consent in a way that allows all four signals to be set correctly.

Basic mode and advanced mode

There are two ways to implement Consent Mode, and the difference has technical and legal consequences:

	Basic mode	Advanced mode
Tag loading	Google tags do not load until the user accepts	Tags always load, with consent denied by default
If the user declines	Nothing is sent to Google	Cookieless pings (without persistent identifiers) are sent with limited information
Modelling	Google applies a general, less precise model	Enables modelling specific to your site, if volume requirements are met
Complexity	Lower	Higher: you need to check in detail what is sent in each state

Advanced mode gives more input for modelling, but it means some data (albeit without cookies) is sent before consent is obtained. There are differing views on whether that is compatible with the rules in every case, so the choice between basic and advanced should be validated by your legal adviser or DPO, not just by the marketing team.

Choosing and configuring a CMP

The CMP is the tool that displays the banner, records the user's decision and communicates it to your tags. When choosing one, check for:

• Native Consent Mode v2 integration. The most widely used CMPs have a template in the Google Tag Manager gallery and send all four signals. Google runs a certified CMP programme; if you also use publisher products such as AdSense or Ad Manager, Google requires a certified CMP integrated with the IAB TCF for traffic from the EEA and the UK.
• A compliant design. Rejecting must be as easy as accepting (a "Reject" button on the first layer, with equal prominence), with no pre-ticked boxes and clear information per purpose.
• Consent records. You need to be able to show what each user agreed to and when.
• Ongoing management. A permanent link (in the footer, for example) so users can change their mind.
• Cookie scanning. A periodic scan that detects new cookies introduced by plugins or integrations.

The mapping between banner categories and Consent Mode signals must be explicit. A common set-up: the "Analytics" category controls analytics_storage; the "Advertising" or "Marketing" category controls ad_storage, ad_user_data and ad_personalization.

Step-by-step implementation with Google Tag Manager

1. Enable the consent overview. In the GTM container settings, switch on the consent overview option. It lets you review on a single screen which consent each tag requires.
2. Add your CMP's template from the Community Template Gallery and configure it with the Consent Initialization – All Pages trigger, which fires before any other.
3. Set the default state. In the template, set all four signals to denied for EEA users (you can limit defaults to particular regions). If the CMP is slow to load, the wait_for_update parameter tells tags how many milliseconds to wait before sending data.
4. Review each tag's consent settings. Google tags (the Google tag, GA4, Google Ads, Floodlight) have built-in consent checks: they read the signals and adapt their behaviour. Third-party tags (other platforms' pixels) do not understand Consent Mode, so you must configure "additional consent checks" so they do not fire without the relevant category.
5. For basic mode, make Google tags fire only when consent has been granted. For advanced mode, let them fire and rely on the built-in checks.
6. Publish to a test environment and verify before going live (see the next section).

If you use gtag.js directly rather than GTM, the default state must be declared before the Google tag loads:

<script>
  window.dataLayer = window.dataLayer || [];
  function gtag(){dataLayer.push(arguments);}
  gtag('consent', 'default', {
    'ad_storage': 'denied',
    'ad_user_data': 'denied',
    'ad_personalization': 'denied',
    'analytics_storage': 'denied',
    'wait_for_update': 500
  });
</script>
<script async src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXX"></script>

When the user accepts, the CMP must send the corresponding update:

gtag('consent', 'update', {
  'ad_storage': 'granted',
  'ad_user_data': 'granted',
  'ad_personalization': 'granted',
  'analytics_storage': 'granted'
});

In practice, your CMP generates this code for you. What matters is understanding the order: default state first, then tag loading, then the update. Getting the order wrong is behind most failures.

How to check that it works

1. GTM preview mode (Tag Assistant). Select the first event and open the consent tab: you will see the default state, the update and the final state of each signal. Check that the default state is set on the consent initialisation event, before any tag fires.
2. Network requests. In your browser's developer tools, filter requests to Google Analytics and look for the gcs parameter. Its value summarises the state of ad_storage and analytics_storage: G100 means both denied; G111, both granted; G101, analytics only. The gcd parameter also encodes the version 2 signals.
3. Cookies. With consent declined, no analytics or advertising cookies (such as _ga) should be created. Check the storage tab of your browser in a private window.
4. All three scenarios. Test accepting everything, rejecting everything and accepting analytics only. Each combination must be reflected correctly in the signals.
5. Google's own dashboards. Google Ads shows in its conversion diagnostics whether it is receiving consent signals; GA4 includes a consent status for ad measurement and personalisation in the data stream settings. Check both a few days after publishing.

What changes in your data

With Consent Mode, part of your audience is not measured with cookies. That has consequences worth explaining to senior management before anyone starts comparing reports:

• Fewer observed users. Users who decline do not generate identifiable sessions. Observed users, sessions and conversions fall compared with measurement that ignores consent.
• Behavioural modelling in GA4. In advanced mode, if your property meets the volume requirements Google documents, GA4 can estimate the behaviour of users who decline based on those who accept. Modelled data appears in reports when the reporting identity is set to "Blended".
• Conversion modelling in Google Ads. Google Ads estimates conversions it cannot observe directly, which helps automated bid strategies avoid working blind.
• Audiences and remarketing. Only users who have granted ad_personalization can be added to remarketing audiences.
• A break in the historical series. Annotate the implementation date in your reporting. Comparing periods before and after without that note leads to wrong conclusions.

Modelling is not an exact recovery of lost data: it is a statistical estimate. Use it for trends and aggregate decisions, not to audit individual visits.

Beyond Consent Mode: first-party and server-side measurement

Consent Mode governs how Google's tags behave, but it is not your whole measurement strategy. Three complements worth considering:

• Server-side tagging. With a GTM server container, data passes through an endpoint you control before it reaches Google or other platforms. It lets you filter or strip information, improve page performance and govern what is shared. It does not replace consent: the same rules apply, and Consent Mode signals must travel through the server too.
• First-party conversions. Enquiries, bookings or sales recorded in your CRM are business data that do not depend on cookies. Importing them (on an appropriate legal basis) gives a fuller picture than web analytics alone.
• Search Console. Organic performance data in Search Console does not depend on the cookie banner, so it is a stable reference for search traffic when observed data in GA4 falls.

Common mistakes

• A late default state. Tags fire before the CMP sets the default, and send data as if consent had been given.
• Version 1 only. The banner sends ad_storage and analytics_storage, but not ad_user_data or ad_personalization.
• Hard-coded tags in the theme. A GA4 tag pasted directly into the site template, alongside the GTM one, that ignores consent.
• Uncontrolled third-party pixels. Other platforms' tags firing without additional consent checks.
• A blocked or slow banner. A CMP that is slow to load makes the wait_for_update value insufficient.
• Never re-checking. Every new plugin, integration or theme change can break the set-up. Verification should be part of your release process.

Conclusion

Consent Mode v2 is the technical piece that connects the user's decision with how GA4 and Google Ads behave. Implemented well, it respects that decision and keeps your measurement useful thanks to modelling; implemented badly, it leaves you without reliable data or sending data you should not. If you want your set-up reviewed, our analytics and data service audits consent, tagging and conversion measurement end to end. And if you are deciding how to split investment between channels, you may find our comparison of SEO and Google Ads useful. For technical terms, see the glossary.