01 — Ansatz
Ordnung ist keine Geschmacksfrage
Wir bauen Tracking-Setups, seit es Google Analytics gibt, und GTM-Container seit deren Anfangstagen. In dieser Zeit haben wir vor allem eines gelernt: Ein Container verrottet nicht durch böse Absicht, sondern durch hundert kleine Schnellschüsse. Ein Tag für die Kampagne, ein Trigger als Kopie, ein Test, der nie zurückgebaut wurde.
Deshalb behandeln wir den GTM wie Code. Namenskonventionen, ein Zweck pro Tag, keine Duplikate, jede Version mit aussagekräftiger Beschreibung. Das ist keine Pedanterie, sondern der Unterschied zwischen einer Änderung in zehn Minuten und einem Nachmittag Archäologie.
02 — Aktuell
Was sich beim GTM gerade ändert
2026 baut Google den Tag Manager so tief um wie seit Jahren nicht: GTM-Container wachsen mit dem Google Tag zusammen. Auf der Google Marketing Live im Mai vorgestellt, rollt der neue Aufbau seit Ende Juni schrittweise aus. Statt separater Tags für GA4, Google Ads und Floodlight gibt es künftig Destinations in einem gemeinsamen Modell, dazu zentrale Einstellungen etwa für Cross-Domain-Tracking und User-Provided Data an einem Ort. Ein visueller Event-Builder ist für Google Ads in der Beta, und Server-Side Tagging wird stärker zum Standardfall.
Das ist bequem, verschiebt aber auch Verantwortung: Zentrale Einstellungen wirken auf mehrere Produkte gleichzeitig, und wer sie durchklickt, ohne sie zu verstehen, ändert sein Tracking an drei Stellen auf einmal. Die Details und unsere Einordnung dazu stehen im Blog-Artikel zum GTM-Update 2026.
Unsere Empfehlung: Die Umstellung nicht einfach abnicken, sondern als Anlass für einen Container-Frühjahrsputz nutzen. Wer jetzt aufräumt, migriert einen sauberen Container statt eines Museums.
03 — Fundament
DataLayer-Architektur
Der DataLayer ist das Fundament, auf dem jeder Tag steht. Wir definieren ein Schema, bevor die erste Zeile implementiert wird: welche Events, welche Parameter, welche Datentypen, wer sie pusht und wann. Das Schema bekommt euer Entwicklungsteam als Spezifikation, die Umsetzung begleiten wir oder übernehmen sie gleich mit, gemeinsam mit unserer Webtechnik. So misst der Container Daten aus einer verlässlichen Quelle statt aus zusammengeklickten DOM-Selektoren, die beim nächsten Redesign brechen.
04 — Praxis
Container-Audit und Cleanup bei Übernahme
Die meisten Container, die wir übernehmen, sind Museen: verwaiste Tags, Trigger in dreifacher Ausführung, und niemand weiß mehr, was Tag 47 eigentlich macht oder warum er nur dienstags feuert. Unser Audit inventarisiert jeden Tag, Trigger und jede Variable, prüft, was noch feuert und was nur Ballast ist, und dokumentiert das Ergebnis. Danach räumen wir in Etappen auf, jede Änderung als eigene Version, damit jederzeit ein Rollback möglich ist.
Ein Tag, den niemand mehr versteht, ist kein Tracking. Er ist ein Risiko mit Versionsnummer.
Wenn ihr wissen wollt, wie es um euren Container steht: Wir machen den Audit-Durchgang als kostenlosen Erst-Check und sagen euch ehrlich, ob ein Cleanup nötig ist oder nur ein paar Handgriffe. Meldet euch kurz.
05 — Disziplin
Web-Container und Server-Container
Web- und Server-Container haben unterschiedliche Jobs: Der Web-Container sammelt Events im Browser, der Server-Container verarbeitet sie first-party weiter, reichert sie an und verteilt sie kontrolliert an GA4, Meta und Co. Wir bauen beide so, dass sie sich die Arbeit sinnvoll teilen, mit einem gemeinsamen Event-Schema statt doppelter Logik. Die Grundsatzfragen dazu, Hosting, Kosten und wann sich der Schritt lohnt, behandelt die Seite zum Server-Side Tracking.
06 — Disziplin
Trigger-Logik ohne Überraschungen
Trigger sind die Stelle, an der Container am liebsten kaputtgehen: zu breite Klick-Trigger, die auf jedem Button feuern, Regex-Konstrukte, die niemand mehr entziffert, Ausnahmen von Ausnahmen. Wir halten Trigger-Logik flach und vorhersehbar. Ein Trigger reagiert auf ein DataLayer-Event, nicht auf CSS-Klassen, und Consent-Bedingungen sind eingebaut statt angeflickt. Wie die Consent-Signale sauber vor den Tags ankommen, zeigt die Seite zum Consent Mode v2.
07 — Prozess
Versionierung, Freigabe und Dokumentation
Jede Änderung durchläuft bei uns denselben Weg: Workspace anlegen, im Preview-Modus testen, Version mit Beschreibung veröffentlichen. Bei größeren Setups trennen wir Rollen, sodass Bearbeiten und Veröffentlichen nicht in derselben Hand liegen müssen. Und wir dokumentieren den Container so, dass euer Team ihn versteht: Was misst welches Event, wo kommt es her, wer darf was ändern. Auf welche Zahlen das alles einzahlt, steht auf unserer Übersicht zu Tracking & Analytics. Die Event-Definitionen selbst entstehen im Messplan zusammen mit GA4.
Wie viele Tags in eurem Container kennt ihr noch?
Schreib uns kurz, wie alt euer Container ist und wer ihn zuletzt gepflegt hat. Wir schauen rein und sagen ehrlich, ob er einen Cleanup braucht. Erstgespräch unverbindlich, 30 Minuten.