Two reads settle it. In a private window, before you touch the banner, run google_tag_data.ics.entries in the browser console and confirm all four signals carry a default: ad_storage, analytics_storage, ad_user_data and ad_personalization. Then open the network panel and read the gcs parameter on the first request your Google tags send. That is the state Google actually received.
Why the toggle in your CMP cannot answer this
Every consent tool now has a settings page with Consent Mode v2 on it, and a green toggle there is the evidence most people accept. It is a statement about configuration. What decides whether Google is receiving anything is what happens in a real browser on a real page load: whether the signal exists, whether it exists early enough, and whether all four of its parts are present.
Those are three separate failures, and a toggle sees none of them. A hosted checker will do the first pass and is a fine place to start. What it cannot do is come back as a returning visitor, or load your site from a second region, and that is where this usually breaks. The checks below take about ten minutes.
How to check your cookie banner is sending the Consent Mode v2 signal
Open the site as a first time visitor in a region you serve
Use a private window so no earlier choice is stored, and test from a region where your banner is supposed to appear. Defaults are frequently scoped by geography, so a page loaded from outside that scope can look broken while behaving exactly as configured. If no banner shows at all, settle the geography question before you conclude anything else.
Read all four signals before you touch the banner
In the browser console, run
google_tag_data.ics.entries. It prints one entry per consent type with the default it was given and any update that followed. Four names have to be there:ad_storage,analytics_storage,ad_user_dataandad_personalization. The last two are what version 2 added, and they are the pair that goes missing on setups wired before 2024 and never revisited.Confirm the default landed before the first tag fired
Open the network panel and reload with the banner still untouched. The first request your Google tags send should already carry a consent state. If a state only appears on later requests, the default is being set after the tags initialise, which is worth as little as having no default: the opening hit of every session goes out ungated. Trigger order is where this usually breaks, and we walk through the correct wiring in how to install a cookie banner with Google Tag Manager.
Read the state on the request itself
Find the
gcsparameter on that request.G100means both storage types denied,G111means both granted, andG101orG110are the mixed states;G1--means the tag fired with no consent state attached at all. Note the limit while you are here, because this is the step most guides stop at:gcsencodesad_storageandanalytics_storageand nothing else. It cannot confirm either of the signals version 2 introduced, which is why step 2 is not optional. A second parameter,gcd, carries more of the picture, but Google does not publish how to read it, so it is not something to lean on. The full decode, and what it tells you about which mode you are running, is in basic versus advanced Consent Mode.Make a choice and watch the update arrive
Accept, then run the console read again. The signals you granted should flip in place, and a fresh request should leave carrying the new state, with no page reload involved. Then start over in a clean private window and reject instead, because the two paths fail independently. A setup that only reflects the choice after a reload is losing every event between the click and the next page load.
Come back as a returning visitor
Close the window, open the site again, and read the entries before the banner has any chance to render. A stored choice has to replay as the default on that first load, ahead of the tags. This is the check that gets skipped, and repeat visits are where a banner that passes everything else quietly stops sending the right answer.
Three ways a clean read is still wrong
The default is granted. Every signal is present, the update flows, the request carries a state, and the banner still asks a question it has already answered on the visitor's behalf. The wiring is fine; the starting position is wrong, and it is invisible unless you look before the click rather than after it.
Only your Google tags are gated. Consent Mode is a Google mechanism. The rest of your stack does not read these entries and does not care what the request said. Those tags need their own gating, and nothing in this procedure will tell you it is missing.
It passes on the page you happened to test. The consent layer initialises per page. A checkout on another subdomain, or any page that loads its container differently, can give a different answer. Test one page of each type.
What the signal is worth once it works
This is not a compliance formality with a measurement side effect. It decides how much of your traffic stays visible. Across Amplio Data client implementations the measured baseline is around 34% of sessions sitting behind the banner, with 20 to 40% of the lost conversions recoverable once the four signals are set the way Google expects. Figures are measured ranges across Amplio Data client implementations, not a guarantee. Recovery depends on your traffic mix, regions and how your tags are configured.
Most of that difference sits between a banner that sends the signal and one that merely claims to, and no report labels the gap for you. What a denial actually costs, and what modelling gives back, is in what happens to your GA4 data when users reject cookies.
The short version
The consent state in the browser shows all four signals, their defaults and their order; the request parameter shows what Google received for two of them. If the four names are present, denied before the click, updated in place after it, and replayed on the next visit, your banner is sending the Consent Mode v2 signal. A toggle in a dashboard is not evidence of any of that.
Velo sets all four from one snippet, before your tags initialise, and replays a stored choice on the visit after. The mechanism is on the product page.
Common questions
How do I check my cookie banner is sending the Consent Mode v2 signal to Google?
Two checks together. In a private window, before touching the banner, read the consent state in the browser console and confirm all four signals exist with a default: ad_storage, analytics_storage, ad_user_data and ad_personalization. Then open the network panel and confirm the first request your Google tags send already carries a consent state. Accept, and confirm the state flips in place and a new request leaves with the updated value. Neither check on its own is enough: the browser read cannot prove what Google received, and the request cannot show you two of the four signals.
Does the gcs parameter prove Consent Mode v2 is working?
No. It encodes ad_storage and analytics_storage only, so it reports the two signals that existed in version 1 and stays silent about ad_user_data and ad_personalization, which are exactly the two version 2 added. A site can show a perfectly correct value on every request and still be sending nothing for half the signal. Read the parameter for what Google received on the storage types, and read the consent state in the browser for the other two.
My CMP says Consent Mode v2 is enabled. Is that enough?
It tells you the feature is switched on in that product, which is a statement about configuration rather than about what happens on your pages. The three things that break in practice are all invisible from a settings screen: signals that are never set, signals that are set after the tags have already fired, and a stored choice that fails to replay on a repeat visit. Verify in the browser instead, on a real page load.
What should the consent state be before someone clicks the banner?
In regions where you are required to ask first, every non essential signal should be denied by default, and that default has to be in place before any tag initialises. Security and functionality signals staying granted is normal. A granted default with a banner on top of it is the common failure: the page looks compliant and the tags have already run as though consent were given.