Consent Mode v2 is how Google's tags respect the choices a visitor makes on your consent banner. Before it, a tag was on or off. Consent Mode gives tags a third state: they can run in a limited way, without cookies or identifiers, until the visitor decides.
Most of the panic around this comes from one assumption. Somebody rolls out Consent Mode, watches their GA4 numbers shrink, and concludes the implementation broke their data. It usually didn't. The more common story is that a server-side pipeline changed, or a tag template got updated, and Consent Mode took the blame because it happened to be the most recent thing on the list.
What the four signals do
Consent Mode works through a handful of states that your site communicates to Google. Four of them cover most setups.
analytics_storagecontrols whether analytics cookies, like GA4's, get written and read.ad_storagedoes the same for advertising cookies.ad_user_datacontrols whether data about the visitor may travel to Google for advertising use.ad_personalizationcontrols whether that data can fuel personalised ads, including remarketing.
The last two arrived in November 2023, with what Google calls Consent Mode v2. Until then you only had storage signals. A visitor could say yes to everything or no to everything, but there was no clean way to say "I am fine with analytics, just do not use my data for ads." Those are legally distinct choices under GDPR, and now they can be signalled that way.
What changed in 2026
Through June 15, 2026, Google Ads data had a safety net. Consent Mode was the primary control, but Google Signals (a GA4 setting) caught what Consent Mode missed. If your Consent Mode setup was wrong, Google Signals could still block data from flowing to Google Ads.
After June 15, Google Signals became reporting-only for signed-in data (Usercentrics has a plain-language summary). Consent Mode's ad_storage is now the only gate between your tags and Google Ads. GA4 still handles its own reporting, but it no longer shields your ads data.
The practical impact is that a misconfiguration that used to get caught now slides through. The legal question is whether removing that backstop counts as a material change to your processing. Under GDPR it can, which means updating your privacy notice and, depending on your jurisdiction, asking for consent again. If you have a legal team, loop them in.
Basic versus advanced
Basic consent mode is the conservative choice. Google tags stay dormant until the visitor answers the banner. It is easy to reason about, easy to verify, and it costs you measurement for anyone who ignores the banner or declines.
Advanced mode loads tags right away, but in a degraded, cookieless state. For visitors who eventually decline, Google fills the data gap with conversion modelling. You keep more signal, and you also take on a dependency you cannot independently audit.
Most ad-funded sites land on Advanced because the recovered conversions justify the uncertainty. There is no universal right answer. If swapping real measurement for modelled numbers unsettles you, stay on Basic and focus on consent-rate optimisation instead.
When it goes wrong
Everyone worries about fines. Most teams lose money to something less dramatic first: their own data quietly misbehaving.
A tag that fires before consent, or fires with the wrong signal state, is sending data you weren't cleared to send. That's the compliance side. But the measurement side shows up first and is harder to notice: a tag with ad_user_data denied, when it should be granted, quietly flattens your audience lists and conversion counts. Nobody sends an alert. The campaign reports just look worse, and you start guessing why.
Add to that the time teams burn rebuilding consent infrastructure that was not broken. They couldn't tell "consent is doing its job" apart from "something else in the pipeline broke." We documented a case where that distinction saved an unnecessary rebuild (case study).
What an audit actually checks
A tag-by-tag consent audit verifies things that a browser tab cannot tell you.
It checks whether every tag on every page respects the consent state before the banner appears, after the visitor accepts, after they decline, and after they reload. It traces whether your consent signals survive a trip through a server-side container and arrive intact at each vendor endpoint. It catches CMP updates that silently break your signal mapping. And it tells you which specific tag fired without permission, instead of just telling you that something on the page looks off.
The gap between a manual check and an audit is the gap between a hunch and evidence. A hunch is fine for your own troubleshooting. Evidence is what a compliance officer, a regulator, or a lawyer needs to see.
We run a free consent scan that handles the first pass automatically. When you need a report you can hand to someone else, we do the fuller audit, tag by tag, with a documented paper trail you can cite.
FAQ
Do I need Consent Mode v2 if I don't run ads
You need it if you have a Google tag and visitors in the EEA. Analytics-only setups can ignore the advertising signals, but getting analytics_storage wrong is its own problem. See our analytics services for what a clean measurement stack looks like.
Is Consent Mode a legal requirement
It is not. The law (GDPR, DMA, and the growing list of state laws) requires you to get lawful consent. Consent Mode is Google's mechanism for knowing what choice each visitor made. Conflating the legal obligation with the technical signal is one of the most common mistakes people make here.
Does advanced mode violate GDPR
Depends on your regulator. Advanced mode fires tags before consent, which is the part that invites scrutiny. Google argues the limited pre-consent state is a lawful approach. Some European regulators take a stricter position, particularly in Germany. Get this reviewed by someone familiar with your jurisdiction rather than trusting a template answer.
I set this up and my GA4 numbers dropped. Is the consent setup the problem
Usually not. A verified consent implementation that still shows a traffic drop means the problem is downstream. Before you spend a week rebuilding consent, check the server-side container.
Rather not do this alone
Most of this is checkable in an afternoon if you know the signatures to look for. If you'd rather someone who does this weekly confirm it, describe the problem you're trying to solve. A description beats a requirements list every time.
Have a project in this space?
A description of the problem is more useful than a list of requirements.