How to Implement Cookie Consent With Google Tag Manager

Getting cookie consent right in Google Tag Manager requires balancing regulatory compliance with your measurement needs. Implementation errors typically fall into two categories: firing tags without proper consent (creating compliance risk), or blocking tags unnecessarily (losing measurement data even when collection would be permissible).

This guide walks through implementing Google Consent Mode v2 in Google Tag Manager using the Advanced Implementation approach. This approach allows Google’s tags to adapt their behavior based on user consent – maintaining full tracking for consented users while sending anonymized signals for unconsented users. These signals enable conversion modeling, which can recover some attribution data even when cookies are declined.

We’ll cover the complete technical setup: configuring your Consent Management Platform (Cookiebot in our examples), setting up Google Tag Manager triggers and tags, handling both Google and non-Google tags, debugging consent signals, and troubleshooting common issues.

Who This Guide Is For:

Marketing teams implementing or auditing GTM consent setups
Developers responsible for privacy-compliant tracking implementations
Analysts who need to understand how consent affects their data
Anyone upgrading from Consent Mode v1 to v2

What You’ll Need:

Access to Google Tag Manager (Editor or Publish permissions)
A Consent Management Platform account (examples use Cookiebot)
Basic familiarity with GTM concepts (tags, triggers, variables)

What This Guide Covers:

This guide focuses on Advanced Implementation with Google Consent Mode v2. If you’re evaluating whether to use Basic or Advanced implementation, need multi-CMP setup guidance, or require server-side tagging configuration, those topics are beyond this guide’s scope.

The regulatory landscape for digital data collection has evolved significantly over the past several years, requiring website owners to rethink how they implement tracking and analytics.

The Regulatory Timeline

The General Data Protection Regulation (GDPR) took effect in 2018, establishing opt-in consent requirements for non-essential cookies across the European Economic Area (EEA). Website owners initially responded with basic implementation approaches: if a user didn’t consent to cookies, tracking tags simply didn’t fire.

In 2024, the Digital Markets Act (DMA) introduced additional requirements for major platforms like Google. Beyond confirming that cookies were stored with permission, these platforms must now demonstrate that users explicitly consented to their personal data being used for advertising purposes and combined across platform services.

Google responded to these requirements by evolving their Consent Mode framework from v1 to v2. This technical framework allows Google’s advertising and analytics platforms to adjust their behavior based on what users consent to.

Consent Mode v1 (released 2020) focused primarily on storage permissions – whether tags could read or write cookies. This addressed GDPR’s cookie consent requirements.

Consent Mode v2 (required March 2024 for EEA traffic) added new signals specifically for the DMA:

ad_user_data: Consent for sending user data to Google for advertising
ad_personalization: Consent for personalized advertising/remarketing

Two Implementation Approaches

There are two ways to implement consent management in Google Tag Manager:

Basic Implementation blocks tags from loading until consent is granted. If a user doesn’t consent, no data flows to Google’s servers. This ensures strict compliance but results in complete data blindness for unconsented users – they effectively don’t exist in your analytics.

Advanced Implementation allows tags to load immediately but adapt their behavior based on consent status. When users grant consent, tags function normally with full tracking. When users deny consent, tags send ‘cookieless pings’ – anonymised data packets containing timestamp, page URL, and conversion value, but no persistent user identifiers. A temporary session ID is generated for each page load but is not stored in cookies.. This enables Google’s conversion modeling, which uses consented user data to estimate the behaviour of unconsented users.

The choice between these approaches typically depends on your legal team’s interpretation of applicable regulations and your organization’s risk tolerance.

Why This Matters for Your Implementation

Implementing either approach correctly requires precise coordination between three systems:

Your Consent Management Platform (CMP) – captures user choice
Google Tag Manager – controls when tags fire
Google’s platforms (GA4, Google Ads) – receive and process the data

Configuration errors can result in two problematic outcomes:

Compliance risk: Tags firing and tracking users who haven’t consented
Data loss: Tags blocked even when tracking would be permissible, losing measurement capabilities

This guide focuses on the Advanced Implementation approach for Google Tag Manager, as it maximizes data recovery while maintaining compliance. We’ll cover the specific GTM configuration, consent parameters, debugging techniques, and common issues you’ll need to address.

Before you start configuring tags and triggers, you need to understand how the consent signaling system actually works.

From Storage Control to Data Usage Signals

Consent Mode v2 expanded the consent signaling framework to distinguish between storage permissions and data usage permissions.

What Changed from v1 to v2

Consent Mode v1 provided two signals that controlled storage access:

