---
title: "Google Tag Manager bis Zustimmung in Usercentrics blockieren: Warum, wie und was schief laufen kann"
id: "1796"
type: "post"
slug: "google-tag-manager-bis-zustimmung-in-usercentrics-blockieren"
published_at: "2026-07-28T13:03:11+00:00"
modified_at: "2026-07-28T14:19:31+00:00"
url: "https://www.markus-baersch.de/blog/google-tag-manager-bis-zustimmung-in-usercentrics-blockieren/"
markdown_url: "https://www.markus-baersch.de/blog/google-tag-manager-bis-zustimmung-in-usercentrics-blockieren.md"
excerpt: "Was kann schon bei der Einbindung des Google Tag Managers schief laufen, wenn man ihn nur bei Zustimmung in Usercentrics laden will? Eine Menge. Ich hatte einen sehr speziellen Fall, bei dem \"self-closing\" script Tags (die es nicht gibt) vor..."
taxonomy_category:
  - "Datenschutz"
  - "Google Tag Manager"
---

[Start](/)
 » [Blog](/blog/)
 » [Datenschutz](https://www.markus-baersch.de/blog/thema/datenschutz/)
 / [Google Tag Manager](https://www.markus-baersch.de/blog/thema/google-tag-manager/)

Was kann schon bei der Einbindung des Google Tag Managers schief laufen, wenn man ihn nur bei Zustimmung in Usercentrics laden will? Eine Menge. Ich hatte einen sehr speziellen Fall, bei dem "self-closing" `script` Tags (die es nicht gibt) vor dem für Usercentrics modifizierten Code des GTM standen und so kein Match des Unblockers stattgefunden hat. Das war mir neu, aber ich habe auch schon andere Fehlerquellen beobachtet. Genug Material, um diese hier zusammenzufassen.

### Blocking von GTM vor Zustimmung: Warum überhaupt?

Das Hauptargument ist schlicht die Netzwerkverbindung und den dabei zwingend stattfindenden **IP-Transfer vs. Anforderungen von "Schrems II" und dem TDDDG**. Denn sobald das GTM-Snippet ausgeführt wird, baut der Browser eine Verbindung zu*www.googletagmanager.com* auf, um den Container zu laden. Dabei werden unweigerlich die IP-Adresse, der User-Agent und der Referrer des Nutzers an Server eines US-Konzerns übertragen. Nach Auslegung des TDDDG (früher TTDSG) ist dieser Abruf technisch nicht zwingend für den Betrieb der Seite erforderlich. Gleichzeitig ist die IP-Adresse ein personenbezogenes Datum (DSGVO), das ohne Einwilligung in ein unsicheres Drittland (USA) fließt. Hard-Blocking ist der einzige Weg, diesen initialen Verbindungsaufbau zu 100 Prozent zu unterbinden, solange man von *www.googletagmanager.com* laden will. Inwiefern eine Bereitstellung über den eigenen Server oder ein Google Tag Gateway alle Probleme löst, sei dahingestellt, denn das TDDDG kann z. B. immer noch so ausgelegt werden, dass das Laden an sich - egal von wo - als unnötig eingestuft wird. Dass man aber zumindest das IP Thema so entschärfen kann, ist unstrittig.

Dennoch: in der Praxis entsteht **kaum ein messbarer Unterschied**, ob ein GTM schon da ist und Dienste nur nach Zustimmung ausspielt oder ob der GTM selbst erst dann geladen wird, wenn eine Zustimmung gegeben wird. Dabei steckt der GTM gern in einer Kategorie wie "*Statistik*", aber auch "*Marketing*" oder jede andere, die nicht "*essenziell*" ist und schon vor Consent stattfindet, macht den Job. Betrachtet man die Zahlen von "individuellem" Consent (also etwas anderem als Nichtstun, alles ablehnen oder allem zustimmen), betrifft dies typischerweise weniger als ein Prozent der Entscheidungen. Und selbst dann ist nicht davon auszugehen, dass Marketing und anderen Kategorien zugestimmt wurde, dem GTM als ggf. in "*Statistik*" einsortiert aber nicht.

Daher ist es in dem meisten Fällen wünschenswert, das GTM Script nicht einfach unverändert im Seitenquellcode zu halten, sondern entsprechend anzupassen. Voraussetzung ist dabei natürlich, dass auch Usercentrics direkt in die Seite implementiert wird. Das Laden von Usercentrics über den GTM ist in diesem Fall - aber nicht nur hier - keine Option.

Ein weiterer Grund, der nicht unwesentlich ist: Wenn der GTM direkt geladen wird, **muss das Trigger-Konzept im GTM sitzen** und wirklich alles blockieren, wenn keine Zustimmung vorhanden ist. Versemmelt das jemand und veröffentlicht eine Version mit unblockierten, aber consent-relevanten Tags, nutzt ggf. auch der Blocker nichts mehr.

#### Advanced Consent Mode vs. blockierter GTM

Ich bin bekannterweise kein Fan des "Erweiterten Zustimmungsmodus" von Google. Wer ihn aber nutzen will, muss bedenken, dass in einem solchen Fall keine Daten fließen, wenn keine Zustimmung zu der Kategorie erfolgt, in der der Tag Manager steckt. Andere Wege zu finden, den GTM z. B. erst nach Interaktion mit Usercentrics zu laden, aber nicht bereits vorher, ist in einem solchen Fall die einzige Option, mit der man das Thema zumindest teilweise entschärfen könnte, aber dennoch auch bei Ablehnung "etwas stattfinden zu lassen" im GTM. In Usercentrics nach Zustimmung zum GTM zu fragen ist dann aber nicht mehr sinnvoll; eine solche Lösung muss separat angestrickt werden. Wer allerdings das Datenschutzthema so locker nimmt und Advanced Consent Mode als tragbar erachtet, wird sich i. d. R. keine Gedanken um das Laden des GTM machen, denn so oder so werden auch die Google-Tags dann geladen und Requests an Google-Endpunkte gesendet, wenn man nicht, wie oben beschrieben, wenigstens eigene Proxy-Infrastruktur vorschiebt, z. B. in Form eines Tag Gateways oder server-side GTM.

### Blocking von Script in Usercentrics

Um in UC ein Script zu blockieren (siehe [Anleitung](https://support.usercentrics.com/hc/en-us/articles/18656524460700-Manually-blocking-services-prior-consent)
), wird es zuerst "entschärft", in dem es per `type`-Attribut zu normalem Text degradiert wird und dann wird über ein weiteres Attribut angegeben, zu welchem Consent-Eintrag / Service dieses Script gehört. Dieser wird im hinzuzufügenden data-usercentrics Attribut über den Namen aus Usercentrics referenziert. Ab Beispiel eines Standard-GTM-Codes sieht das z. B. so aus:

<script **type="text/plain" data-usercentrics="Google Tag Manager"** nonce="xxxxxxxxxxxxx">(function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':  
 new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],  
 j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src=  
 'https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);  
 })(window,document,'script','dataLayer','GTM-XXXXXXX');</script>

### Typische Fehlerquellen

Wenn das Ganze nicht wie gewünscht funktioniert, liegt es vermutlich an einem der folgenden Aspekte.

#### Probleme in der Umgebung des Scripts

Wenngleich dies nicht die typischste Ursache sein mag, war dieser Fall der Auslöser für diesen Post. Er ist besonders heimtückisch, weil das Script selbst einwandfrei angepasst wurde. Grund waren zwei Script Tags (es hätte aber auch eines davon gereicht), die vor dem angepassten GTM Code standen. Das sah in etwa wir folgt aus:

<script src="https://web.cmp.usercentrics.eu/ui/loader.js" id="usercentrics-cmp" data-settings-id="ABC-def" data-language="de" nonce="xxxxxxxxxxxxx"**/>**  
 <script src="https://privacy-proxy.usercentrics.eu/latest/uc-block.bundle.js" type="application/javascript" nonce="xxxxxxxxxxxxx"**/>**  
 <script type="text/plain" data-usercentrics="Google Tag Manager" nonce="xxxxxxxxxxxxx">(function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':  
 new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],  
 j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src=  
 'https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);  
 })(window,document,'script','dataLayer','GTM-XXXXXXX');</script>

