Google Tag Manager Cookies: consent and compliance

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

‍

If you’ve already implemented Google Tag Manager, the question of cookies quickly becomes central when it comes to privacy, cookie banners and compliance in the UK and across Europe. This article focuses specifically on how to control cookies actually set by tags, and how to make consent actionable within the container, without repeating the basics already covered in the main article.

‍

What this article explores beyond Google Tag Manager

‍

The main article sets the scene: GTM orchestrates tags via triggers and variables. Here, we go further on four practical topics that frequently cause non-compliance and loss of data:

• the distinction between “GTM does not set cookies” and “tags triggered by GTM do” (and why this changes your responsibility);
• the chain CMP → consent state → tag firing (timing, load order, events);
• Google Consent Mode and its evolution (Consent Mode v2) in GTM, to adapt Google tag behaviour based on consent;
• the method for auditing and linking each cookie to a tag, then keeping your cookie policy up to date as your tagging plan evolves.

‍

How does Google Tag Manager work?

‍

GTM works on an “events → conditions → tags” logic. For cookie management, it’s not just when a tag fires, but in what consent state it fires. Compliance depends on your ability to:

• receive a reliable consent signal (variable, consent cookie, data layer event);
• block non-essential tags by default;
• only allow execution after explicit and traceable action (opt-in).

‍

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

‍

Multiple specialist sources confirm: GTM does not “place” cookies itself, it triggers tags (analytics, advertising, A/B testing, video, chat, social plugins, etc.), and these services set or read cookies and collect data. The real issue for cookies managed via GTM is therefore tag governance: what runs, in what order, under what consent conditions and with which cookie parameters.

In practice: if a cookie appears in your browser, the right question is not “what cookie did GTM set”, but “which tag triggered by the container wrote or read this cookie”.

‍

Does Google Tag Manager use cookies?

‍

As a tag management tool, GTM does not require its own tracking cookie. However, as soon as your container triggers a tag that sets a cookie (for example analytics cookies like _ga or marketing cookies), your GTM implementation becomes a control point for cookie placement: you must be able to prove those tags don’t fire before consent when required.

‍

Does Google Tag Manager use cookies?

‍

No, not by itself. GTM is a tag orchestration layer. Cookies are typically set by the tags you fire (analytics, ads, video embeds, social pixels, etc.). Your compliance work therefore focuses on (1) blocking non-essential tags by default and (2) firing them only after a valid consent signal is available.

‍

Deployment and security: from container to CSP constraints

‍

How do I set up Google Tag Manager?

‍

“Consent-oriented” configuration happens at three levels:

• implementation (the right container in the right place, loaded early enough to control tags);
• trigger conditions (robust events, stable variables, especially consent conditions);
• governance (audit, versioning, systematic testing before publication, documentation).

If you’re still at the technical setup stage, follow a guide to install GTM correctly to avoid duplicates (hardcoded tags plus tags in GTM), a common cause of unintended cookie placement.

‍

Scripts, installation and versions: impact on cookies and tag firing

‍

Cookie management is directly linked to the load order:

• if a non-essential tag can fire immediately on Page View without a consent condition, you risk placement before opt-in;
• if your CMP loads too late, it “records” placement instead of preventing it;
• if you publish without pre-production, you lose the ability to explain behaviour changes (e.g. a new marketing cookie appears after adding a tag).

Key point: the script GTM presence alone does not mean compliance. It’s the published container versions (and active tags) that actually determine what runs on users’ devices.

‍

Strict CSP policy: tag loading, blocking and workarounds to avoid

‍

A strict CSP reduces injection risks and restricts uncontrolled loads, but it can break consent scenarios if you use too many custom HTML tags or “work around” blocks by adding overly broad exceptions. For compliance, avoid:

• workarounds that allow third-party scripts without consent checks (you lose “prior consent” status);
• overly permissive whitelists that reintroduce attack surfaces;
• undocumented CSP changes that make audits impossible (you can’t tell if a tag isn’t firing because it’s blocked or correctly conditioned).

‍

Cookie banner, CMP and tag governance

‍

Cookie banner: what GTM does (and doesn’t do) with a CMP

‍

A CMP (via a cookie banner) handles the user interface, records the choice and provides proof of consent. GTM makes this choice operational: firing (or not) tags according to accepted categories (statistics, marketing, preferences, etc.).

Common implementations rely on events and variables pushed to the data layer to inform GTM of consent status. For example, a documented CMP integration might push a key like OneTrustActiveGroups (comma-separated list of active categories) and an event OneTrustGroupsUpdated when preferences update, allowing dynamic tag activation without a page reload.