ad_storage – Permission to read/write advertising cookies
analytics_storage – Permission to read/write analytics cookies

These signals told tags whether they could access the browser’s local storage, which addressed cookie consent requirements under the ePrivacy Directive.

Consent Mode v2 added two new signals that control data usage:

ad_user_data – Consent for sending user data to Google for advertising purposes
ad_personalization – Consent for personalized advertising (remarketing/retargeting)

The Storage vs Usage Distinction

The four parameters now work together to control two different aspects of tracking:

Storage signals control whether cookies can be written to and read from the browser:

If ad_storage is denied, Google Ads tags cannot set or read cookies like _gcl_au
If analytics_storage is denied, GA4 cannot set or read cookies like _ga

Usage signals control whether user data can be sent to Google and how it can be processed:

If ad_user_data is denied, user-identifiable information (hashed emails, phone numbers) cannot be sent to Google Ads
If ad_personalization is denied, the user cannot be added to remarketing audiences or personalized advertising campaigns

Why the Separation Matters

A user might consent to having an analytics cookie stored on their device (for measuring site performance) but not consent to having their browsing behavior used to target them with advertising across Google’s services.

While most Consent Management Platforms currently present these as unified choices to users (like a single “Marketing Cookies” toggle), your GTM implementation must send all four distinct signals to Google’s systems. Missing any of these signals can result in:

Loss of conversion modeling capabilities
Inability to build remarketing audiences
Enhanced Conversions not functioning
Warnings in Google Ads about missing consent implementation

The technical implementation in GTM must track and transmit all four consent states, even if your CMP groups them together in the user interface.

Consent Mode operates by maintaining a global “Consent State” in the browser. Consent state is preserved in a first-party cookie (typically named CookieConsent) for 12 months. On return visits, the CMP reads this cookie and immediately updates the Consent API before any tags fire.

When a Google tag fires, it doesn’t immediately execute its tracking logic. Instead, it first queries this global state to determine what it’s permitted to do.

This behaviour is governed by four core parameters:

Parameter Name	Introduced	Primary Function	Technical Impact	Critical Dependency
`ad_storage`	v1	Storage Access: Controls the enabling of storage (cookies, localStorage) related to advertising.	If Denied: Google Ads/Floodlight tags cannot read/write cookies (e.g., `_gcl_au`).	Conversion Modelling: Essential for basic conversion tracking.
`analytics_storage`	v1	Storage Access: Controls the enabling of storage related to analytics.	If Denied: GA4 cannot read/write first-party analytics cookies (e.g., `_ga`).	Behavioural Modelling: Determines if session continuity is maintained via cookies.
`ad_user_data`	v2	Data Usage: Sets consent for sending user data to Google for advertising purposes.	If Denied: User-identifiable data is not sent to Google Ads services.	Enhanced Conversions: Required for hashing and matching user data (email, phone) for conversion attribution.
`ad_personalization`	v2	Data Usage: Sets consent for personalised advertising (remarketing).	If Denied: User is excluded from remarketing lists and audience segments.	Audience Building: Required to populate Google Ads remarketing lists.

The v2 parameters, ad_user_data and ad_personalization, are the specific technical responses to the DMA. If these signals are not present or are set to “Denied,” Google Ads will continue to function for reporting aggregate counts, but the ability to retarget those users or use their data for uplift modelling is severed.

Basic Mode vs Advanced Mode: A Critical Decision

Consent Mode allows for two distinct implementation approaches. The choice between them is typically made by your legal team based on their interpretation of applicable regulations and your organization’s risk tolerance. The GTM configuration differs significantly between the two.

Basic Implementation

Basic Consent Mode prevents Google tags from loading or firing until users explicitly grant consent.

How it works: Google tags are blocked from executing until the consent signal changes to “Granted.”

GTM configuration: This requires “Blocking Triggers” or “Exception Triggers” in GTM. For example, a Google Ads Conversion tag would have a trigger of “All Pages” combined with an Exception of “Marketing Consent is NOT Granted.”

Data consequence: Users who don’t consent generate no tracking data. No cookies are set, and no network requests are sent to Google’s servers. Your analytics and advertising platforms will only reflect consented users. Conversion modeling is not available because Google receives no signals from unconsented traffic.

When this approach is appropriate:

Your legal team interprets regulations to require explicit consent before any data transmission
Your organization prioritizes strict compliance over data completeness
You’re operating in jurisdictions with restrictive interpretations of consent requirements
Your business can function effectively with measurement limited to consented users

Advanced Implementation

Advanced Consent Mode allows Google tags to load immediately but adapt their behavior based on consent status.

