A cookie banner that looks right can still send the wrong signals. Tags fire before the default is set, the update never arrives, or two of the four v2 signals are missing. None of this is visible on the page.
This guide covers what a correct setup looks like and how to check each part yourself, in the browser and in Google's own tools.
What you're checking.
Consent Mode is a set of signals your site passes to Google tags. It doesn't block tags on its own. It tells them what they may store and send. A working setup has three parts.
- A default state, set before any Google tag fires. For visitors in the UK and EEA, this should normally be denied for everything except essential storage.
- An update on accept, switching the relevant signals to granted as soon as the visitor accepts.
- An update on reject or on withdrawal, keeping or returning the signals to denied.
Many sites use region-specific defaults: denied for the UK and EEA, and a different default elsewhere. If you do, test from a UK or EEA location, or the defaults you care about won't apply.
The four v2 signals.
Consent Mode v2 added two signals to the original two. All four should be set in the default and in every update.
ad_storage: whether advertising cookies can be read and written.analytics_storage: whether analytics cookies, such as GA4's, can be read and written.ad_user_data: whether user data can be sent to Google for advertising.ad_personalization: whether data can be used for personalised advertising, such as remarketing.
A common fault is a banner that still only sends the first two. Google's tags then treat the two newer signals as not set, which for UK and EEA traffic can limit what Google Ads can use.
Basic and advanced mode.
How you implement it changes what you should see when testing.
- Basic mode: Google tags don't load at all until the visitor consents. Before consent, you should see no requests to Google at all.
- Advanced mode: tags load straight away with the denied default and send cookieless pings. Google uses these to model some of the behaviour and conversions of people who declined. Before consent, you should see requests, but with consent denied and no Google cookies set.
Know which one you've implemented before you start. A request before consent is a fault in basic mode and expected in advanced mode.
Start with a quick first-visit check.
For a fast first look, the tracking checker loads your page as a first-time visitor and shows what tags and consent signals appear before any banner interaction. Then work through the manual checks below for the detail.
Test 1: GTM Preview and Tag Assistant.
If you use Google Tag Manager, start in Preview mode. Tag Assistant opens your site in a connected window.
How to check: Before touching the banner, select the earliest event in the left-hand timeline and open the Consent tab. It shows the on-page default, any update, and the current state for each signal. All four should show a default, and for UK and EEA visitors they should be denied.
Then accept on the banner, select the next event, and check an update has arrived with the right signals granted. Repeat in a fresh session and reject.
Also check timing. The default should come from a tag on the Consent Initialization trigger, or from code above the GTM snippet. If a Google tag fires before the default appears, it fired without consent information.
How to fix it: Move the default into a tag on Consent Initialization, or use your consent platform's GTM template, which normally handles this. Set each Google tag's consent settings in GTM so it waits for the right signals.
Test 2: The network tab and the gcs and gcd parameters.
Open the browser's developer tools, go to the Network tab and filter for collect. GA4 requests go to a URL containing /g/collect. Click one and look at the query parameters.
The gcs parameter carries the two original signals. It reads G1 followed by two digits: the first for ad_storage, the second for analytics_storage. 1 means granted and 0 means denied.
| gcs value | ad_storage | analytics_storage |
|---|---|---|
G100 | Denied | Denied |
G110 | Granted | Denied |
G101 | Denied | Granted |
G111 | Granted | Granted |
If there's no gcs parameter at all, the tag isn't picking up any consent state.
The gcd parameter covers all four v2 signals, including ad_user_data and ad_personalization. It's a string of numbers and letters recording each signal's state and whether it came from the default or an update.
Google hasn't published a full specification, so treat it as a check that the v2 signals are present, and use Tag Assistant to read the exact values.
How to check: On a first visit in advanced mode, expect G100 before consent. After accepting everything, the next hits should show G111. After rejecting, they should stay at G100. If an update isn't reflected on later hits, the update isn't reaching the tags.
Test 3: Cookies before and after consent.
In developer tools, open the Application tab (Storage in Firefox) and look at cookies for your domain. Clear them first, or use a private window, so you start as a new visitor.
How to check: Before any banner interaction, there should be no _ga or _ga_ cookies (GA4) and no _gcl_au cookie (Google Ads). Your consent platform's own cookie is fine. After accepting, the Google cookies should appear. After rejecting, they should still be absent.
If Google cookies are set before consent, something is firing outside Consent Mode: a hardcoded gtag.js snippet, a tag with consent checks switched off, or a default that loads too late.
Test 4: Reject and withdraw.
Most testing stops at "accept works". Rejection and withdrawal are where the faults usually hide.
- Reject on a fresh visit and check the signals stay denied, both in Tag Assistant and in
gcs. - Accept, then reopen the banner or preferences centre and withdraw consent. An update should switch the signals back to denied, and later hits should show it.
- Accept analytics only, if your banner allows it, and check
gcsreadsG101, with the ad signals still denied.
After withdrawal, Google tags stop using their cookies, but that doesn't always mean the cookies are deleted. Check what your consent platform does, and whether it meets your own policy.
Test 5: Google Ads and GA4.
Browser tests show one visit. Google's platforms show whether signals are arriving across real traffic.
In Google Ads, the conversions area reports on consent mode status and flags problems. The exact location has moved over time, so look in the conversions summary and the diagnostics for each conversion action. It can take several days of traffic before the status updates.
In GA4, Admin has a consent settings page showing whether consent signals are active for analytics and for ads personalisation. If it says signals are missing, GA4 isn't receiving them from your site.
Modelling in GA4 also depends on advanced mode and on the property having enough traffic. Google sets those thresholds and doesn't guarantee modelling will switch on.
Summary.
A working Consent Mode v2 setup sets all four signals to a denied default before any Google tag fires, then updates them on accept, reject and withdrawal. Check it in Tag Assistant, confirm it on the wire with gcs and gcd, and prove it with cookies. Then confirm Google Ads and GA4 are receiving it.
If you need it built or fixed, see Consent Mode v2 implementation. If you'd rather have your wider tracking checked, the GA4 mini audit covers consent alongside the rest of your GA4 setup.