‍

Consent management: states, timing, load order and proof

‍

Non-compliance often comes from timing:

• consent state unavailable at first display (so tags fire “by default”);
• consent update event never triggered (or wrongly named);
• data layer variables overwritten, preventing GTM from reading the correct state.

Key takeaway: if a CMP pushes information to dataLayer, ensure you don’t overwrite the existing dataLayer. Data layer guides recommend defensive initialisation like window.dataLayer = window.dataLayer || [];, then dataLayer.push() calls to avoid losing event and state history.

For proof, operational requirements include: clear and unambiguous consent, ability to consent and withdraw for each category, and capacity to securely document consent. Recommendations also mention annual consent renewal, with some contexts requiring more frequent updates.

‍

Cookie policy: keeping your cookie policy updated as your tagging evolves

‍

The classic risk: your cookie policy describes a “theoretical” state, while the GTM container deploys a “real” state that changes with each version. To keep your cookie policy up to date:

• link each cookie to a tag and purpose (statistics, marketing, preferences, necessary);
• note the trigger moment (page view, click, e-commerce event, etc.) and consent condition;
• track changes for each GTM publication (which tags were added, changed, removed).

‍

Controlling tags based on consent: blocking, conditioning and disabling

‍

How do I block tags before user consent in Google Tag Manager?

‍

“Prior consent” means only strictly necessary trackers may run on arrival. In GTM, you have two (often combined) strategies:

• blocking by trigger: never use an “All Pages” trigger on non-essential tags; instead, use triggers conditioned on an “accepted” state;
• control via CMP events: fire tags on a specific consent update event (like OneTrustGroupsUpdated), with a condition on active categories.

Practical example (data layer logic): a GTM variable of “data layer variable” type reads OneTrustActiveGroups, then a “Custom Event” trigger on OneTrustGroupsUpdated only activates an analytics tag if the relevant category is present. A source illustrates RegEx control by category, for instance a C0002 category for performance/statistics.

‍

How do you condition tag firing on user consent?

‍

The most robust method is to make consent a limiting factor for your triggers:

• if a tag already has a business trigger (e.g. purchase), use a trigger group (AND logic): business event and “statistics” consent;
• avoid stacking triggers directly on a tag if you want AND logic (in GTM, multiple triggers on a tag act as OR);
• if using exceptions (blocking), ensure they evaluate on the same event as the activation trigger, or they won’t block as intended.

Depending on CMP integrations, it’s also possible to read an internal consent cookie (e.g. OptanonConsent) via a GTM “internal cookie” variable, then activate a tag if the value contains a marker like C0002:1. This approach can help on the first load if the update event hasn’t yet fired, but strict validation (format, encoding, timing) is needed.

‍

GDPR and cookie consent: handling refusal, partial consent and acceptance without excessive data collection

‍

Three cases must be covered unambiguously:

• refusal: no non-essential tags fire (including remarketing, social pixels, unnecessary A/B tests);
• partial consent: only accepted categories trigger their tags (e.g. statistics yes, marketing no);
• acceptance: controlled firing, without “catch-up” sending of illegitimate events.

Guidelines cited by specialist sources stress: no pre-ticked boxes, scrolling does not equal consent, and “cookie walls” are not valid consent. Technically, your container must reflect these principles: no non-essential tags active by default, and no ambiguity regarding the category required for firing.

‍

Disabling certain cookies without breaking essential cookie measurement

‍

In a real tagging plan, “disabling cookies” usually means:

• disabling the tag that writes them;
• or changing its configuration (e.g. domain scope, prefix, duration);
• or limiting firing to pages/scenarios with legitimate purpose.

Mind the side effects: Google’s documentation on cookie customisation (Google tag and GTM) notes that changing a cookie prefix can make existing visitors appear as new, as previous cookie context is no longer recognised.

‍

Measuring without cookies: what’s possible and what you should avoid collecting

‍

Without cookies, you can still measure aggregate or contextual signals, but you lose some user continuity (repeat sessions, multi-visit attribution, certain remarketing scenarios). Sources on Google’s consent mode indicate that when users don’t consent, tags may behave differently and rely on basic signals (e.g. timestamp, user-agent, referrer) for modelling/aggregation, with structural limits: you don’t get the same granularity as when storage is allowed.

For compliance, it’s better to relinquish non-essential marketing data than try to “rebuild” equivalent tracking at the expense of excessive collection.

