Google Tag Manager cookies: consent, CMP and compliance

Do you manage a site’s measurement with Google Tag Manager and need to prove that your tags respect each visitor’s choice? This page covers cookies in Google Tag Manager from the point of view of whoever owns measurement: who sets what, how the CMP controls tag firing, and how to configure Consent Mode v2.

It helps you decide three things: the inventory to maintain, the consent mode to choose (basic or advanced) and the scenarios to test before each publication.

Cookies in Google Tag Manager: managing privacy, consent and compliance

For cookies, it’s not just when a tag fires, but in what consent state it fires. The container becomes the control point for cookie placement: this is where you prove that no non-essential tag fires before the visitor agrees.

Why GTM does not set cookies, but each tag may do

GTM does not set any cookie itself: the tags it fires are what write or read cookies. When you find an unknown cookie, the right question is therefore: “which tag in the container wrote it?”.

The following table is the basis for your inventory, tag by tag:

Inventory and classification: building a traceable cookie list

Your cookie policy describes a theoretical state; the container deploys a real state that changes with each version. The inventory reconciles the two.

Building a reliable cookie list: pages, scenarios and browsers

A useful cookie list is not a single snapshot. It covers:

• multiple pages: landing page, form, checkout, pages with video embeds or plugins;
• multiple scenarios: before any choice, after partial acceptance, after full acceptance;
• multiple browsers, especially those with strong third-party cookie restrictions;
• the other trackers tags use: local storage, pixels, IndexedDB.

Without a scenario-based inventory, you almost always underestimate the real number of trackers. Also note who sets the cookie (your domain or a third party) and who uses it.

Classifying each cookie and linking it to a tag

European law only allows cookies strictly necessary for site operation without consent. Everything else is classified by purpose:

• necessary: security, load balancing, storing the consent choice;
• statistics: audience measurement;
• marketing: advertising, remarketing, third-party pixels;
• preferences: language, currency, non-essential personalisation.

For each cookie, document the tag that writes it, its trigger, its consent condition and any customised parameters. For each publication, log the tags added, changed or removed: this log keeps your cookie policy up to date.

Cookie banner, CMP and tag governance

The CMP displays the banner, records the choice and keeps proof of it. GTM makes this choice operational: the CMP exposes a consent state, then GTM fires or blocks each tag according to the accepted categories.

Your CMP pushes an event to the data layer each time the choice is updated, along with the list of active categories. A data layer variable reads this list; a “Custom Event” trigger on the CMP event activates tags without a page reload. Reading the CMP cookie remains a last resort, with URI decoding.

States, timing and load order

Most non-compliance comes from timing, not from tag configuration:

• the consent state is unavailable at first display, so tags fire by default;
• the CMP loads too late: it records placement instead of preventing it;
• the update event is never pushed, or has a different name from the one in the trigger;
• the dataLayer is overwritten, and GTM no longer reads the correct state.

To avoid the last pitfall, initialise with window.dataLayer = window.dataLayer || [] and then only use dataLayer.push() calls, as set out in the data layer data contract. Event names are case-sensitive: changed without coordination, one disables the control.

Controlling tags based on consent: blocking, conditioning and disabling

On arrival, only strictly necessary trackers run. In GTM, this principle translates into conditioned triggers and a few cookie settings.

Blocking before consent and conditioning tag firing

No non-essential tag should keep an unconditioned “All Pages” trigger. To make consent a limiting factor:

• replace the arrival trigger with a trigger conditioned on the accepted category;
• for a tag that already has a business trigger (purchase, lead), create a trigger group: business event AND “statistics” consent;
• don’t stack several triggers on a tag to get AND logic: in GTM, they act as OR;
• evaluate an exception trigger on the same event as the activation trigger, or it blocks nothing.

Name these triggers according to the container’s tag and script naming convention, so you can trace a cookie back to its tag at a glance.

Disabling or adjusting a cookie: domain, prefix and duration

Disabling a cookie means disabling the tag that writes it, restricting its firing or changing its configuration: cookie_domain, cookie_prefix, cookie_expires, cookie_update. Three side effects are worth knowing:

• changing the prefix after a first visit makes existing visitors appear as new;
• a cookie domain that isn’t an ancestor of the current domain prevents the cookie from being written, and no data is sent;
• hardening the Secure, HttpOnly or SameSite attributes can break a payment or cross-domain journey.

By default, Google tags set the cookie at the highest possible domain level (example.com for blog.example.com). No attribute setting replaces consent.

Consent Mode and Consent Mode v2: implementation in GTM

Consent Mode v2 adapts the behaviour of Google tags (GA4, Google Ads) to the consent state. It does not collect consent: it passes your CMP’s result on to the tags.

What Consent Mode v2 has required since March 2024

Since March 2024, Consent Mode v2 has been mandatory for EEA sites that use Google’s advertising features. On top of the original storage signals, it adds two advertising signals. The following table summarises all four, at the time of writing:

A banner can allow measurement and refuse marketing: in that case, separate analytics_storage and ad_storage instead of switching everything together. The two advertising signals require a CMP granular enough not to reduce everything to a single button.

Default state, then update: configuring through the CMP template

Consent Mode relies on two commands: a default state, usually denied, set before any tag, then an update state sent as soon as the visitor has chosen. If the order is reversed, tags fire before the state is known. In GTM, configure it through your CMP’s template from the Community Template Gallery rather than hand-written gtag commands:

• fire the template on “Consent Initialization”, before any other trigger;
• set wait_for_update to give the CMP time to read a choice already stored;
• use region to apply a denied default state to EEA visitors;
• enable url_passthrough if you want to keep click information in the URL when cookies are refused;
• declare the signals each tag requires in its consent settings.

On a SPA, check that the state doesn’t fall back to the denied default on every route change. With URL passthrough, watch out for redirects, which can lose the parameters.

Basic or advanced mode: the choice to make in France

The choice between the two modes is about what is sent to Google before and after a refusal, as this table shows:

The CNIL has not approved pings sent before consent: in France, basic mode is the cautious choice. Advanced mode requires sign-off from your DPO, and a CMP that does not already block Google tags.

In GA4, a refusal in basic mode means none of that visitor’s sessions are measured. In advanced mode, pings feed modelling above a volume threshold, without restoring multi-visit attribution.

Testing each consent scenario

Testing validates consent scenarios, not just pages. Do it at every version publication, then during the monthly check, using the GTM testing and debugging method.

The scenarios to run before publication

Run each scenario in Preview mode and record the result:

On acceptance, no catch-up: tags must not send events that occurred before the choice after the fact.

Reading the Consent tab and the gcs / gcd parameters

In Tag Assistant, GTM’s Preview mode, the “Consent” tab shows the default state, the update and the current state of all four signals for each event. Check three points:

• no advertising tag fires before the default state;
• tags that require ad_storage stay blocked as long as it is denied;
• requests sent to Google carry gcs and gcd parameters that match the choice.

After publication, compare volumes in GA4: a discrepancy is often due to consent, but it may also reveal overly broad firing or a duplicate tag.

Compliance: privacy, GDPR and proof

Compliance is demonstrated in the container, by proving that non-essential tags do not fire before consent. A few CNIL rules translate directly into configuration.

The CNIL rules that matter for configuration

The CNIL recommendations that affect your container are as follows:

• no pre-ticked boxes: consent requires a clear action;
• continued browsing or scrolling does not equal consent;
• a “cookie wall” is not valid consent;
• refusing must be as easy as accepting, and withdrawable at any time;
• the visitor’s choice is kept for 6 months, after which the banner is shown again;
• tracker lifetime is capped at 13 months.

The last point concerns cookie_expires: align the duration of measurement cookies with this cap. For settings specific to audience measurement, see the guide on Google Analytics GDPR compliance.

Continuous audit: what to document

A useful audit combines three layers, to update with each published version:

• tags: inventory of active tags, purpose, recipient, trigger;
• cookies and trackers: name, duration, storage type, placement condition;
• consent: categories, default state, update event, proof retention period.

