Consent Mode v2: what it changes for your cookie banner
Consent Mode v2 changes what your banner must do before any Google tag fires: without valid consent, tags run in a restricted mode with no identifiers, and the banner must offer genuine accept and reject choices that map to the new consent states. Banners that only collect a single accept click are no longer enough.
What Consent Mode v2 actually requires
Consent Mode v2 adds two consent states, ad_user_data and ad_personalization, alongside the existing analytics_storage and ad_storage. Google tags read these states before deciding what they may do. Without consent, tags still fire, but in a restricted mode: no identifiers, no personalization, cookieless pings only. The banner's job is no longer just recording a yes or no. It is setting four distinct states correctly and keeping them in sync with what the tags assume.
The practical consequence: a banner that collects a single accept click and calls it consent is now visibly incomplete. Regulators and Google both expect granular choice, and the gap between a one-button banner and the four-state model is where enforcement risk lives.
Reject must be as easy as accept
The requirement that refuse be as easy as accept is not new, but Consent Mode v2 makes violations easier to detect. When a banner offers a prominent accept button and buries reject in a second layer, the resulting consent states skew heavily toward granted. That skew is measurable, and data protection authorities have started treating lopsided consent rates as evidence of an unfair interface.
Audit your own banner the way a regulator would: count the clicks to reject, compare the visual weight of the two choices, and check whether the default state of every toggle is off. If rejecting takes meaningfully more effort than accepting, the consent you collect is built on sand.
The banner and the tags must agree
The most common implementation failure is a mismatch between what the banner records and what the tags do. The banner says the user rejected analytics, but the tag fires with analytics_storage granted because the default state was never updated. Or the banner updates consent on the page where it was shown, but the state does not persist to the next page view.
Test the full loop: set each combination of choices, then inspect the actual consent state the tags receive. This is a technical test, not a visual one, and it needs to run after every banner or tag change. Consent interfaces drift out of sync silently, and silent drift is the most expensive kind.
Document the state, not just the click
When a regulator asks how you obtained consent, a timestamped record of accept clicks is only half the answer. You also need the state that resulted: which purposes were granted, which were denied, what the banner showed at the time, and which version of the banner it was. Consent Mode v2's four states make this record more detailed, and more valuable as evidence.
Store the full consent state with each record, version your banner text, and keep the mapping between banner choices and consent states explicit in your implementation. If you ever need to prove that a specific user's analytics consent was valid, this record is the proof.
Do not wait for the audit letter
Consent Mode v2 has been a requirement for advertisers in the EEA for a while now, and enforcement attention keeps widening from the largest sites downward. The sites that scramble after an inquiry always pay more, in remediation cost and in fines, than the sites that fixed their banners proactively.
The upgrade is bounded work: map your purposes to the four states, make reject genuinely equal, verify the tag behavior for every combination, and document the state. A week of focused work now beats a year of arguing with a regulator later.
Keep a change log for the banner
Every banner change, a reworded purpose, a new vendor added, a layout tweak, potentially changes the legal basis of the consent you collect. Keep a dated change log of the banner text, the purposes listed, and the vendors disclosed, so that any consent record can be matched to the exact banner the visitor saw. When purposes or vendors change materially, re-prompt existing visitors rather than grandfathering their old consent into new processing.
This discipline pays off the first time anyone asks questions. A regulator, a partner, or your own legal team can trace any consent decision to its context in minutes. Without the log, you are reconstructing history from memory, and memory is not evidence.
Frequently asked questions
What does Consent Mode v2 change for a cookie banner?
It adds more specific consent signals that the banner must collect and pass on, particularly around advertising data uses. The banner choices need to map to those signals accurately, not just store a general accept or reject.
Does Consent Mode replace the need for a banner?
No. Consent Mode communicates choices to tags. The banner is still how the visitor makes and changes those choices, and blocking and record keeping duties remain with your setup.
What should be checked after enabling Consent Mode v2?
That each banner choice produces the correct signal states, that tags behave accordingly before and after choices, and that records match the signals sent. Test reject and partial choices, not only accept all.