‍

Quality control: pre-production, debugging and testing tag triggers

‍

Quality control must validate consent scenarios, not just pages:

• arrival with refusal: check no non-essential tags fire;
• arrival with statistics acceptance only: check analytics tags fire, but not marketing;
• preference update without reload: check CMP event correctly triggers (or stops) tags.

To go further in practice, you can test your GTM triggers using a dedicated methodology.

Additionally, always check analytics tool volumes after publication: discrepancies are often due to consent, but may also reveal overly broad firing or duplicates.

‍

Inventory and classification: building a traceable cookie list

‍

Building a reliable cookie list: pages, scenarios and variations based on consent

‍

A useful “cookie list” is not a single snapshot. It must cover:

• multiple pages (landing, forms, checkout, video embeds, plugin pages);
• multiple scenarios (before consent, after partial acceptance, after full acceptance);
• multiple browsers (especially those with strong third-party cookie restrictions).

Examples published by consent providers show how volumes vary by category. One declaration cited counts by category: necessary (51), preferences (16), statistics (30), marketing (87). Even without using these figures for your site, note: without scenario-based inventory, you almost always underestimate the reality.

‍

Essential cookie: distinguishing necessary, audience measurement and marketing

‍

A source summarises the ePrivacy principle: you may only store cookies on the device if strictly necessary for site operation, and need permission for other types. Operationally, this requires classification:

• necessary: security, load balancing, consent choice, vital functions;
• statistics: audience measurement (often conditioned by consent);
• marketing: advertising, retargeting, third-party pixels;
• preferences: language, currency, non-essential personalisation.

‍

First-party vs third-party cookies: responsibility, scope and compliance risks

‍

Two distinctions matter:

• who sets: your domain (first-party cookie) or a third-party domain;
• who uses: your organisation only, or a partner/provider (often with data transfer).

Browser privacy pressure reduces reliability of third-party cookies, encouraging more streamlined and governed measurement architectures. This does not replace consent: it urges you to clarify what truly needs measuring, with which tags, and to limit unnecessary dependencies.

‍

Linking each cookie to a tag: variables, triggers and actionable documentation

‍

Google’s documentation on cookie parameters highlights practical levers: cookie domain (cookie_domain), prefix (cookie_prefix), expiration (cookie_expires), update (cookie_update). To link a cookie to a tag, document:

• the GTM tag (exact name, type, provider);
• the trigger (event, pages, filters);
• the consent condition (category, consent mode);
• any modified cookie parameters (if customised).

‍

Consent Mode and Consent Mode v2: implementation in GTM

‍

Consent Mode: parameters, dependencies and execution order in Google Tag Manager

‍

Google’s consent mode adapts Google tag behaviour (analytics or advertising) according to consent state. A typical chain works as follows:

• CMP collects user choice;
• it exposes consent state;
• GTM applies this state to tags, controlling storage and collection.

Non-negotiable point: default state must be set before any non-essential tags execute, then updated immediately after user choice.

‍

Consent Mode v2: configuration, integration and validation for Google tags

‍

Available sources indicate consent mode is designed to make Google Tag Manager, gtag, Google Analytics and Google Ads work according to consent state, permitting more aggregated measurement when cookies aren’t allowed. The provided extracts don’t detail the specific Consent Mode v2 parameters. In practice, GTM implementation should be validated on two axes:

• functionality: Google tags respect state (no storage when refused);
• triggering: triggers remain consistent (no marketing events sent if marketing refused).

For validation, test by consent scenario in preview mode and also verify analytics impacts on event volumes and quality.

‍

Signals sent and tag behaviours: consent, modelling and limits

‍

One source describes that, without consent, basic signals (e.g. timestamp, user-agent, referrer) may feed aggregation/modelling. This helps limit some measurement loss, but is not equivalent tracking:

• you lose attribution precision and user journey continuity;
• cookie reading/writing remains consent-bound;
• results become more sensitive to opt-in rate variations.

‍

Default consent and update after user choice: common pitfalls

‍

Recurring pitfalls:

• “implicit” consent (e.g. continued navigation) when a clear action is required;
• “accepted” default on load, then correction after banner display (too late);
• consent update not reaching GTM (wrong event, poorly read data layer variable, overwritten data layer).

‍

Naming, reading and attributes: cookie name, reading and secure cookies

‍

Cookie name: naming conventions, collisions and container auditing

‍

If you customise names (prefixes), do so methodically. Google warns that changing prefix after a first visit can make existing visitors appear new. For auditing:

• standardise tag naming conventions (to trace from cookie to tag);
• avoid two tags writing similar cookies (collision risk and misinterpretation);
• document every cookie parameter change on publication.

‍

Reading a cookie via GTM variables: reliability and avoiding false positives

‍

Reading a cookie in GTM serves two purposes: checking a state (consent) or enriching an event. For reliability:

• ensure the cookie is set when the trigger evaluates (else you get empty values);
• if the cookie is encoded, enable URI decoding in the cookie variable (as recommended for some consent cookies);
• prefer, when possible, an explicit data layer signal over cookie reading (more testable, less ambiguous).

‍

Cookie domain and subdomains: scope, cross-domain and configuration impact

‍

Google’s documentation notes Google tags use automatic cookie domain configuration: they set the cookie at the highest possible domain level (e.g. example.com for blog.example.com), facilitating measurement across subdomains. It also notes a cookie domain must be an ancestor of the current domain, or the cookie won’t be set and no data sent.

Before “fixing” cookie scope, check the root cause: it’s sometimes a trigger (consent) issue, not a domain problem.

‍

Cookie flags: SameSite, HttpOnly and secure cookies to reduce security and privacy risks

‍

Security attributes (e.g. Secure, HttpOnly, SameSite settings) reduce technical risks but do not replace consent. Two useful rules:

• don’t “harden” a cookie without checking impact on user journeys (payment, cross-domain, subdomains);
• don’t compensate for consent issues by changing cookie settings: control must stay at trigger and consent state level.

‍

Compliance in the UK and Europe: privacy, GDPR and proof

‍

Valid consent: granularity, proof, withdrawal, retention and traceability

‍

Commonly cited operational requirements: clear and unambiguous consent, information on types of cookies/trackers, consent and withdrawal by category, and capacity to securely document consent. Other recommendations indicate annual renewal, with some contexts needing more frequent updates.

In practice, compliance is not just about the banner: it’s about your GTM container, proving non-essential tags do not fire before opt-in. For specific measurement implications, refer also to best practices in GDPR Google Analytics.

‍

Continuous audit: what to document for tags, cookies and consent

‍

A useful audit combines three layers:

• tags: inventory of active tags, purpose, recipient, trigger;
• cookies/trackers: name, duration, type (http cookie, local storage, etc.), placement conditions;
• consent: categories, default state, update event, proof and retention period.

Note: some sources explicitly list trackers beyond cookies (HTML5 local storage, pixels, IndexedDB, etc.). Even if your cookie policy only mentions “cookies”, your audit should cover other storage if tags use them.

‍

Measurement focus: links between GTM, audience and analytics compliance

‍

Compliance changes your numbers: refusal of consent ⇒ reduction in sessions and measured events. The main article already covers possible discrepancies between tools. Here, the key is to make discrepancies interpretable:

• segment analyses by GTM version periods;
• track opt-in rate evolution and link to traffic/conversion trends;
• document trigger changes (e.g. “GA4 switches from All Pages to a conditioned trigger”).

‍

Deep dive into cookies in analytics: what depends on tags, not GTM

‍

To avoid confusion, always separate:

• cookies set by analytics implementation (e.g. typical cookies like _ga, often with 2-year duration in declarations);
• analytics tag execution conditions (consent, triggers, exclusions);
• cookie parameters (domain, prefix, expiration) possibly customised via GTM.

‍

Interactions with Google Analytics: consistency, duplicates and data layer

‍

Clarifying roles: Google Tag Manager vs Google Analytics

‍

To correctly address the cookie question, remember role separation: GTM triggers, Analytics measures and reports. An analytics cookie becomes a “GTM cookie” only because an analytics tag is deployed via the container. For a concise comparison, see GTM vs GA.

‍

Deploying GA via GTM with consent dependencies: Google Tag Manager and Google Analytics

‍

The critical point for consent: avoid firing the analytics configuration tag on arrival if the “statistics” category isn’t accepted. If you have e-commerce events pushed to the data layer, condition their analytics send on consent, ideally via a trigger group combining “business event” and “statistics consent”. A step-by-step is available at GTM and GA.

‍

Making consent actionable: data layer conventions and governance

‍

The data layer remains the most robust way to standardise:

• events (e.g. purchase, lead generation, sign-up);
• parameters (value, currency, form type);
• and consent state (active categories, update event).

For governance, stability is paramount: a case-sensitive event or variable name changed without coordination can disable consent control (and let tags fire “by default”).