Keep the published GTM versions with their descriptions and the Tag Assistant screenshots showing default then update; the CMP keeps the proof of choice.

Interactions with Google Analytics and Meta Pixel: reading measurement under consent

A measurement cookie becomes a “GTM cookie” only because a GA4 tag was deployed by the container: GTM fires, GA4 measures and reports, as detailed in the comparison of GTM and GA4 roles.

Making measurement discrepancies interpretable

Properly applied consent lowers measured sessions. Make this signal loss readable rather than trying to fill it:

• treat the consent rate as an explanatory variable, not noise;
• segment your analyses by container version: a firing change creates a break in series;
• compare Google Search Console clicks with GA4 sessions, taking refusals into account;
• document each change, for example “GA4 switches from All Pages to a conditioned trigger”.

It’s better to relinquish non-essential marketing data than to rebuild equivalent tracking at the expense of excessive collection.

Meta Pixel and consent

The Meta Pixel does not read Google’s Consent Mode: condition its base tag on the marketing consent exposed by your CMP, or pass the state with fbq('consent', …). The full setup is described in the guide to installing the Meta Pixel with GTM.

Depending on your situation

Depending on where you are, the next step is not the same:

• GTM is not yet in place: start by installing Google Tag Manager with the official snippet, then connect the CMP.
• GA4 needs to go through the container: follow the tutorial to deploy GA4 via GTM without duplicates, with a conditioned trigger from the outset.
• A CSP is blocking tags: adjust the directives with the CSP and Google Tag Manager guide rather than widening permissions without consent control.
• You are hesitating between basic and advanced: start with basic mode, document the choice and review it with your DPO.
• Volumes drop after a publication: run the six scenarios in the test table before concluding that audience has fallen.

To track the effect of consent on your organic traffic, the Incremys performance reporting module brings together Google Search Console and Google Analytics data via API: a drop in sessions can be read alongside clicks.

FAQ: cookies, consent and compliance in GTM

Does GTM set cookies?

No, Google Tag Manager does not set any cookie itself. Cookies come from the tags it fires: GA4, Google Ads, pixels, video embeds. Compliance depends on your configuration: block non-essential tags by default and only fire them after valid consent.

What is Consent Mode v2?

Consent Mode v2 passes the consent state to Google tags, which adapt cookie writing and data sending accordingly. It relies on four signals: analytics_storage, ad_storage, ad_user_data and ad_personalization. It has been mandatory since March 2024 for EEA sites using Google’s advertising features.

Basic or advanced mode?

In France, basic mode is the cautious choice, because the CNIL has not approved pings sent before consent. In basic mode, Google tags wait for interaction with the banner. In advanced mode, they load on page open and send cookieless pings, for richer modelling.

What happens in GA4 if the user refuses?

If the user refuses, GA4 writes no cookie. In basic mode, no data is sent. In advanced mode, cookieless pings feed modelling if the site’s volume reaches the threshold set by Google. In both cases, multi-visit tracking of that visitor is lost.

Do you need a CMP with GTM?

Yes, a CMP is needed as soon as the container fires non-essential tags. GTM does not collect consent: it applies the state the CMP passes to it, through the data layer or its Community Template Gallery template. The CMP displays the banner and keeps proof of the choice.

How do you test consent in GTM?

Test consent scenario by scenario in Tag Assistant, GTM’s Preview mode: arrival without a choice, refusal, partial acceptance, full acceptance, changed choice. In the “Consent” tab, check the default state then the update, and inspect the gcs and gcd parameters.

Which cookies are actually set, by which tag and at what time?

Only a cross-referenced inventory answers this question: active tags, triggers and consent scenarios. A reliable list is built by testing multiple pages, scenarios and browsers, then linking each cookie to the tag that writes it and to its purpose.

Cookie banner: is a banner enough if tags fire on load?

No, a banner is not enough if non-essential tags fire on load: it announces placement after the fact instead of preventing it. The container must block these tags by default and only activate them after the visitor’s choice, category by category.