Das Problem hierbei sind die beiden Scripts über dem GTM Block. Beide sind als "self-closing" gestaltet, enden also mit "`/>`" statt "`></script>`". Da hier - logischerweise - keine entsprechenden `data-usercentrics`-Attribute und natürlich auch der falsche (weil für JS richtige) `type` am öffnenden Tag zu finden ist, kommt erst nach dem modifizierten GTM Block das erste `</script>`. Der Browser scheint das auf den ersten Blick zu verzeihen und die self-closing script Tags zu verdauen - beide werden geladen. Im DOM landet aber nie ein Knoten für diese Scripts und es kommt zu keiner wirklichen Ausführung. Vor allem fehlt aber eben auch ein Script mit einem passenden `data-usercentrics`-Attribut im DOM des Browsers. Das Script zum Entblockieren sucht aber eben explizit nach solchen `script`-Tags mit den passenden Attributen im DOM. Der enthält an dieser Stelle aber faktisch nur Text, kein `script`-Tag als selektierbares DOM Element. Im DOM ist also der ganze Block faktisch von oben bis unten eine Einheit und entspricht nicht dem Selektor. Folgerichtig würde selbst dann nichts entsperrt, wenn das Unblocker-Script wirklich ausgeführt und nicht nur geladen würde, nur weil der Preload-Scanner des Browsers sich nicht um korrekten Aufbau des DOM kümmert.