How it works: Google tags load on page load regardless of consent status, but they query the consent API before executing tracking logic.

Behavioral adaptation:

If Consent is Granted: The tag executes normally. It writes cookies (_ga, _gcl_au) and sends full payloads including user identifiers.
If Consent is Denied: The tag enters a restricted state. It doesn’t write or read cookies. Instead, it sends “cookieless pings” – ephemeral data packets containing non-identifying information such as timestamp, user agent, and conversion value. These pings are not stored on the user’s device.

Data consequence: Google receives anonymized signals from unconsented users, which enables conversion modeling. Google uses aggregate data from cookieless pings to estimate the behavior of unconsented users based on patterns observed in consented users. This provides partial visibility into unconsented traffic.

When this approach is appropriate:

Your legal team interprets regulations to permit anonymized data transmission
Your organization needs visibility into total conversion volume (consented + modeled)
You’re using Google’s advertising platforms and need conversion data for optimization
You can meet technical requirements (sufficient conversion volume for modeling)

Choosing Your Approach

The decision between Basic and Advanced implementation should be made by your legal team, not your marketing team. The technical capabilities of each approach are secondary to compliance requirements.

Factors your legal team should consider:

Applicable regulations (GDPR, ePrivacy Directive, DMA, local laws)
Regulatory guidance and enforcement precedents in your jurisdiction
Your organization’s interpretation of what constitutes “anonymous” data
Risk tolerance for regulatory scrutiny

This guide’s scope: This guide focuses primarily on implementing Advanced Mode because it requires more complex technical configuration. However, we’ll also cover handling non-Google tags, which must always use “Basic Mode” logic since they lack the adaptive capabilities of Google tags.

If your legal team chooses Basic Mode for Google tags, many sections of this guide will still apply (CMP setup, consent signals, debugging), but you’ll need to implement blocking triggers rather than relying on built-in consent checks.

Before You Start: Prerequisites and Setup

A successful implementation relies on a clean environment and precise configuration of your Consent Management Platform. Before modifying a single tag in GTM, you need to lay the architectural foundation.

Choosing and Configuring Your CMP

For this guide, we’ll use Cookiebot as the CMP example. Cookiebot operates by scanning your website to identify all cookies and trackers, then groups them into four primary categories:

Necessary: Essential for the site to function. Always active.
Preferences: Stores user choices (language, etc.).
Statistics: Analytics and measurement (maps to analytics_storage).
Marketing: Advertising and tracking (maps to ad_storage, ad_user_data, ad_personalization).

For Consent Mode to function, Cookiebot must be the “Source of Truth.” It captures the user’s choice and broadcasts this choice to the GTM container via the Consent API.

Getting Your Domain Group ID

The critical link between the Cookiebot cloud service and your GTM container is the Domain Group ID. This isn’t the script ID or the API key – it’s a specific GUID (Globally Unique Identifier) assigned to your domain group.

To find it:

Navigate to the Cookiebot Admin Interface
Go to Settings > “Your Scripts” tab
Locate the script source URL
The GUID is the alphanumeric string (format: 00000000-0000-0000-0000-000000000000) found within the data-cbid attribute or the script source path

You’ll need this ID for the GTM template configuration. It ensures that the banner displayed on your site matches the configuration and scanning results defined in the Cookiebot console.

The Clean Slate Principle

A common source of implementation failure is the “Hybrid State,” where parts of the implementation are hardcoded in your website’s HTML and parts are managed in GTM.

The conflict risk: If gtag.js is loaded directly in your source code AND via GTM, or if the Cookiebot script is hardcoded in the <head> while also being deployed via GTM, race conditions occur. The hardcoded script might set a default state that conflicts with the GTM default state, or tags might fire twice.

Best practice: If you’re deploying via GTM (which is recommended for granular control), remove all hardcoded instances of the Cookiebot script and the Google Global Site Tag (gtag.js) from your website source code. The GTM container should be the sole arbiter of tag injection.

Auditing and Classifying Your Tags

Before proceeding, audit your existing GTM container. You must classify every tag into one of two categories:

Google Tags (Consent Aware):

Google Analytics 4 (GA4) Configuration & Events
Google Ads Conversion Tracking
Google Ads Remarketing
Floodlight / DoubleClick
Conversion Linker

Strategy: These will be configured for Advanced Mode (always load, adapt behaviour).

Non-Google Tags (Consent Ignorant):

Meta (Facebook) Pixel
LinkedIn Insight Tag
TikTok Pixel
Microsoft (Bing) Ads
Hotjar / CrazyEgg