‍

GEO perspective: impact on visibility in generative AI answers

‍

Signal loss: effects on acquisition, conversions and SEO/GEO attribution

‍

When you correctly block non-essential tags, you accept some signal loss. This affects conversion attribution to SEO and, more broadly, your capacity to link a page to business outcomes. Visibility trends are changing: some sources in Incremys resources note that 60% of searches result in zero clicks, which reinforces the value of clean, interpretable measurement over “maximalist” data collection.

‍

Reliable decision-making despite consent: trends, segmentation and comparison with Search Console

‍

To steer SEO and GEO despite consent:

• treat opt-in rate as an explanatory variable (not noise);
• compare Search Console (clicks, impressions) to Analytics (sessions, conversions) considering refusals;
• analyse by container version: a trigger change can cause a bigger break in series than an audience shift.

‍

Quantitative benchmarks: SEO statistics, SEA statistics and GEO statistics for business impact context

‍

To frame the business impact of a consent strategy (and avoid misinterpreting false drops), rely on benchmarks and market trends. Incremys resources gather useful data, for example on zero-click share, CTR by position, and the evolution of multi-source journeys, which help contextualise measurement variations.

‍

A word about Incremys

‍

Connecting cookie compliance, SEO/GEO performance and editorial ROI through a unified vision (Search Console and Google Analytics via API)

‍

Proper tag and consent governance improves the reliability of SEO/GEO analysis: you know why a volume drops (refusal, trigger change, GTM version) and avoid wrongly concluding a loss of performance. Incremys follows this unified analysis logic, integrating Search Console and Google Analytics via API, to link visibility, traffic and outcomes, while factoring in consent constraints.

‍

FAQ: cookies, consent and compliance in GTM

‍

Does Google Tag Manager use cookies?

‍

No, GTM does not set tracking cookies “by itself”. Cookies come from the tags you trigger via the container (analytics, advertising, third-party pixels, video embeds, etc.).

‍

Does Google Tag Manager use cookies?

‍

No, not by itself. GTM is a tag orchestration layer: cookies are generally set by the tags you trigger (analytics, advertising, video embeds, social pixels, etc.). Compliance thus relies on your configuration: block non-essential tags by default and only fire them after a valid consent signal.

‍

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

‍

To determine this, you need to cross-reference (1) the inventory of active GTM tags, (2) triggers (page view, event, click, etc.) and (3) consent scenarios (refusal, partial acceptance, full acceptance). A reliable list is built by testing multiple pages and user journeys.

‍

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

‍

No. If non-essential tags fire on load, the banner doesn’t prevent placement, it only informs after the fact. The container must block by default and only activate after opt-in, by category.

‍

Cookie policy: how do you keep it updated when tags change frequently?

‍

Link every cookie to a tag and container version, document purpose, duration, trigger and consent condition, then update the policy for every publication that adds/changes a tag.

‍

GDPR and cookie consent: what proof should you keep to demonstrate compliance?

‍

Keep proof of choice (timestamp, accepted/refused categories, policy version), the ability to withdraw, and a history of GTM versions showing non-essential tags don’t fire before consent.

‍

Can you disable a cookie without breaking key measurement indicators?

‍

Sometimes yes, if you disable a non-essential tag or reduce its scope. But changing parameters like cookie prefix can disrupt visitor continuity and break time series. Test and document before publishing.

‍

What can you measure without cookies and with what limits?

‍

You can still work with aggregate and contextual signals, but lose much of multi-visit tracking and certain attribution/remarketing capabilities. Consent mode can mitigate some loss, but not restore equivalent granularity.

‍

First-party cookie: how can you reduce reliance on third-party cookies?

‍

Start by removing unnecessary tags, favour an event taxonomy based on the data layer, and limit marketing tags to those with a clear business objective and properly managed legal basis via consent.

‍

Cookie domain and cookie flags: which settings avoid the most common errors?

‍

Avoid setting a cookie domain that isn’t an ancestor of the current domain (otherwise the cookie won’t be set and you lose data). Only change security attributes (SameSite, Secure, HttpOnly) after validation across your cross-domain and subdomain journeys.

‍

Cookie naming and reading: how do you audit, read and ensure reliability in GTM?

‍

Standardise tag naming, document modified cookie parameters (domain, prefix, expiration), and prefer a data layer signal for consent. If you must read a consent cookie, use a cookie variable with URI decoding if needed, then test timing of reading.

‍

Where to deepen SEO, GEO and digital marketing: Incremys blog

‍