Der Google Tag Manager ist ein kostenloses Werkzeug, mit dem Sie Mess- und Marketing-Skripte an einer Stelle verwalten, statt sie einzeln in den Quelltext zu schreiben. Sie binden einmal einen Container ein und steuern darin über Tags, Trigger, Variablen und die Datenschicht, was wann feuert. Ausgewertet wird woanders — der Tag Manager erhebt selbst keine Berichtsdaten.
- Was es istVerwaltung für Mess- und Marketing-Tags, kein Analyse-Werkzeug
- Container-TypenWeb, Android, iOS und Server
- KostenStandardversion kostenlos; Tag Manager 360 kostenpflichtig
- Vier BausteineTags, Trigger, Variablen, Datenschicht
- EinbauSkript so weit oben wie möglich im <head>, noscript nach <body>
- ArbeitsbereicheDrei: ein Standard- und zwei eigene (360: unbegrenzt)
- EinwilligungIntegrierte und zusätzliche Einwilligungsprüfungen je Tag
Angaben nach der Tag-Manager-Hilfe und der Google-Entwicklerdokumentation, geprüft im August 2026. Die vollständige Quellenliste finden Sie am Ende des Beitrags.
1. Was der Tag Manager macht — und wovon er sich unterscheidet
Die häufigste Verwechslung im Erstgespräch: Tag Manager und Analytics gelten als dasselbe. Sie sind es nicht. Der Tag Manager ist ein Verwaltungswerkzeug, kein Analyse-Werkzeug. Er entscheidet, welcher Code unter welcher Bedingung ausgeführt wird. Was mit den Daten danach passiert, ist Sache des Zielprodukts.
Google beschreibt den Container als Sammlung von Tags, Triggern, Variablen und den zugehörigen Konfigurationen, die in eine Website oder mobile App eingebunden wird. Er ersetzt die Skripte, die sonst von Hand im Quelltext stehen. Vier Werkzeuge werden dabei regelmäßig durcheinandergeworfen:
| Werkzeug | Aufgabe | Rolle im Datenfluss |
|---|---|---|
| Google Tag Manager | Verwaltet, welches Skript wann feuert | Erhebt selbst keine Berichtsdaten |
| Google Analytics 4 | Wertet das Nutzerverhalten aus | Das Ziel, an das gemessen wird |
| Google-Tag (gtag.js) | Bindet ein Google-Produkt direkt in den Quelltext ein | Alternative zum Container, kein Widerspruch |
| Server-Container (sGTM) | Verlagert die Tag-Ausführung auf einen eigenen Endpunkt | Eigene Infrastruktur, eigene Kosten |
Die Zeilen zwei und vier haben eigene Beiträge, weil sie eigene Entscheidungen verlangen: Wie Sie das Analyse-Werkzeug dahinter aufsetzen, steht in unserer Anleitung Google Analytics 4 einrichten. Ob sich die serverseitige Variante für Sie rechnet, ordnet der Beitrag Server-Side-Tracking: Wann sich der Aufwand wirklich lohnt mit Kosten und Grenzen ein. Dieser Artikel bleibt beim Web-Container im Browser.
Container gibt es laut Google für vier Plattformen: Web, Android, iOS und Server. Für eine klassische Unternehmenswebsite ist der Webcontainer der richtige — die anderen drei brauchen Sie erst, wenn Sie eine App messen oder die Tag-Ausführung auf einen eigenen Endpunkt verlagern wollen.
2. Die vier Bausteine: Tags, Trigger, Variablen, Datenschicht
Wer diese vier Begriffe einmal sauber getrennt hat, versteht jede Anleitung im Netz. Sie bauen aufeinander auf: Das Tag tut etwas, der Trigger sagt wann, die Variable liefert den Wert, die Datenschicht liefert die Daten aus Ihrer Website.
Tags
Das Stück Code, das etwas tut: ein Seitenaufruf an Analytics, eine Conversion an Google Ads, ein Pixel-Aufruf. Für die gängigen Dienste liefert der Tag Manager fertige Vorlagen, in die Sie nur noch die Ziel-ID eintragen.
Trigger
Die Bedingung, durch die ein Tag ausgelöst wird — ein Seitenaufruf, ein Klick auf eine bestimmte Schaltfläche, ein Formularversand, ein eigenes Ereignis aus der Datenschicht. Ein Tag ohne Trigger feuert nie.
Variablen
Platzhalter für Werte, die sich je Seitenaufruf ändern: die aktuelle URL, der Text des angeklickten Elements, der Bestellwert. Sie halten Tag-Konfigurationen kurz, weil Sie denselben Wert nicht an zehn Stellen pflegen.
Datenschicht
Laut Google ein Objekt, das Informationen an Tags übergibt. Ihre Website schreibt dort hinein, was der Container wissen soll — Bestellwert, Artikelnummer, Kundentyp. Ohne Datenschicht bleibt der Container auf das angewiesen, was er im HTML errät.
Die Datenschicht ist der Baustein, der in Projekten am häufigsten fehlt — und der über die Haltbarkeit Ihres Setups entscheidet. Google definiert sie als Objekt, das von Tag Manager und gtag.js verwendet wird, um Informationen an Tags zu übergeben. Technisch ist sie ein Array, das Ihre Seite vor dem Container anlegt und danach befüllt:
window.dataLayer = window.dataLayer || []; legt sie an, ohne bereits vorhandene Werte zu überschreiben. Mit dataLayer.push({'event': 'kauf_abgeschlossen'}) meldet Ihre Seite ein Ereignis, mit dataLayer.push({'bestellwert': 149.90}) einen Wert. Auf beides können Trigger und Variablen zugreifen.
Der Unterschied in der Praxis: Ein Trigger, der auf ein Ereignis aus der Datenschicht hört, funktioniert nach jedem Relaunch weiter. Ein Trigger, der auf eine CSS-Klasse oder einen Button-Text hört, ist beim nächsten Theme-Update kaputt — und niemand merkt es, weil keine Fehlermeldung erscheint. Wir bestehen deshalb in jedem Projekt darauf, die relevanten Ereignisse einmal sauber in die Datenschicht zu schreiben, bevor der erste Trigger entsteht.
3. Container anlegen und einbauen
Bis zum ersten funktionierenden Tag brauchen Sie fünf Handgriffe. Planen Sie eine gute Stunde ein, wenn Sie Zugriff auf die Templates Ihrer Website haben — ohne diesen Zugriff scheitert es an Schritt zwei, nicht an Google.
- Konto und Container anlegen. Melden Sie sich unter tagmanager.google.com an. Das Konto steht für Ihr Unternehmen, der Container für eine Website. Wählen Sie als Zielplattform „Web". Sie erhalten eine Container-ID im Format GTM-XXXXXXX.
- Beide Code-Blöcke einbauen. Google gibt die Platzierung eindeutig vor: den ersten Block „so weit oben wie möglich im
<head>-Tag", den zweiten „direkt nach dem öffnenden<body>-Tag". Der zweite Block ist einnoscript-Fallback mit einem iframe und gehört deshalb nicht in den Head — sonst ist Ihr HTML ungültig. Das Container-Skript lädt asynchron und blockiert den Seitenaufbau nicht. - Datenschicht vor dem Container initialisieren. Die Zeile
window.dataLayer = window.dataLayer || [];gehört über den Container-Code. Steht sie darunter, sind Werte, die früh gesetzt werden, für die ersten Tags nicht sichtbar. - Einwilligungs-Standard setzen, bevor irgendetwas feuert. Der Standardstatus muss stehen, bevor das erste Tag ausgeführt wird — sonst hat die Reihenfolge über Ihr Setup entschieden und nicht Sie. Details dazu im nächsten Abschnitt.
- Erstes Tag, Trigger, Vorschau, Version. Legen Sie ein Tag an, weisen Sie ihm einen Trigger zu, prüfen Sie beides in der Vorschau — und veröffentlichen Sie erst dann. Ein Container, der nie veröffentlicht wurde, ist auf der Website nicht aktiv.
Ein Hinweis aus Projekten mit Redaktionssystemen: Viele Themes und Plugins bieten ein Feld „Google Tag Manager ID". Nutzen Sie es, statt den Code von Hand ins Template zu schreiben — sonst verschwindet der Container beim nächsten Theme-Update. Prüfen Sie danach im Quelltext, dass der Container wirklich nur einmal geladen wird.
4. Consent: damit vor der Einwilligung nichts feuert
Das ist der Teil, den die englischsprachigen Anleitungen überspringen und der hier die eigentliche Arbeit ausmacht. § 25 TDDDG verlangt eine Einwilligung, bevor Informationen auf dem Endgerät eines Nutzers gespeichert oder ausgelesen werden. Auf ein Tracking-Setup übersetzt heißt das: Analytics-, Ads- und Pixel-Tags dürfen erst nach der Zustimmung laufen.
Hinweis: Dieser Abschnitt ist allgemeine Information und ersetzt keine Rechtsberatung. Maßgeblich sind § 25 TDDDG und die DSGVO; für Ihren konkreten Fall ist Ihre Rechtsberatung zuständig. Stand: August 2026.
Die sieben Einwilligungstypen
Der Einwilligungsmodus arbeitet mit benannten Parametern. Ihr Consent-Banner setzt sie auf granted oder denied, der Container liest sie aus. Diese sieben sollten Sie kennen:
| Parameter | Wofür er steht | Typisch betroffen |
|---|---|---|
ad_storage |
Speicherung für Werbezwecke, insbesondere Werbe-Cookies | Google Ads, Floodlight |
analytics_storage |
Speicherung für Analysezwecke, etwa die Wiedererkennung von Sitzungen | Google Analytics 4 |
ad_user_data |
Einwilligung, werbebezogene Nutzerdaten an Google zu senden | Google Ads |
ad_personalization |
Einwilligung in personalisierte Werbung und Remarketing | Google Ads |
functionality_storage |
Speicherung für Funktionen wie Spracheinstellung oder Layout | optional, je nach Setup |
personalization_storage |
Speicherung für personalisierte Inhalte, etwa Empfehlungen | optional, je nach Setup |
security_storage |
Speicherung für Sicherheit, etwa Betrugserkennung | in der Regel technisch notwendig |
Integrierte und zusätzliche Einwilligungsprüfungen
Der Tag Manager kennt zwei Ebenen. Google-Tags wie Analytics und Ads bringen eine integrierte Einwilligungsprüfung mit: Sie enthalten laut Google eine Logik, durch die sich die Funktionsweise des Tags auf Grundlage des Einwilligungsstatus ändert. Für diese Tags müssen Sie nichts zusätzlich konfigurieren.
Für alle anderen — den Meta-Pixel, ein LinkedIn-Tag, ein eigenes Skript — gibt es die zusätzliche Einwilligungsprüfung mit drei Einstellungen: „Keine Festlegung" als Voreinstellung, „Keine zusätzliche Einwilligung erforderlich" und „Zusätzliche Einwilligung zur Auslösung erforderlich". Nur die dritte Option hält ein Tag wirklich zurück, bis der genannte Parameter auf granted steht.
Genau hier liegt die häufigste Lücke, die wir in bestehenden Containern finden: Fremd-Tags stehen auf „Keine Festlegung" und feuern damit unabhängig vom Banner. Die Einwilligungsübersicht im Container macht das in einer Minute sichtbar — sie sortiert alle Tags in „nicht konfiguriert" und „konfiguriert" und erlaubt die Bearbeitung mehrerer Tags auf einmal. Diese Seite ist der erste Ort, an dem wir bei einer Bestandsanalyse nachsehen.
Einfacher oder erweiterter Einwilligungsmodus?
Zwei Betriebsarten stehen zur Wahl. Im einfachen Einwilligungsmodus bleiben die Google-Tags blockiert, bis der Nutzer mit dem Einwilligungsbanner interagiert hat. Ohne Zustimmung wird gar nichts gesendet; die Modellierung fehlender Conversions läuft dann über ein allgemeines Modell.
Im erweiterten Einwilligungsmodus laden die Tags beim Seitenaufruf, standardmäßig mit allen Parametern auf denied. Bei einer Ablehnung senden sie cookielose Signale samt Einwilligungsstatus an Google — daraus entsteht eine genauere, auf Ihr Konto zugeschnittene Modellierung. Die Datenqualität ist besser, die datenschutzrechtliche Bewertung dafür anspruchsvoller, weil bereits vor der Entscheidung eine Verbindung zu Google aufgebaut wird.
Unsere Empfehlung aus der Praxis: Diese Entscheidung fällt nicht der Tag Manager, sondern Ihre Rechtsberatung gemeinsam mit dem Marketing. Was das Banner davor leisten muss und welche Gestaltungsfehler Aufsichtsbehörden rügen, behandelt unser Beitrag Cookie-Banner richtig umsetzen — dort geht es um die Einwilligung selbst, hier nur darum, wie der Container sie technisch respektiert.
5. Vorschau und Debugging
Vor jeder Veröffentlichung steht die Vorschau. Sie starten sie im Arbeitsbereich über „In Vorschau ansehen", geben Ihre URL ein und verbinden sich. Ihre Website läuft dann so, als wäre der aktuelle Entwurf bereits live — sichtbar ausschließlich in Ihrem eigenen Browser. Reguläre Besucher merken davon nichts.
Die Debug-Oberfläche heißt Tag Assistant und zeigt, welche Tags in welcher Reihenfolge ausgelöst wurden und welche Daten dabei verarbeitet wurden. Wer häufiger damit arbeitet, installiert zusätzlich die Chrome-Erweiterung Tag Assistant Companion. Diese fünf Punkte prüfen wir bei jeder Abnahme:
- Feuert das richtige Tag? Der Tag Assistant trennt ausgelöste von nicht ausgelösten Tags. Steht Ihr Tag auf der falschen Seite, stimmt der Trigger nicht — nicht das Tag.
- Feuert es genau einmal? Doppelte Auslösungen sind der häufigste Grund für Conversion-Zahlen, die zu gut aussehen, um wahr zu sein.
- Kommen die Werte an? Öffnen Sie das Ereignis und sehen Sie nach, was in der Datenschicht steht. Ein leerer Bestellwert fällt hier auf und nicht erst im Monatsbericht.
- Verhält sich die Ablehnung richtig? Testen Sie beide Wege: einmal zustimmen, einmal ablehnen. Nach einer Ablehnung darf kein einwilligungspflichtiges Tag mehr auftauchen.
- Stimmt der Zielbericht? Kontrollieren Sie den Echtzeitbericht des Zielprodukts. Erst wenn das Ereignis dort ankommt, ist die Kette vollständig.
6. Versionen, Arbeitsbereiche und Rechte im Team
Änderungen entstehen in einem Arbeitsbereich und werden erst live, wenn Sie eine Version veröffentlichen. Eine Version ist laut Google eine Momentaufnahme der Konfiguration eines Containers. Genau darin liegt das beste Argument für den Tag Manager: Sie können jederzeit zu einer früheren Konfiguration zurückkehren. Ein fehlerhaftes Update ist über das Aktionsmenü einer älteren Version und „Als neueste Version festlegen" in Sekunden zurückgenommen.
Die Standardversion erlaubt bis zu drei Arbeitsbereiche gleichzeitig: einen Standardarbeitsbereich und zwei benutzerdefinierte. Für ein Team von zwei bis drei Personen reicht das gut aus. Nur Tag Manager 360 hebt die Grenze auf — dort gibt es zusätzlich einen Genehmigungs-Workflow, in dem eine Freigabe beantragt und bestätigt wird.
Auf Kontoebene unterscheidet Google zwischen Administrator und Nutzer. Interessanter ist die Containerebene mit ihren fünf Stufen — sie ist der Hebel, mit dem Sie verhindern, dass jemand versehentlich live schaltet:
| Berechtigung | Was sie erlaubt | Passt typischerweise für |
|---|---|---|
| Kein Zugriff | Der Container erscheint für diesen Nutzer gar nicht erst im Konto. | Externe, die nur einen von mehreren Containern brauchen |
| Lesen | Container, Tags, Trigger und Variablen ansehen, nichts ändern. | Geschäftsführung, Auditoren, neue Kolleginnen und Kollegen |
| Bearbeiten | Arbeitsbereiche anlegen und Änderungen vornehmen, aber keine Version erstellen. | Agenturen und Freelancer im laufenden Projekt |
| Freigeben | Zusätzlich Versionen erstellen — veröffentlichen jedoch nicht. | Erfahrene Umsetzende im Vier-Augen-Prinzip |
| Veröffentlichen | Uneingeschränkt Arbeitsbereiche und Versionen anlegen und live schalten. | Ein bis zwei Verantwortliche im Haus |
Der praktische Rat dazu ist unbequem, aber er erspart viel Sucherei: Vergeben Sie „Veröffentlichen" an höchstens zwei Personen. Agenturen und Freelancer arbeiten mit „Bearbeiten" völlig ausreichend; wer regelmäßig ausrollt, bekommt „Freigeben". So bleibt der Moment, in dem sich Ihre Messung ändert, nachvollziehbar — und Sie behalten die Hoheit über Ihre eigenen Daten, auch wenn ein Dienstleister wechselt.
7. Wann ein Container falsch ist — unsere eigene Entscheidung
Praktisch jede Anleitung im Netz behandelt den Tag Manager als gesetzt. Das liegt in der Natur der Quellen: Fünf der ersten Plätze bei Google gehören Google selbst, dahinter schreiben Anbieter, an deren Angebot der Container hängt. Wir halten die Frage trotzdem für berechtigt — und beantworten sie am eigenen Beispiel.
yagemi.de lief jahrelang über einen Tag-Manager-Container. Im Juni 2026 haben wir ihn beim Relaunch abgeschaltet und Google Analytics 4 direkt als gtag.js eingebunden. Nicht aus Prinzip, sondern weil drei Dinge zusammenkamen:
- Weniger JavaScript im kritischen Pfad. Mit Container lädt der Browser erst den Container und darin anschließend die Bibliothek des Zielprodukts. Ohne Container lädt er genau eine Bibliothek. Wir nennen dazu bewusst keine Millisekunden — wir haben keinen dokumentierten Vorher-Nachher-Messwert. Abzählbar bleibt aber: eine Anfrage und eine Abhängigkeitsstufe weniger, und die Ladewerte sind für uns eine harte Vorgabe.
- Weniger bewegliche Teile bei der Einwilligung. Unsere Skripte stehen als
type="text/plain"im Seiten-Template und werden von der Consent-Plattform freigeschaltet. Es gibt also genau eine Stelle, an der die Einwilligung wirkt. Mit Container gäbe es zwei Systeme, die dasselbe regeln — und jede Abweichung dazwischen ist ein Datenschutzrisiko, das niemand sieht. - Kein Vorteil bei Änderungen. Der stärkste Grund für den Container ist die Änderung ohne Entwickler. Bei uns läuft jede Änderung ohnehin über ein Deployment, und die Personen, die Tags ändern, haben Zugriff auf das Repository. Der Container hätte einen Weg abgekürzt, den wir gar nicht gehen.
Das ist ausdrücklich kein Argument gegen den Tag Manager. Es ist ein Argument dafür, die Frage überhaupt zu stellen. In den meisten Kundenprojekten fällt unsere Antwort andersherum aus — und zwar immer dann, wenn mindestens einer dieser Punkte zutrifft:
- Sie betreiben mehr als zwei oder drei Tags. Analytics, Google Ads, Meta, LinkedIn, ein Umfrage-Tool: Ab dieser Zahl ist eine Verwaltungsoberfläche jedem Sammelsurium aus Template-Schnipseln überlegen.
- Es ändert sich regelmäßig etwas. Neue Kampagnen, neue Conversions, ein Testlauf mit einem weiteren Kanal — jede dieser Änderungen wäre sonst ein Entwicklungsticket.
- Marketing und Entwicklung sind getrennt. Wenn das Marketing keinen Zugriff auf den Quelltext hat oder Releases nur alle paar Wochen laufen, ist der Container der einzige Weg, in Tagen statt Monaten zu messen.
- Sie brauchen Versionierung und ein Rollback. Der Rückweg zur letzten funktionierenden Konfiguration ist im Container ein Klick. Im Template ist er ein Deployment.
- Sie wollen die Einwilligung zentral prüfen. Die Einwilligungsübersicht zeigt für alle Tags auf einer Seite, was konfiguriert ist. Verteilte Skripte im Template müssen Sie einzeln durchsehen.
- Serverseitiges Tagging steht im Raum. Der Server-Container ist der natürliche nächste Schritt aus einem sauberen Web-Container heraus, nicht aus verstreuten Snippets.
Die ehrliche Faustregel: Der Container kostet ein wenig Ladezeit und eine zusätzliche Verwaltungsebene und zahlt das mit Tempo, Nachvollziehbarkeit und Übersicht zurück. Für einen Online-Shop mit aktivem Marketing lohnt sich dieser Tausch fast immer. Für eine Website mit einem einzigen Messwerkzeug und einem Entwicklungsteam, das ohnehin jede Woche ausrollt, lohnt er sich möglicherweise nicht.
Aus der Beratung: Die falsche Frage lautet „Container oder nicht?". Die richtige lautet „Wie viele Tags werden wir in zwölf Monaten haben, und wer wird sie ändern?". Antworten Sie darauf mit „mehr als drei" und „nicht die Entwicklung", ist die Entscheidung getroffen.
8. Fünf Fehler, die wir immer wieder sehen
Diese fünf Muster begegnen uns bei fast jeder Bestandsanalyse eines gewachsenen Containers. Keines davon ist schwer zu vermeiden — aber jedes kostet Daten, wenn es unentdeckt bleibt.
- Der Container läuft, die Einwilligung nicht. Jedes Tag steht in der Einwilligungsübersicht auf „Keine Festlegung", und niemand hat je hineingeschaut. Der Container feuert dann genau so, wie ihn jemand gebaut hat — und nicht so, wie es das Banner verspricht.
- Tags hängen am HTML statt an der Datenschicht. Trigger, die auf eine CSS-Klasse oder einen Button-Text hören, überleben kein Theme-Update. Wer den Bestellwert aus der Bestätigungsseite ausliest, misst nach dem nächsten Relaunch nichts mehr. Ereignisse gehören in die Datenschicht.
- Alte Skripte bleiben im Template stehen. Nach der Migration in den Container liegt dasselbe Analytics-Snippet zweimal auf der Seite. Die Folge sind doppelte Seitenaufrufe und Conversion-Zahlen, denen niemand mehr traut. Prüfen Sie den Quelltext nach der Umstellung Zeile für Zeile.
- Veröffentlicht wird ohne Vorschau. Die Vorschau kostet zwei Minuten und zeigt genau, welches Tag ausgelöst wurde und welches nicht. Ohne sie merken Sie einen Fehler erst, wenn eine Woche Daten fehlt — und die holen Sie nicht zurück.
- Alle im Team haben „Veröffentlichen". Wenn fünf Personen live schalten dürfen, erklärt am Ende niemand, warum eine Conversion seit Dienstag doppelt zählt. Ein bis zwei Verantwortliche mit Veröffentlichungsrecht, alle anderen auf „Bearbeiten" — das reicht in fast jedem Mittelstandsteam.
Auffällig ist, was die Liste nicht enthält: technisch anspruchsvolle Probleme. Tracking-Setups scheitern selten an der Technik und fast immer an fehlender Zuständigkeit. Wer im Haus benennt, wer den Container pflegt, hat den größten Teil der Arbeit erledigt. Und weil verlässliche Zahlen erst dann etwas wert sind, wenn jemand etwas mit ihnen anfängt, lohnt danach der Blick darauf, wie Sie Ihre Conversion Rate systematisch verbessern.
9. Fazit: erst die Frage, dann der Container
Der Google Tag Manager ist gut gebaut, kostenlos und für die meisten Websites mit aktivem Marketing die richtige Wahl. Das Einrichten selbst ist an einem Nachmittag erledigt: Container anlegen, beide Code-Blöcke an die vorgeschriebenen Stellen setzen, Datenschicht initialisieren, Einwilligung vor dem ersten Tag klären, in der Vorschau prüfen, veröffentlichen. Die Arbeit steckt danach — in der Datenschicht, in der Einwilligungsübersicht und in der Frage, wer veröffentlichen darf.
Sie möchten wissen, ob Ihr bestehendes Setup wirklich das misst, was Sie glauben — oder ob ein Container in Ihrem Fall überhaupt der richtige Weg ist? Wir sehen uns Container, Google Analytics 4 und Ihre Einwilligungslogik gemeinsam an und sagen Ihnen, wo Daten verloren gehen. Wenn Werbeplattformen dabei eine große Rolle spielen, ist serverseitiges Tracking mit Stape der nächste Schritt, den wir mit Ihnen ehrlich durchrechnen.
Hinweis: Dieser Beitrag ist allgemeine Information und ersetzt keine Rechtsberatung. Die Angaben zur Oberfläche und zum Einwilligungsmodus des Google Tag Managers entsprechen der Google-Dokumentation mit Stand August 2026 und können sich durch Produktänderungen verschieben. Ob und in welcher Form eine Einwilligung in Ihrem Fall erforderlich ist, klären Sie bitte mit Ihrer Rechtsberatung.
10. Häufige Fragen zum Google Tag Manager
Für was ist der Google Tag Manager?
Der Tag Manager verwaltet die Mess- und Marketing-Skripte Ihrer Website an einer zentralen Stelle. Statt jedes Skript einzeln in den Quelltext zu schreiben, binden Sie einmal einen Container ein. Darin legen Sie fest, welches Tag bei welchem Ereignis feuert. Änderungen laufen danach ohne Eingriff in den Code Ihrer Website.
Ist Google Tag Manager kostenlos?
Ja. Die Standardversion ist kostenlos und ohne Begrenzung der Tag-Zahl nutzbar; Sie brauchen lediglich ein Google-Konto. Kostenpflichtig ist allein Tag Manager 360 aus der Google Marketing Platform, das unbegrenzte Arbeitsbereiche, einen Genehmigungs-Workflow und Enterprise-Support bietet. Einen Listenpreis dafür veröffentlicht Google nicht.
Wie komme ich zum Google Tag Manager?
Über tagmanager.google.com mit Ihrem bestehenden Google-Konto. Nutzen Sie dasselbe Konto, mit dem Sie Analytics und Google Ads verwalten — das erspart Ihnen später doppelte Freigaben. Nach der ersten Anmeldung legen Sie ein Konto für Ihr Unternehmen an und darin einen Container je Website oder App.
Wie richte ich ein Google-Tag ein?
Im Container wählen Sie „Neues Tag", entscheiden sich für einen Tag-Typ, tragen die Ziel-ID ein und weisen dem Tag mindestens einen Trigger zu. Ohne Trigger feuert nichts. Anschließend prüfen Sie das Tag im Vorschaumodus und veröffentlichen erst danach eine neue Version des Containers.
Wie funktioniert ein Google-Tag?
Ein Tag ist ein Stück Code, das der Container erst ausführt, wenn eine hinterlegte Bedingung eintritt. Der Trigger liefert diese Bedingung, Variablen liefern die einzelnen Werte, die Datenschicht liefert die Daten aus Ihrer Website. Das Tag verpackt beides und sendet es an den jeweiligen Zieldienst.
Wo finde ich den Google-Tag?
Die Mess-ID Ihres Google-Tags steht im Zielprodukt: in Google Analytics 4 unter „Verwaltung" beim jeweiligen Datenstream im Format G-XXXXXXXXXX, in Google Ads bei den Conversion-Einstellungen. Die Container-ID des Tag Managers selbst finden Sie im Format GTM-XXXXXXX oben rechts neben dem Namen des Containers.
Ist Google Tag Manager einwilligungspflichtig?
Einwilligungspflichtig ist nach § 25 TDDDG jedes Tag, das Informationen auf dem Endgerät speichert oder ausliest — also Analytics-, Ads- und Pixel-Tags. Ob der Container-Code selbst darunterfällt, ist rechtlich nicht abschließend geklärt; eigene Cookies setzt er nicht. Lassen Sie diesen Punkt für Ihren Fall anwaltlich prüfen.
11. Quellen & offizielle Dokumentation
Alle Produktangaben in diesem Beitrag stammen aus der offiziellen Google-Dokumentation und wurden im August 2026 geprüft. Externe Quellen öffnen in einem neuen Tab.
- Tag-Manager-Hilfe — Übersicht — Definitionen von Konto, Container, Tag, Trigger und Variable.
- Google for Developers — Datenschicht — Definition, Initialisierung und Übergabe von Werten per
push(). - Tag-Manager-Hilfe — Webcontainer installieren — vorgeschriebene Platzierung der beiden Code-Blöcke und asynchrones Laden.
- Tag-Manager-Hilfe — Einwilligungsmodus — integrierte und zusätzliche Einwilligungsprüfungen sowie die Einwilligungsübersicht.
- Google for Developers — Einwilligung konfigurieren — die Einwilligungsparameter und ihre Bedeutung.
- Google for Developers — Einwilligungsmodus im Detail — Unterschied zwischen einfachem und erweitertem Modus sowie die Modellierung.
- Tag-Manager-Hilfe — Vorschau- und Debug-Modus — Tag Assistant und die Debug-Oberfläche.
- Tag-Manager-Hilfe — Nutzer und Berechtigungen — die Stufen auf Konto- und Containerebene.
- Tag-Manager-Hilfe — Veröffentlichen, Versionen und Freigaben — Versionen als Momentaufnahme und der Weg zurück.
- Tag-Manager-Hilfe — Arbeitsbereiche — drei Arbeitsbereiche in der Standardversion, unbegrenzt in Tag Manager 360.
- Gesetze im Internet — § 25 TDDDG — Einwilligung für das Speichern und Auslesen von Informationen auf Endgeräten (Primärquelle).