Strategy: These must be configured for Basic Mode (block until consent is verified).

This classification determines your entire implementation approach. Google tags have built-in consent awareness – they can adapt their behaviour based on consent signals. Non-Google tags are binary: if they fire, they track. There’s no middle ground.

Implementing the Cookiebot CMP in Google Tag Manager

The cornerstone of your implementation is the “Cookiebot CMP” tag template. This template abstracts the complex JavaScript required to interface with the Google Consent API.

Installing the Template

Within your GTM workspace, navigate to Templates > Tag Templates > Search Gallery
Search for Cookiebot CMP by Usercentrics
Ensure you’re selecting the official template to guarantee compatibility with v2 features
Add to Workspace

This makes the “Cookiebot CMP” tag type available when creating new tags.

Configuring the Cookiebot CMP Tag

Create a new tag using the Cookiebot CMP type. This tag will act as the “Controller” for consent across your entire site.

Core Identification

Cookiebot ID: Paste the Domain Group ID you retrieved earlier.

Language: Set to “Auto-detect” (Default). This ensures the banner language dynamically adjusts to the user’s browser settings, improving user experience and potentially consent rates.

Enable Google Consent Mode: This checkbox must be selected. It activates the API integration, allowing the Cookiebot script to push gtag('consent', 'update',...) commands to the Data Layer.

Without this enabled, your Google tags won’t receive consent signals and will operate blindly.

This section defines the baseline state of the browser before the user has made a choice. This is critical for compliance.

The “Denied” default principle: For GDPR and DMA compliance, the default state for all parameters must be “Denied.” This ensures that if a user lands on the page and does nothing (or abandons), no tracking occurs.

Configuration: In the template, you’ll see options for ad_storage, analytics_storage, ad_user_data, and ad_personalization. Set all to Denied.

Region-Specific Defaults (Advanced)

The template allows for sophisticated regional logic. You can define specific defaults for specific regions using ISO 3166-2 codes.

Example scenario: A global company operates in the US and EU.

EU Setup:

Add a row for EU countries (e.g., DE, FR, IT, ES)
Set all defaults to Denied

US Setup:

Add a row for US (or specific states like US-CA)
Set defaults to Granted (if operating under an opt-out model like CCPA/CPRA)

Fallback: If no region matches, the “Default” setting applies.

Why this matters: This allows you to maximise data collection in permissive regions where “Denied by Default” isn’t legally required, while strictly complying in the EEA.

Wait for Update

This setting (measured in milliseconds) instructs Google tags to pause their execution for a brief window to allow the CMP to load and provide the current consent status.

The race condition problem: Without this setting, a Google tag firing on “Initialization” might execute before the Cookiebot script has retrieved the user’s previous consent from the cookie. The tag would see the “Default” (Denied) state and send a cookieless ping, even if the user had actually consented.

Recommendation: Set to 500-1000ms for most sites. Increase to 2000ms only if you’re seeing race condition issues in testing (tags firing with denied status for returning consented users). If the update happens sooner, the tags fire immediately – they don’t wait the full duration set.

Redact Ads Data

What it does: When ad_storage is denied, this setting (ads_data_redaction) instructs Google tags to route ad click traffic through a cookieless domain (gstatic.com) rather than the standard doubleclick.net or google.com.

It also actively strips ad-click identifiers (like the GCLID) from outgoing network requests to prevent them from being stored in third-party cookies.

Recommendation: Set to True (or “Dynamic” which matches ad_storage status). This is a privacy-enhancing feature that reinforces the “Denied” state for advertising data.

Enable URL Passthrough

The problem it solves: When ad_storage is denied, the GCLID (Google Click Identifier) cannot be stored in a cookie. If the user navigates to a second page, the GCLID is lost, breaking attribution.

The solution: url_passthrough enables the tags to append the click identifier (and session ID) to the URL of internal links as query parameters (e.g., ?_gl=1*xyz...). This passes the identity state from page to page without touching the browser’s storage.

Recommendation: Set to True. This is vital for Advanced Mode. It ensures that even if a user denies cookies, their session and conversion can still be attributed (via modelling) because the click ID persists during the session.

Technical note: Ensure your web server is configured to ignore unknown query parameters. Some strict caching rules (like Varnish) might cache the page with the query parameter, serving a user-specific link to other users. Configure your caching layer to strip _gl before caching, or vary cache by query string.

Setting the Trigger

The placement of the Cookiebot CMP tag in the firing order is the single most critical factor in your setup.

Trigger: Consent Initialization - All Pages

