Google Consent Mode (GCM): the practical basics

Google Consent Mode (GCM) is a mechanism that lets Google tags - GA4, Google Ads, Floodlight, and others - adjust their behaviour based on a user's consent choices. When a user declines tracking, GCM-aware tags do not simply stop firing; they fire differently, without writing or reading identifiers.

GCM does not automatically make a site compliant. It does not replace a Consent Management Platform (CMP). It is a set of signals that tags read and respond to - and those signals have to be set correctly, at the right moment, for GCM to do anything useful.

Basic mode vs Advanced mode

This is the distinction that matters most in practice.

Basic mode is the simpler implementation. Tags are blocked from loading until the user interacts with the consent banner. If the user declines, the tags never fire at all. You lose measurement for every non-consenting user - no data, no modelling.

Advanced mode is what most sites should be aiming for. Tags load on every page visit. Before any interaction, a default consent state is set (typically deny for ad and analytics storage). If the user declines, Google's tags fire in a restricted mode: they send a cookieless ping to Google's servers - no identifiers written, no identifiers read - but the hit is recorded. Google uses these pings, along with machine learning, to model conversions and behaviour that would otherwise be invisible.

The practical result is that Advanced mode significantly improves measurement accuracy for non-consenting users compared to blocking tags entirely. It is also what Google requires for features like enhanced conversions and consent-based modelling in GA4.

The four storage parameters

GCM works by setting and updating four consent parameters:

Parameter	Controls
ad_storage	Cookies and local storage used for advertising (e.g., Google Ads conversion cookies)
analytics_storage	Cookies and local storage used for analytics (e.g., _ga, _gid)
ad_user_data	Whether user data may be sent to Google for advertising purposes
ad_personalization	Whether data may be used for personalised advertising

A correct Advanced mode implementation sets all four to 'denied' before any user interaction, then updates them to 'granted' (for the appropriate categories) once the user consents.

// Set defaults before the banner loads
gtag('consent', 'default', {
  ad_storage: 'denied',
  analytics_storage: 'denied',
  ad_user_data: 'denied',
  ad_personalization: 'denied',
  wait_for_update: 500,
});

// Update after user consents (typically handled by your CMP)
gtag('consent', 'update', {
  ad_storage: 'granted',
  analytics_storage: 'granted',
  ad_user_data: 'granted',
  ad_personalization: 'granted',
});

In practice, the update call is triggered by your CMP when the user makes a choice - you rarely write this yourself.

Reading the gcs parameter

When a Google tag fires in consent-mode context, it appends a gcs parameter to its requests. This parameter encodes the current consent state as a short string:

gcs value	Meaning
G100	ad_storage granted, analytics_storage granted
G110	ad_storage denied, analytics_storage granted
G101	ad_storage granted, analytics_storage denied
G111	Both denied (cookieless ping)

If you open DevTools and inspect requests to google-analytics.com or googletagmanager.com, the gcs value tells you what GCM state was in effect when that request fired. G111 on first load, before any interaction, is the sign of a correctly configured Advanced mode implementation.

Common misconfigurations

Defaulting to granted. If the default state is 'granted' rather than 'denied', GCM is technically present but provides no practical protection. Tags behave exactly as they would without GCM. This is the most common error, and it can look compliant at a glance - the GCM API is there, the update call is there, but the default is wrong.

Basic mode only. Implementing Basic mode (blocking tags until consent) while calling it GCM is technically correct but misses the measurement benefits of Advanced. The tell is that no Google requests fire at all before consent interaction.

Late defaults. The consent default must be set before any Google tag loads. If the gtag('consent', 'default', ...) call comes after GTM or GA4 has initialised, the tags may fire without reading it. Timing matters.

Partial implementation. Setting analytics_storage but forgetting ad_storage (or vice versa) means Google Ads tags may still write cookies even when analytics is restricted. All four parameters should be set.

Where ConsentScout fits

ConsentScout's first-load scan checks whether non-required cookies appear before any user interaction. For GCM, this means:

• GA4/Google Ads cookies on first load (_ga, _gid, _gcl_au) strongly suggest GCM is either absent or misconfigured with a granted default.
• No cookies but Google requests present is consistent with Advanced mode operating correctly - cookieless pings rather than cookie-setting requests.
• No Google requests at all before consent is consistent with Basic mode.

The scanner also checks for GCM detection signals in page source and tag behaviour. A site passing the ConsentScout check for GCM Advanced has demonstrated that no identifiers are set on first load and that GCM signals are present - but a full audit should still verify the gcs parameter in network requests and confirm the wait_for_update timing is appropriate for your CMP.