Does Google Tag Manager (GTM) require user consent? Breaking down the 2025 decision from Germany

Earlier this year, the Administrative Court of Hannover, Germany, issued a judgment ruling that Google Tag Manager (GTM) requires user consent before activation. 

‍

While the decision initially drew limited attention beyond Germany's borders, its implications are now gaining momentum, as organizations realize the potential impact on their operations.

‍

In this article, we cover the intricacies of the decision, what it means for organizations using GTM, and present ways to ensure compliance in Germany and (potentially soon) beyond. 

‍

Understanding the GTM decision from the Administrative Court of Hannover

The Administrative Court of Hannover delivered a judgment earlier this year, ruling that Google Tag Manager (GTM) requires explicit user consent before activation. 

‍

What does that mean? 

‍

First, it’s important to understand how GTM technically functions:

1. Upon loading a web page (and prior to any consent interaction), the browser contacts GTM.
2. During this contact, user device data, including IP addresses, device configuration, country, and referrer URL, is transmitted to Google servers.
3. Additionally, a customized gtm.js script is stored on the user’s device.

What is the issue? This behavior requires consent under German privacy law (TTDSG §25(1)) for storing/accessing device information, and a legal basis under the General Data Protection Regulation (GDPR).

‍

In this case, however, the legitimate interest legal basis was rejected, as GTM before consent was not considered "necessary" by the Administrative Court, and user privacy rights outweigh commercial interests, especially given early, cross-site data flows to a large platform.

‍

Long story short: Under this decision, Google Tag Manager requires user consent.

‍

Does this GTM decision have the potential to expand past Germany? 

While the ruling happened in Germany, it establishes a precedent that could influence similar cases across the European Union. It wouldn’t be the first time we’ve seen several actions targeting Google spread across Europe and various DPAs in the last couple of years:

Critically, the decision applies the EU's ePrivacy Directive (implemented in Germany as TTDSG) and the overarching European framework of the GDPR, appealing to principles that could be consistent in other jurisdictions (ie, enforcement must begin at the point of script execution).

‍

Note that the reasoning about non-essential services requiring user consent applies to similar technical implementations across the marketing technology ecosystem, including other major tag management platforms beyond Google Tag Manager.

‍

What does it mean for organizations using GTM? 

Following this decision, GTM can be considered a "legal risk" in Germany, and organizations may face non-compliance risks even before any tracking pixel is activated. Preloading GTM, even for performance or analytics purposes, means assuming regulatory risk.

‍

Organizations must thus consider taking actionable steps to ensure compliance.

‍

What are your options if you use Google Tag Manager?

So, what can you do? The crux of the decision is that personal data (e.g., IP addresses) should not be transmitted to a third party before explicit consent.

‍

It’s worth noting that Google Consent Mode alone won’t be sufficient to solve the problem, as the initial GTM load still transmits technical identifiers before consent, nor will loading a Consent Management Platform (CMP) via GTM before consent. 

‍

German Data Protection Authorities (DPAs) and courts have also rejected:

‍

• Locally hosting gtm.js (the legal issue is data transmission at load, not file location).
• Categorizing GTM as "functional" or "essential" (it is not considered "strictly necessary").

‍

Here are the actual, valid options available to organizations using Google Tag Manager:

‍

1. Obtain valid prior consent for GTM 

The court's ruling means that GTM cannot run until the user explicitly says yes. As a result, an option is to gate GTM behind consent, ensuring gtm.js or contacts to googletagmanager.com do not occur until the user has opted in.

The safest implementation sequence is to load your Consent Management Platform (CMP) first, wait until the user expresses a consent signal (preferably for marketing or tracking purposes), and then dynamically inject GTM only once that consent is recorded.

‍

Ensure that systems are in place to remove or disable GTM if consent is later revoked. Additionally, be aware of potential data loss with this solution: If users decline consent for GTM itself, none of the tags within GTM (analytics, ads, pixels, etc.) will fire, effectively stopping all tracking for those users.

‍

2. Remove or replace GTM entirely

Some other professionals are suggesting dropping GTM altogether, and adopting alternative approaches such as:

‍

• Hard-code all tags: While minimizing compliance issues, this would significantly limit digital capabilities for organizations.
• Implement direct, consent-conditioned loaders: Use custom code or CMP-integrated tag firing to trigger tags only after consent.
• Consider alternative tag managers: While options like Adobe Launch or Tealium IQ exist, many might still encounter similar issues by pinging their own servers at load, potentially making them non-compliant under this ruling.

‍

While a valid alternative, these options are not realistic for every organization, especially for teams that have put significant time and effort into configuring Google Tag Manager and are not ready to start anew (understandably).

‍

3. Implement Addingwell by Didomi

By implementing a CDN between the browser and Google's servers using Addingwell by Didomi, organizations are able to avoid sending data to Google while loading files.

‍

How to ensure compliance with the right server-side GTM implementation?

Addingwell by Didomi offers an infrastructure designed to host a server-side GTM container, specifically designed to address these compliance concerns. At its core, this is how it works:

‍

1. When core GTM files like gtm.js, and gtag/js are requested, Addingwell performs the request as a server and then forwards it to the user. This means no user data or headers are passed directly to Google from the user's browser for these files. Addingwell's server makes a fetch call to the original Google URL, excluding any headers and request information.
2. For the GTM "geo token" (used by gtm.js), Addingwell obtains the country and region from the original user request. It then requests a regional token from Google based on these values, performing a fetch call without any headers going through. The user's actual fingerprint never goes to Google during this process.

‍

See the following diagram for a clear picture of how the process works, with and without Addingwell:

The privacy benefits of this approach cover two areas:

‍

• File Loading Protection:
  
  • When loading common Google files (gtm.js, analytics.js, etc.), no user data reaches Google
  • Only Addingwell's servers communicate with Google - end users stay anonymous
  • Files are cached, so most requests don't even need to contact Google
• Geographic Information:
  
  • For location-based features, Addingwell only shares basic country/region info with Google
  • No personal identifiers, IP addresses, or browser fingerprints are included. 

Get started today with Addingwell by Didomi

Didomi acquired the server-side tracking platform Addingwell earlier this year. 

‍

Our joint expertise and set of solutions enable us to support clients in confidently facing this type of scenario, and we’d be happy to discuss your specific use case to ensure you avoid unfavorable outcomes in Germany, while maximizing your data collection opportunities. 

‍

Book a time with one of our experts to learn more.