Why this matters: GTM executes triggers in a specific sequence:

Consent Initialization: Reserved for CMPs
Initialization: Where GA4/Google Ads config tags should live
Container Loaded (Page View): Standard tags
DOM Ready: Tags needing page elements
Window Loaded: Late-loading tags

By placing the Cookiebot tag on the Consent Initialization trigger, you guarantee that the API defaults are set and the listener is active before any Google tag attempts to check for permission.

If you place the CMP tag on “All Pages” (Container Loaded), it will fire too late, causing all Google tags to fire with “Denied” status regardless of user choice.

Configuring Google Tags for Advanced Mode

With the CMP establishing the rules of engagement, the next phase involves configuring your Google tags to operate within this framework. In an Advanced Implementation, we don’t block these tags, we allow them to fire, relying on their internal logic to adapt.

Google’s primary tags (GA4 Configuration, GA4 Events, Google Ads Conversion Tracking, Conversion Linker, and Floodlight) possess “Built-in Consent Checks.” They’re hardcoded to check the gtag consent state before executing.

To verify this:

Open one of your Google tags (e.g., GA4 Configuration)
Navigate to Advanced Settings > Consent Settings
You’ll see a section listing “Built-in Consent Checks” – it will typically list ad_storage and analytics_storage

Critical instruction: Do NOT add “Additional Consent Checks.” Leave this setting as Not set.

If you manually add checks here, GTM changes its behaviour from “Adapt” to “Block.” If the check fails, the tag is suppressed entirely, reverting your implementation to Basic Mode.

Setting Firing Triggers for Google Tags

In Advanced Mode, you use standard firing triggers:

GA4 Configuration: Fire on Initialization - All Pages. This ensures it loads immediately after the Consent Initialization phase.

Google Ads Conversion: Fire on the standard conversion trigger (e.g., “Thank You Page View”).

Remarketing: Fire on Initialization - All Pages or specific audience pages.

Because these tags are “Consent Aware,” they will fire on these triggers regardless of the user’s choice.

What happens in practice:

Scenario A (User Accepts):

Tag fires
Consent API says “Granted”
Tag writes _ga cookie
Tag sends full hit with user identifiers

Scenario B (User Denies):

Tag fires
Consent API says “Denied”
Tag does NOT write _ga cookie
Tag generates a random, ephemeral ID
Tag sends a “ping” with gcs=G100 (denied status)
Google servers receive the ping, note the conversion, but don’t profile the user

This is the magic of Advanced Mode, the tag always fires, but its behaviour adapts based on consent.

Handling Non-Google Tags (Basic Mode Logic)

Third-party tags like the Meta (Facebook) Pixel, LinkedIn Insight Tag, and TikTok Pixel don’t have built-in consent logic. They’re binary: if they fire, they track. If they track without consent, you’re non-compliant.

Therefore, these tags must be implemented using “Basic Mode” logic, blocking them until consent is positive.

The “Update” Event Logic

You cannot simply fire a Facebook Pixel on “All Pages.” Here’s why:

On the first page load, the default consent is “Denied.” If the Pixel fires on “All Pages,” it executes immediately, illegally dropping cookies.

Conversely, if you block it, and the user clicks “Accept” 10 seconds later, the Pixel won’t fire because the “All Pages” trigger has already passed.

The solution: We need a trigger that listens for the change in consent.

Cookiebot pushes a Data Layer event whenever the consent status is resolved (either by reading a cookie on load or by user interaction). This event is typically named cookie_consent_update.

Create the trigger:

Trigger Type: Custom Event
Event Name: cookie_consent_update
Trigger Name: “Event – Cookie Consent Update”

Refining the logic: This trigger fires whenever any consent is updated. We need to be specific.

For a Facebook Pixel (which requires Marketing consent), we should only fire if Marketing is granted.

Cookiebot typically pushes variables into the Data Layer, such as cookiebot_consent_marketing (True/False).

Updated trigger configuration:

Event Name: cookie_consent_update
Firing Condition: cookiebot_consent_marketing equals true

Implementing Third-Party Tags

There are two strategies for applying this trigger.

Strategy A: Replacement (Recommended)

Replace the standard “All Pages” trigger with the “Cookie Consent Update” trigger.

How it works:

The cookie_consent_update event fires on every page load (when Cookiebot reads the existing cookie) AND when the user interacts with the banner.

Results:

New user: Lands. Pixel waits. User accepts. cookie_consent_update fires. Pixel fires. (Compliant)

Returning user: Lands. Cookiebot reads cookie. cookie_consent_update fires immediately. Pixel fires. (Compliant)