Nach Korrektur der Einbindung der beiden Scripte funktionierte alles einwandfrei. **Aber was hätte den sonst noch schief gehen können**? Hier ein paar Fundstellen, die in der einen oder anderen Form so bereits vorgekommen sind.

#### Gut gemeinte Ergänzung von Attributen

**Async/Defer Chaos**: Wenn Performance-Optimierungs-Plugins dem blockierten GTM-Script nachträglich und gut gemeint ein "`defer`" oder "`async`" Attribut hinzufügen, kann das Unblocking-Script beim Umschreiben des Typs zu "`text/javascript`" in Ausführungs-Konflikte geraten.

#### Subtile Fehler im Namen: Leerzeichen

Das Attribut `data-usercentrics="..."` muss exakt – bis auf das letzte Leerzeichen und die exakte Groß-/Kleinschreibung – mit dem Namen des Data Processing Services (DPS) im Usercentrics-Backend übereinstimmen. Ein unscheinbares Leerzeichen am Ende (`data-usercentrics="Google Tag Manager "`), Zeichendreher oder Nutzung einer alternativen ID führt ggf. dazu, dass die Zustimmung im Banner erteilt wird, das Script aber dennoch nicht geladen werden darf.

#### <noscript>-Part vergessen

Wer in seiner Implementierung wirklich noch den faktisch nutzlosen (okay, GSC Verifikation vielleicht. Aber dann bitte lieber einen der anderen Wege verwenden!) `<noscript>`-Snippet im `<body>` hat, sollte ihn einfach komplett entfernen. Sonst führt das `<noscript>`-Iframe ohne JavaScript zwar keinen komplexen Code aus dem GTM aus, könnte aber theoretisch dort verbaute Image-Tags auslösen und - vor allem - werden in diesem Fall Ressourcen von Google geladen. Auch der "abgespeckte" `noscript`-GTM Container-Inhalt als - meistens leere - HTML Seite im iFrame ist ein externer Aufruf... und genau das galt es ja durch das Blocking bis zur Zustimmung zu verhindern.

### Probleme sind typischerweise hausgemacht

Wenn also der Tag Manager oder ein anderes Script nicht geladen wird, obschon die implementierte modifizierte Fassung korrekt aussieht und die entsprechenden Ressourcen von Usercentrics einwandfrei geladen zu werden scheinen, lohnt sich ein Blick in die Umgebung der betreffenden Script-Blöcke ebenso wie ein zweiter Check aller Attribute, die in der real vom System produzierten Seite zu finden sind.