Why GTM Fires Before Consent by Default
Google Tag Manager does not block anything out of the box. Every tag configured with an "All Pages" trigger fires the moment the GTM container loads, regardless of whether the visitor has made a consent choice. For tags that set cookies like _ga, _fbp, or _gcl_au, this creates an immediate compliance problem.
Article 5(3) of the ePrivacy Directive requires prior consent before storing or accessing information on a user's device, unless the cookie is strictly necessary. The GDPR reinforces this through its consent requirements under Articles 6 and 7.
A March 2025 ruling by the German Administrative Court of Hanover went further: the court held that loading GTM itself requires consent, because the container script connects to Google's servers, transmits IP addresses, and stores JavaScript locally on the visitor's device. This ruling treats GTM as active data processing under both the GDPR and Germany's TTDSG.
Three Approaches to Blocking Tags Before Consent
There are three primary methods for preventing GTM tags from firing until the visitor grants consent. Each addresses a different layer of the problem.
| Approach | How It Works | Best For |
|---|---|---|
| Consent Initialisation trigger | Sets consent defaults to "denied" before any other trigger fires | Sites using Google Consent Mode v2 |
| dataLayer push event | CMP pushes a custom event after consent; tags use that event as their trigger | Custom CMP integrations |
| Script blocking (type/plain swap) | GTM container script itself is blocked until consent, using type="text/plain" | Strict compliance or jurisdictions requiring full script blocking |
Most implementations combine the first two approaches. The third is relevant when regulators expect the GTM container itself to be blocked, as the German court ruling suggests.
Setting Consent Defaults with the Consent Initialisation Trigger
Every GTM web container includes a built-in trigger called Consent Initialisation - All Pages. This trigger fires the gtm.init_consent event before all other triggers, including the standard Initialisation and Page View triggers.
The purpose is straightforward: attach your consent default tag to this trigger so that all consent states are set to "denied" before any measurement or marketing tag attempts to fire.
Step-by-Step Configuration
Create a new tag in GTM using the Google tag or a CMP consent template. Set the following Consent Mode v2 defaults:
ad_storage: deniedad_user_data: deniedad_personalization: deniedanalytics_storage: denied
Assign the Consent Initialisation - All Pages trigger to this tag. Do not use a Custom HTML tag for this purpose. Google's documentation explicitly warns against it, because Custom HTML tags do not integrate with the Tag Manager consent APIs and cannot guarantee execution order.
Tags with analytics or marketing cookie requirements will now remain blocked until the corresponding consent state is updated to "granted".
Updating Consent State via dataLayer Push
Once a visitor interacts with your cookie banner and grants consent, the consent state must be updated. Your CMP handles this by pushing an event to the dataLayer.
A typical dataLayer push after consent looks like this:
window.dataLayer.push({ event: 'consent_update', ad_storage: 'granted', analytics_storage: 'granted', ad_user_data: 'granted', ad_personalization: 'denied' });
The CMP should call gtag('consent', 'update', {...}) or use the Tag Manager consent API's updateConsentState method. The updateConsentState method is preferred inside GTM because it processes consent changes before any queued dataLayer items, preventing race conditions where a tag fires before the consent update is registered.
Creating a Trigger for the Consent Update Event
If your tags rely on a custom event rather than built-in consent checks, create a Custom Event trigger in GTM with the event name your CMP pushes (for example, consent_update or cookie_consent_given). Assign this trigger to any tag that should only fire after consent.
This approach works well for tags that do not natively support Consent Mode, such as older tracking pixels or custom scripts. For Google's own tags (GA4, Google Ads, Floodlight), built-in consent checks are more reliable because they respond directly to the consent state rather than relying on a separate trigger event.
Blocking the GTM Container Script Entirely
The consent initialisation approach assumes that loading the GTM container is acceptable and that blocking happens at the tag level inside GTM. The 2025 German court ruling challenges this assumption.
If your legal assessment requires blocking GTM itself until consent, there are two methods:
The first is the type="text/plain" swap. Change the GTM snippet's script type from text/javascript to type="text/plain" and add a data attribute like data-category="analytics". Your CMP then changes the type back to text/javascript and executes the script after consent. This is the same technique used for conditionally loading third-party scripts.
The second method uses the CMP's callback API. The GTM snippet is not present in the initial HTML at all. Instead, the CMP injects it dynamically after consent through a JavaScript callback.
Both methods mean that no GTM tags fire and no connection to Google's servers occurs until the visitor opts in. The trade-off is that you lose the ability to set consent defaults via the Consent Initialisation trigger, because the container itself has not loaded.
Consent Mode v2: Built-in Consent Checks for Google Tags
Consent Mode v2 adds built-in consent awareness to Google tags. When analytics_storage is set to "denied", the GA4 tag will still load but will not set cookies. Instead, it sends cookieless pings that Google uses for conversion modelling.
This behaviour is specific to Google's own tags. Third-party tags like the Meta Pixel, LinkedIn Insight Tag, or Hotjar do not respond to Consent Mode signals. For those tags, you must configure additional consent requirements within GTM's tag settings.
Adding Consent Requirements to Non-Google Tags
In GTM, open any non-Google tag and navigate to Advanced Settings, then Consent Settings. Select "Require additional consent for tag to fire" and add the relevant consent types (typically ad_storage or analytics_storage). The tag will now respect the same consent state set by your Consent Initialisation tag.
This is the cleanest approach for mixed containers that include both Google and third-party tags.
Testing and Verifying Your Setup
A misconfigured consent setup is worse than no setup at all, because it creates a false sense of compliance. Use GTM's Preview mode (Tag Assistant) to verify the firing sequence.
Check for the following in Tag Assistant:
- The Consent Initialisation event appears first in the event timeline
- All consent states show "denied" before any user interaction
- Marketing and analytics tags display a "Blocked" or "Paused" status
- After simulating consent, the relevant tags fire and consent states update to "granted"
Open the browser's DevTools Application panel to confirm that no _ga, _fbp, or _gcl_au cookies are set before consent. The Network tab should show no requests to google-analytics.com, facebook.com/tr, or similar endpoints until after the consent update event. For a detailed walkthrough, see the guide on testing your cookie banner.
Common Mistakes That Break Consent Blocking
The most frequent error is using a Custom HTML tag to set consent defaults. Custom HTML tags run outside the consent API pipeline, so other tags may fire before the defaults are applied. Always use a dedicated consent template or the built-in Google tag.
Another common problem: forgetting to set ad_user_data and ad_personalization defaults. These two consent types were added in Consent Mode v2 and are required for Google's EU User Consent Policy. Omitting them triggers the Tag Assistant warning "A tag read consent state before a default was set."
Race conditions also cause issues. If your CMP loads asynchronously and the GTM container fires before the CMP has set defaults, tags may briefly operate in an undefined consent state. Loading the CMP script before the GTM container script in the page source resolves this.
Frequently Asked Questions
Does Google Tag Manager set cookies on its own?
GTM itself does not set cookies directly. The tags inside the container (such as GA4, Google Ads, or the Meta Pixel) are what set cookies like _ga or _fbp. GTM does, however, connect to Google's servers and store JavaScript locally, which a German court ruled requires consent under GDPR and TTDSG.
What is the difference between Consent Initialisation and Initialisation triggers in GTM?
The Consent Initialisation trigger fires the gtm.init_consent event before everything else, including Initialisation triggers. Use Consent Initialisation for setting consent defaults. Use the Initialisation trigger for non-consent-related setup tasks like dataLayer variable configuration.
Can I use Google Consent Mode without a CMP?
Technically yes, by hardcoding consent defaults and updates yourself. In practice, you need a CMP to collect and store visitor consent choices, update consent states dynamically, and provide the audit trail that regulators expect.
Do I need to block GTM entirely or just the tags inside it?
Under most regulatory guidance, blocking tags inside GTM is sufficient. The 2025 German court ruling suggests that loading the GTM container itself may require consent because it transmits data to Google. If you operate in Germany or want maximum caution, consider blocking the container script until consent.
What happens to Google Analytics data when consent is denied?
With Consent Mode v2 active, GA4 sends cookieless pings when analytics_storage is denied. Google uses these pings for conversion modelling to estimate the data gap. Without Consent Mode, no data is collected at all when the tag is blocked.
How do I handle consent for server-side GTM?
Server-side GTM still requires consent because it processes the same user data. The consent check happens on the client side before the event is sent to the server container. The server container does not add or bypass consent requirements.
Take Control of Your Cookie Compliance
If you are not sure which cookies your site sets, start with a free scan. Kukie.io detects, categorises, and helps you manage every cookie - so your visitors get a clear choice, and you stay on the right side of the law.