Benefit: It covers both the initial interaction and subsequent page views with a single trigger.

Strategy B: Trigger Groups (Complex)

Some implementers use a Trigger Group combining “All Pages” AND “Consent Granted.” This is often unnecessary with Cookiebot’s architecture and introduces complexity regarding trigger firing counts.

We recommend Strategy A for simplicity and reliability.

Handling Advanced Matching and PII

For tags like Meta Pixel that use “Advanced Matching” (sending hashed email/phone), ensure that you’re only populating these variables when marketing consent is granted.

Even if the tag fires, sending hashed PII without consent (specifically the ad_user_data equivalent) violates the DMA. Since Meta doesn’t read the Google Consent API, the blocking trigger is your only line of defence.

Advanced Configuration and Optimisation

Once you have the basic implementation working, there are several advanced features that can improve data quality and user experience.

Managing Race Conditions with Wait for Update

One of the most technically subtle issues in Consent Mode is the race condition.

The issue:

A returning user loads the page. The browser starts executing GTM. The GA4 tag (on Initialization) prepares to fire. It checks the Consent API. The Cookiebot script (async) hasn’t finished reading the cookie yet. The API returns the “Default” state (Denied). GA4 fires a denied ping. 50ms later, Cookiebot finishes and updates the API to “Granted.”

The consequence:

The session starts as “Denied” (cookieless). The user is effectively bifurcated into a “Denied” user and a “Granted” user within milliseconds. Data quality degrades.

The solution:

This is precisely why the wait_for_update parameter exists. When configured in the Cookiebot template (e.g., 500ms or 2000ms), the Google tags enter a “Hold” state. They don’t fire immediately. They subscribe to the API and wait for the Update command. Once the update arrives (or the timer expires), they execute using the correct state.

This ensures the very first hit of the session carries the correct consent status.

Understanding URL Passthrough in Detail

When url_passthrough is set to true in the Cookiebot template, the gtag.js library activates its “Linker” functionality for same-origin links.

Technical behaviour:

When a user clicks a link on your site (e.g., from Home to Product Page), the script intercepts the click. If cookies are denied (meaning the Client ID cannot be stored), script appends query parameters (primarily _gl) to internal links. The _gl parameter contains an encrypted payload with the Client ID, Session ID, and any click identifiers (like GCLID), allowing session continuity without cookies.

Payload:

The _gl parameter contains a hashed, time-limited version of the Client ID and Session ID.

Destination:

When the Product Page loads, the GA4 tag on that page parses the URL, extracts the _gl parameter, decodes the Client ID, and initialises the session using that ID in memory rather than from a cookie.

Result:

The session is stitched together. The user count is 1 instead of 2. Conversion attribution is preserved.

Important caveat:

Ensure your web server (Apache/Nginx/IIS) is configured to ignore unknown query parameters. Some strict caching rules (like Varnish) might cache the page with the query parameter, serving a user-specific link to other users. Configure your caching layer to strip _gl before caching, or vary cache by query string.

Validation and Debugging

The implementation is only as good as its verification. Debugging Consent Mode v2 requires looking at the actual network signals sent to Google servers.

Understanding the gcs Parameter

In every network request to Google (GA4 collect, Google Ads conversion), there is a query parameter named gcs (Google Consent Status). It’s the primary indicator of the consent state at the moment the tag fired.

Format: G1xyzw (Consent Mode v2)

x: ad_storage (1 = Granted, 0 = Denied)
y: analytics_storage (1 = Granted, 0 = Denied)
z: ad_user_data (1 = Granted, 0 = Denied)
w: ad_personalization (1 = Granted, 0 = Denied)

Common values:

G10000: All denied (Advanced Mode ping)
G11111: All granted (Full consent)
G11100: Storage granted, usage denied

Troubleshooting:

If you see G100 but you’ve accepted cookies on the banner, your tag fired before the update (Race Condition). Check your wait_for_update setting and trigger priorities.

Decoding the gcd Parameter

Introduced with v2, the gcd (Google Consent Default) parameter is a complex encoded string that tells the full story of the consent interactions on the page. It encodes the state of all four signals (ad_storage, analytics, ad_user_data, ad_personalization) and their source (Default vs. Update).

Format: 11<ad_storage><analytics><ad_user_data><ad_personalization>...

The values are represented by letters that map to specific states.

