Consent Mode v2 fails quietly. There is no error, no warning in the console, and your reports keep filling up. The site looks fine and the banner appears. Meanwhile Google is receiving either no consent instruction at all, or the wrong one.
Three things go wrong, in this order of frequency: a signal is missing, a signal defaults to granted, or the default is set after the tags have already fired. You can check all three with the free Consent Mode v2 checker, or by hand with Tag Assistant.
How do you know if Consent Mode v2 is working?
Three things have to be true. All four required signals must be declared, they must default to denied, and the default command must run before any Google tag. If any one of those is missing, Consent Mode is present but not doing its job, and nothing on the page will tell you.
Our checker loads your site the way a first time visitor does, reads the dataLayer, and reports on exactly those three points. It takes about fifteen seconds and does not need an account.
The four signals v2 requires
Consent Mode v1 had two signals. v2 added two more, and both are about advertising data rather than storage:
ad_storage, whether Google may store advertising cookiesanalytics_storage, whether it may store analytics cookiesad_user_data, whether user data may be sent to Google for advertisingad_personalization, whether that data may be used for personalised ads
Google's documentation is clear that your tag has to load defaults for at least these four parameters. The two v2 additions are the ones most often missing, because a setup written for v1 still works and still looks correct.
An undeclared signal is not the same as a denied one. Google treats it as unset, which is why declaring all four explicitly matters even when the answer is no.
Why does the default have to be denied?
Because the default is what applies before the visitor has chosen anything. If analytics_storage defaults to granted, then everyone who arrives, reads a page and leaves without touching the banner has been tracked without consent. The banner made no difference to them at all.
This is a genuinely common misconfiguration, and it is easy to miss because the banner still works perfectly for anyone who clicks it. The people it fails for are exactly the people who never interact, which is most of your traffic.
The most common failure: the default is set too late
The order matters as much as the values. Google's own troubleshooting guide describes the failure case plainly: visitor opens the page, ad tag fires, default consent is then set to denied. By that point the tag has already read or written a cookie.
Google's fix is to move the consent default command higher in the page, above any tag snippets, and to never set consent defaults asynchronously. In Tag Manager, the consent tag needs the Consent Initialization trigger rather than a normal page load trigger.
Our checker reports on this specifically. It compares where the consent default appears in the dataLayer against the first Google tag call, and tells you which came first.
What does the gcs parameter mean?
Look at any Google request in your Network tab and you will see a gcs value in the form G1xy. The first digit after G1 is ad storage, the second is analytics storage, and 1 means granted while 0 means denied. So G100 is both denied, G111 is both granted, G110 is analytics granted and ads denied.
This is the fastest manual check there is. Load your site fresh, look at the first Google request, and you should see G100. Then accept the banner and you should see G111 on the next request. If it stays at G100 after accepting, your banner is not sending the update command.
An empty result can be good news
Here is the case that confuses people. You run a checker, it finds Google identifiers in the page source, but no consent signals at all. That reads like a broken setup.
It usually is not. If your consent tool blocks Google from loading until someone accepts, then during a first visit there is nothing to read, because nothing was sent. That is the stronger setup, not the broken one. Our checker reports this separately as tags being held back, rather than calling it a failure.
This is also why Consentify sites often show no Consent Mode signals on a first load. Integrations are injected after consent rather than loaded and then restricted, so there is no early request to instruct.
How do you fix it?
Work through it in this order, because each step makes the next one readable:
- Add the missing signals. All four, declared explicitly in the default command.
- Set every default to denied. If a regional configuration sets some regions differently, check that every parameter behaves the same way, not just one of them.
- Move the default above your tags. In gtag, physically higher in the head. In Tag Manager, on the Consent Initialization trigger.
- Confirm the update fires. Accept the banner and watch gcs change from G100 to G111.
- Re-run the check. A configuration that looks right in the code is not the same as one that behaves right in a browser.
If you are setting this up rather than repairing it, our Consent Mode v2 guide covers the setup from the start, and the walkthrough for GA4 and Tag Manager goes through the implementation step by step.
Consent Mode is not a substitute for blocking
Worth saying plainly, because it comes up constantly. Consent Mode tells Google what it may do. It does not stop other scripts on your page from running, and it does nothing about your Meta Pixel, your heatmap tool or your chat widget.
You need both: Consent Mode so Google behaves correctly, and consent gating so everything else does. A free GDPR scan shows what else is firing before consent on your site, which is usually more than people expect.
Want the consent signals handled for you? Try Consentify free, one domain, no watermark, no time limit.