If you advertise with Google in the European Economic Area, Consent Mode V2 is not optional. It has been a requirement since March 2024, and accounts without it lose access to features they may not realize they were using.
Two years on, almost nobody fails this because they have never heard of it. They fail it because somebody installed a cookie banner, the banner's own dashboard says consent mode is enabled, and nothing has been tested since. That is a different problem, and it is the one this page is now mostly about.
Here is what V2 actually is, what changed from V1, and how to tell whether the thing you have is doing what you think.
What is consent mode V2 and why did Google introduce it?
It is the mechanism your site uses to tell Google's tags what a visitor agreed to, expanded in V2 with two additional advertising signals and made mandatory for EEA and UK traffic.
Consent mode is the mechanism by which your website tells Google's tags what a user consented to. Rather than blocking tags outright when someone declines, it can let them run in a restricted state that respects the choice while still providing signals Google can model from.
That "can" is doing real work. Consent Mode comes in two flavours, basic and advanced, and only advanced behaves the way the paragraph above describes. Basic blocks the tags until consent is granted, which means no restricted state, no cookieless signal and nothing to model from. Both are valid, they suit different organisations, and the choice is usually made by accident. We wrote about what each one costs you separately, because it is the decision that most affects how much data you keep.
V2 is an expansion of that framework. It adds two new signals specifically covering how user data may be used for advertising, and it makes implementation mandatory for advertisers serving users in the EEA and UK.
The driver is the Digital Markets Act, which requires designated gatekeepers, Google among them, to obtain and honor explicit end user consent before using personal data for advertising purposes. Google's response was to require advertisers to pass that consent signal explicitly, rather than assuming it.
The practical effect is that consent handling moved from a compliance nicety to a technical prerequisite for using large parts of the Google advertising stack.
What is the difference between consent mode V1 and V2?
Two things changed. V2 adds two advertising specific signals to the original pair, and it moved from recommended to required for EEA and UK traffic, with automatic consequences rather than discretionary ones.
V1 established the framework with two signals:
ad_storage, governing whether advertising cookies and identifiers may be stored
analytics_storage, governing whether analytics cookies may be stored
Both are about storage. They answer the question of whether something may be written to the user's device.
V2 keeps both and adds two more:
ad_user_data, governing whether user data may be sent to Google for advertising purposes
ad_personalization, governing whether that data may be used for personalized advertising and remarketing
These are about use, not storage. That distinction is the whole point of the update. A user might allow a cookie to be set while not consenting to their data being used to build an advertising profile, and V1 had no way to express that difference.
The other change is enforcement. V1 was recommended. V2 is required for EEA and UK traffic, and the consequences of not having it are automatic rather than discretionary.
What do the new V2 signals cover?
Two signals, both about advertising rather than storage: whether user data may be sent to Google at all, and whether it may be used to personalise ads. Between them they decide whether Enhanced Conversions, Customer Match and remarketing work for a given visitor.
ad_user_data answers whether you may send user data to Google for advertising purposes at all. When denied, Google Ads conversion tags cannot transmit user provided data such as hashed emails. This directly affects Enhanced Conversions and Customer Match, both of which depend on sending identifiers to Google for matching.
ad_personalization answers whether the data may be used to personalize advertising. When denied, that user cannot be added to remarketing audiences or used for personalized targeting. They can still be served contextual advertising.
Both are independent of the storage signals. A valid combination is storage granted, personalization denied: cookies may be set for measurement, but no advertising profile may be built.
Your consent banner needs to actually collect enough granularity to set these correctly. A banner offering only Accept All and Reject All can map both cases, but a banner with granular categories needs those categories mapped thoughtfully to the four signals.
What happens to my campaigns without consent mode V2?
The consequences apply to EEA and UK traffic specifically, and they are cumulative. Audience features stop working for affected users, conversion modelling becomes unavailable, Enhanced Conversions degrade, and warnings start appearing in your account. None of it is a penalty you can appeal.
Audience features stop working for affected users. Without ad_personalization granted, users cannot be added to remarketing lists. Existing audiences shrink over time as membership expires and is not replenished. Remarketing and Customer Match campaigns lose reach, gradually enough that the cause is easy to miss.
Conversion modelling becomes unavailable. Without proper consent signals, Google cannot model the conversions it did not directly observe. Your reported conversions reflect only consenting users, which understates performance and biases what smart bidding learns from.
Enhanced Conversions degrade. Without ad_user_data, the hashed first party data that improves match rates cannot be sent, so conversion matching quality falls.
Warnings appear in your account. Google surfaces consent mode warnings in Google Ads, though they are easy to overlook among other notifications.
None of this stops your ads serving. That is what makes it insidious. Campaigns keep running, reporting keeps producing numbers, and performance quietly degrades in ways that look like market conditions.
How do I implement consent mode V2 with my existing CMP?
You do not need to replace your consent platform. Most established CMPs already support V2 and simply need it enabled. Confirm that, set all four signals to a default state before any tag loads, map your banner's categories onto them, fire the update command when the visitor chooses, and handle non Google tags separately.
Confirm your CMP supports V2. Cookiebot, OneTrust, Complianz, Usercentrics, Axeptio and others all do. Check the version and that V2 mode is switched on, because many accounts are still running a V1 configuration.
Set the default state before any tags load. All four signals must default to denied before your GA4 or Google Ads tags execute. In Google Tag Manager this means using the Consent Initialization trigger, which fires before All Pages. This ordering is the most common point of failure, and getting it wrong produces a setup that looks correct while leaking data on first page load.
Map your banner categories to all four signals. Decide explicitly which of your consent categories grants ad_user_data and which grants ad_personalization. Do not assume the CMP defaults match your intent.
Fire the update command on user choice. When someone interacts with the banner, an update command must communicate the result to Google's tags.
Configure consent settings on non Google tags. Google tags read the signals automatically. Third party tags need consent requirements declared explicitly in GTM.
How do I verify consent mode V2 is working?
Five checks, and the one that matters most is the decline path, because an implementation that looks perfect on accept can still be broken for the visitors it exists to protect.
Use GTM preview mode. Load your site and check the Consent tab. It shows the state of each signal at each step. Confirm all four default to denied on initial load, before any tags fire.
Test the decline path specifically. Reject consent and confirm Google tags still fire in restricted mode rather than not firing at all. If they do not fire, you have blocking rather than consent mode, and you are losing the modelling benefit entirely.
Test the accept path. Confirm all four signals flip to granted and tags switch to full behavior.
Read the requests themselves. GTM preview tells you what the container believes. The network tab tells you what actually left the browser. Decline the banner and look at any request to Google for its gcs parameter: G100 means the denial is being reported correctly, G111 after a decline means it is not and you are tracking people who said no. The full walkthrough is in our piece on whether rejecting cookies actually stops tracking.
Check Google Ads. Look under Tools, then Data Manager, or in your account notifications, for consent mode diagnostics. Google reports whether it is receiving valid signals.
Watch modelled conversions appear. Once V2 is working and you have enough volume, modelled conversions show up in your GA4 and Google Ads reporting. Their presence is the clearest confirmation the implementation is functioning. Their absence is not proof of failure, though: modelling has thresholds, Google has changed them more than once, and a smaller site can be correctly configured and still never see a modelled conversion. Check the current requirements against your own traffic before reading silence as a fault.
The short version
If you advertise to European users and have not explicitly confirmed V2 is implemented, assume it is not. Having a cookie banner is not the same thing, and the failure mode is silent degradation rather than an error message.
Two things worth keeping straight as you fix it. Consent Mode governs how Google's tags respond to a consent signal; it does not collect that signal, and it does not make your banner lawful. And it is Google's framework only, so your Meta, LinkedIn and TikTok tags need their own consent conditions. The most common finding in a consent audit is an immaculate Google setup sitting beside a pixel that fires no matter what anyone clicks.
FAQ
What is Google Consent Mode V2?
Consent Mode V2 is Google's framework for communicating user consent to its tags, expanded with two new signals: ad_user_data, covering whether user data may be sent to Google for advertising, and ad_personalization, covering whether it may be used for personalized ads. It has been required for advertisers serving EEA and UK users since March 2024.
Do I need Consent Mode V2 if I do not advertise in Europe?
It is only mandatory for EEA and UK traffic, so a purely domestic business elsewhere is not required to implement it. It is still worth doing. Proper consent handling improves data quality wherever privacy regulations apply, and implementing it now avoids a rushed retrofit if you expand or if similar requirements arrive in your market.
What is the difference between Consent Mode V1 and V2?
V1 had two signals, ad_storage and analytics_storage, both governing whether data could be stored on the device. V2 adds ad_user_data and ad_personalization, which govern how data may be used rather than whether it may be stored. V2 is also mandatory for EEA and UK advertising, whereas V1 was recommended.
What happens if I do not implement Consent Mode V2?
For EEA and UK traffic you lose access to audience features, so remarketing lists stop being populated and shrink over time. Conversion modelling becomes unavailable, understating reported performance. Enhanced Conversions degrade because user data cannot be sent. Campaigns keep running throughout, which makes the decline easy to attribute to market conditions instead.
How do I check if Consent Mode V2 is set up correctly?
Open GTM preview mode and check the Consent tab. All four signals should default to denied before any tags fire, using the Consent Initialization trigger. Decline consent and confirm Google tags still fire in restricted mode. Then accept and confirm they switch to full behavior. Google Ads also surfaces consent diagnostics in the account.