Letter	Default State	Update State	Interpretation	Scenario
`l` (lowercase L)	Not Set	Not Set	ERROR. Consent Mode is not active.	Template missing or not firing.
`p`	Denied	(None)	Denied by Default. No update yet.	User just landed, banner visible, no interaction.
`q`	Denied	Denied	Denied by Default. Denied by Update.	User clicked “Reject All.”
`t`	Granted	(None)	Granted by Default.	Risk. Implies default was “Granted” (Not GDPR compliant).
`r`	Denied	Granted	Denied by Default. Granted by Update.	Ideal. User landed (denied), then clicked “Accept.”
`e`	Granted	Denied	Granted by Default. Denied by Update.	User revoked consent.

How to debug:

Open Chrome DevTools (F12)
Go to the Network tab
Filter for collect (GA4) or googleadservices
Click a request and look at the Payload (Query String Parameters)
Find gcd

Example interpretation:

11p1p1p1p5:

p (ad_storage): Denied Default, No Update
p (analytics): Denied Default, No Update
Conclusion: User has not interacted with the banner yet

11r1r1r1r5:

r: Denied Default → Granted Update
Conclusion: Valid GDPR consent flow

If you see l (e.g., 13l3l...), it means the Google tag loaded but could not find the Consent API signals. This usually indicates the Cookiebot CMP tag did not fire on “Consent Initialization” or failed to load.

Using Google Tag Assistant

Enable Preview Mode in GTM
Select the Consent tab in the debug interface (top bar)
Review the “On-Page Consent” table

What to check:

It should list all 4 parameters with initial values as “Denied” (for EEA).

Click on the “Consent Default” event in the left timeline:

Verify all are “Denied”

Click on the “Consent Update” event (after accepting banner):

Verify they change to “Granted”

Click on a specific tag (e.g., GA4 Config):

Check the “Consent” section of the tag execution
Status: “Succeeded” (if Granted) or “Active” (if Denied/Advanced)
“Active” confirms the tag is running in restricted mode rather than being blocked

Troubleshooting Common Issues

Zero Traffic in GA4

Symptom: After implementing Consent Mode, real-time traffic drops to near zero.

Cause: You likely added “Additional Consent Checks” to the GA4 tag settings in GTM. By adding analytics_storage as a required additional check, GTM was forced to block the tag entirely when consent was denied (Basic Mode behaviour), but the trigger logic wasn’t updated to support it.

Fix: Revert GA4 tags to “Additional Consent Checks: Not Set.” Trust the built-in behaviour.

Modelling Not Active

Symptom: “Modelled” data column in GA4 is empty or shows no uplift.

Cause 1: Insufficient volume. “Google requires sufficient conversion volume to train the model. While not officially documented, industry observation suggests approximately 500-700 conversions per day over a 7-day period. This threshold may vary by account type and industry.

Cause 2: ad_user_data is missing. If the CMP template is outdated, it might only be sending the v1 signals (ad_storage). Without the v2 signals, Google cannot validate eligibility for modelling.

Fix: Update the Cookiebot template in GTM. Verify the gcd parameter shows signals for all 4 types.

Symptom: Google Ads UI displays a warning that Consent Mode is not implemented.

Cause: Google’s bots crawl the site to verify implementation. If the default state is “Granted” (e.g., t in gcd) for an EEA IP address, the bot flags it as non-compliant.

Fix: Ensure Region-Specific Defaults are correctly configured in the Cookiebot template to set “Denied” for EEA country codes.

Symptom: Tags are firing with denied status even though users have previously consented.

Cause: Race condition. Tags are firing before Cookiebot reads the stored consent from the cookie.

Fix: Increase the wait_for_update value in the Cookiebot CMP template (try 2000ms).

Symptom: Third-party pixels (Facebook, LinkedIn, etc.) are firing even when users deny marketing consent.

Cause: Tags are still using standard “All Pages” trigger without consent checks.

Fix: Replace with the “Cookie Consent Update” trigger that only fires when cookiebot_consent_marketing equals true.

Maintenance and Ongoing Management

Consent Mode isn’t a “set and forget” system. It requires active maintenance to remain effective and compliant.

Template Updates

The GTM Community Template Gallery does not auto-update. You must periodically (quarterly recommended) check if the cybotcorp template has an update available.

Why this matters: Updates often include fixes for new browser restrictions (like ITP updates) or new Google API parameters.

How to check:

Go to Templates > Tag Templates in GTM
Look for an “Update Available” indicator on the Cookiebot CMP template
Review the changelog before updating
Test in a preview environment before publishing

Managing New Tags

Every new tag added to your container must be rigorously classified:

Ask yourself:

Does it support Consent Mode? (Google tags do, most others don’t)
If not, does it need the cookie_consent_update trigger?
What consent category does it belong to (Marketing, Statistics, Preferences)?

