How to actually verify Google Consent Mode is working

The fastest way to verify Consent Mode is working is to look at the gcs parameter on any Google request in your browser's network panel: G100 means storage denied, G111 means granted. Everything else — banner behaviour, cookie state, region logic — follows from confirming that one value changes correctly when the user chooses. Most broken implementations fail one of two ways, and only one of them is visible in your reports.

The two failure modes

Tags fire before consent. The banner appears, the user has chosen nothing, and Google tags are already sending full hits with cookies. This is a compliance exposure, and it is invisible in reporting because the data looks complete. Nobody investigates a healthy number.

Consent updates never arrive. The default is denied, the user accepts, and nothing changes because the banner never calls the update. All EEA data disappears. This gets misdiagnosed as "European traffic doesn't convert" — sometimes for months.

Testing only one direction is how sites end up with one of these permanently. Test both, every time.

The five-minute verification

Use a fresh browser profile or incognito window, with extensions disabled, and ideally an EEA IP if your consent logic is region-specific.

Step 1: Before choosing anything

Open the network panel, filter for collect, and load the page.

• A request with gcs=G100 — Advanced Consent Mode is working. Tags loaded, in a restricted state, sending a cookieless ping.
• No request at all — either Basic Consent Mode (correct, if intended) or the tag is not loading (a different problem entirely).
• A request with gcs=G111 — tags are firing with full consent before the user chose. This is the compliance failure.

Also check Application → Cookies. Before consent there should be no _ga cookie and no advertising cookies.

Step 2: Accept

Click accept and watch for new requests.

• gcs should become G111 and cookies should now be set.
• If nothing changes, the banner is not calling the consent update. This is the silent data-loss failure.

Step 3: Reject, then navigate

Reject, then load a second page.

• The denied state must persist. If the second page shows granted, the choice is not being stored or restored, and every page view re-asks.

Step 4: Return as a repeat visitor

Close the tab, reopen the site.

• The stored choice should be restored before tags act on the default. If a returning acceptor briefly shows denied and then granted, your wait_for_update may be too short — or the restore is happening after the tag has already sent.

Reading the signals precisely

The gcs parameter encodes the two storage signals:

Value	Meaning
G100	ad_storage denied, analytics_storage denied
G110	ad_storage granted, analytics_storage denied
G101	ad_storage denied, analytics_storage granted
G111	Both granted

Note what gcs does not tell you: the state of ad_user_data and ad_personalization, the two signals Consent Mode v2 added. Those appear separately in the payload — look for the gcd parameter, and confirm your implementation is setting all four rather than only the original two. An implementation built before 2024 and never updated will look fine on gcs and still degrade EEA advertising.

Check the console too:

// What has been pushed to the dataLayer, including consent calls
window.dataLayer.filter(function (i) {
  return i[0] === 'consent';
})

Ordering: the cause of most failures

The default consent call must execute before any Google tag loads. Not in GTM, not after the container snippet, not in a tag that fires on page view — in the document head, above everything.

<script>
  window.dataLayer = window.dataLayer || [];
  function gtag(){dataLayer.push(arguments);}
  gtag('consent', 'default', {
    ad_storage: 'denied',
    analytics_storage: 'denied',
    ad_user_data: 'denied',
    ad_personalization: 'denied',
    wait_for_update: 500
  });
</script>

If this runs after the container, there is a window in which tags fire unrestricted. On a fast connection that window is small; it is not zero, and it is exactly what an auditor will find.

Platform-specific ordering constraints are the usual culprit — Consent Mode v2 on Shopify covers the most common case, where the platform, not you, decides when things load.

Platform-side verification

Browser checks confirm what leaves the page. Two platform checks confirm what arrives:

• GA4 reports consent state coverage in its admin diagnostics. Low or zero coverage means signals are not reaching Google.
• Google Ads warns when conversions lack v2 signals for EEA traffic. That warning is the most reliable signal that ad_user_data and ad_personalization are missing.

When the banner and the tags disagree

A pattern worth recognising: the consent platform records a choice, its own dashboard shows healthy accept rates, and Google's diagnostics still report missing signals. The banner is storing consent without translating it into Google's consent API.

This is common with platform-native banners and with consent tools configured for a different tag stack. The fix is a bridge — subscribing to the consent platform's change event and calling the Google consent update. Verify with the gcs value, not with the banner's own reporting.

FAQ

What does gcs=G100 mean?

Both ad_storage and analytics_storage are denied. Before a user chooses, that is the correct state for a compliant Advanced Consent Mode implementation.

Why do my tags fire before the user accepts?

The default consent call is running too late — after the container or tag has already loaded. It must be the first script in the head, above everything else.

Why did my EU data disappear after installing a consent banner?

Almost certainly because the denied default is set but the granted update never fires. Test the accept path explicitly and watch for gcs changing to G111.

How do I check ad_user_data and ad_personalization?

They are not encoded in gcs. Look at the gcd parameter in the request payload and confirm your implementation sets all four signals, not just the original two.

Does Consent Mode work if the user has an ad blocker?

If the Google tag itself is blocked, no request is made at all — consent state becomes moot. Consent Mode governs behaviour when the tag runs, not whether it is allowed to load.

For a fast outside check on any site, the free tracking audit reports whether Consent Mode v2 calls and a consent platform are present on the page.