Adding a new Facebook Pixel on “All Pages” without consent checks effectively breaks the compliance of your entire container.

Periodically rescan your site in the Cookiebot console to ensure new cookies (dropped by new plugins or widgets) are categorised.

The risk: Uncategorised cookies might be blocked by Cookiebot’s auto-blocker (if enabled) or might leak through if you’re using manual GTM blocking without updated logic.

Recommended frequency: After any major site changes (new plugins, theme updates, new marketing tools).

Documentation

Maintain documentation of your consent implementation:

Which tags are Google tags vs. third-party tags
Which consent categories each tag requires
Your regional default settings
Any custom trigger logic
Known issues and their resolutions

This documentation becomes invaluable when onboarding new team members or troubleshooting issues months later.

Testing After Changes

After any changes to your GTM container, test the consent flow:

Clear your cookies
Load the site in an incognito window
Check the Network tab for consent signals
Accept the banner
Verify tags fire correctly
Reject the banner (new incognito window)
Verify Google tags fire in restricted mode
Verify non-Google tags don’t fire

This testing routine should take 5-10 minutes but prevents costly compliance mistakes.

Next Steps

Now that you’ve implemented cookie consent in GTM, here are the logical next steps to optimise your measurement setup:

Monitor Conversion Modelling Performance

If you’ve implemented Advanced Mode correctly, Google should begin modelling conversions from unconsented users within 7-14 days (assuming sufficient volume).

What to monitor:

Navigate to your GA4 property
Go to Reports > Engagement > Conversions
Look for the “Modelled” column
Compare modelled vs. observed conversions

If modelling isn’t active after 2-3 weeks with sufficient traffic, revisit your gcd parameter to ensure all four consent signals are present.

Implement Enhanced Conversions

With ad_user_data now properly signalled, you can implement Enhanced Conversions for Google Ads. This allows you to send hashed first-party data (email, phone, address) to improve conversion attribution.

Enhanced Conversions work particularly well with Consent Mode because they provide additional matching signals even when cookies are limited.

Set Up Server-Side Tagging

For organisations with higher traffic volumes and more complex privacy requirements, server-side tagging via Google Tag Manager Server-Side represents the next evolution.

Server-side tagging moves tag execution from the browser to your own server infrastructure, giving you complete control over what data is sent to third parties and when.

This pairs particularly well with Consent Mode because you can implement more sophisticated consent logic on the server side while reducing the JavaScript payload in the browser.

Your implementation is only as good as your consent rate. If only 10% of users consent, even perfect technical implementation won’t solve your data loss problem.

Consider:

Is your banner design clear and professional?
Is the copy easy to understand?
Are you explaining the value exchange (why users should consent)?
Have you tested different banner positions and designs?

Small improvements in consent rate (e.g., 30% to 45%) can dramatically impact your data quality.

If you’re operating globally, consider implementing region-specific consent strategies:

GDPR (EEA): Opt-in required (default Denied)
UK GDPR: Opt-in required (default Denied)
CCPA/CPRA (California): Opt-out model (default Granted with opt-out mechanism)
LGPD (Brazil): Opt-in required
Other regions: Assess local requirements

The Cookiebot template’s region-specific defaults make this straightforward to implement.

Audit Third-Party Scripts

Now that you have proper consent management in place, audit all third-party scripts on your site:

Which scripts are loading outside of GTM?
Which scripts need consent but aren’t being managed?
Can you move more scripts into GTM for better consent control?

Common culprits include:

Chat widgets (Intercom, Drift, etc.)
Social media embeds
Video players (YouTube, Vimeo)
Payment processors

Many of these can be lazy-loaded through GTM with proper consent checks.

Conclusion

Implementing cookie consent in Google Tag Manager requires precise coordination between your Consent Management Platform, GTM configuration, and Google’s tracking endpoints. The technical details—trigger sequences, consent parameters, and signal validation—determine whether your implementation achieves both compliance and measurement utility.

This guide has walked you through the complete setup process: configuring your CMP to broadcast consent signals, setting up GTM tags and triggers to respect those signals, handling both Google and non-Google tags appropriately, and debugging the consent flow to verify correct implementation.

Privacy regulations will continue to evolve, and browser restrictions will become more stringent. By building your measurement infrastructure on a consent-first foundation, you’ve created a system that can adapt to these changes while maintaining the data visibility your business needs.

If you encounter issues during implementation, refer back to the troubleshooting section, use the debugging techniques covered in the validation section, and test thoroughly before publishing to production.

Table of Contents