Zusammenlegung von Google Tag und Tag Manager: Destinations, gtm-init-Trigger und was die Lade-ID entscheidet

Der Google-Tag und der Tag Manager waren zehn Jahre lang zwei Wege, dasselbe zu tun. Seit dem Frühjahr 2026 führt Google sie zusammen: Bestehende Google-Tags werden zu vollwertigen Tag-Manager-Containern, und die Google-Produkte, an die ein Container sendet, heißen fortan Ziele.

Die Umstellung ist freiwillig, sie ändert nichts von allein, und der Nutzen ist eher unspektakulär. Bemerkenswert ist ein anderer Satz – der aus den Anmerkungen vom 9. Juli 2026, in dem steht, dass künftig die Kennung darüber entscheidet, was ein Container überhaupt darf.

Was ein Ziel ist

Bisher lud ein Container für jedes Google-Produkt eine eigene Bibliothek nach: einmal gtag/js für die Messkennung, einmal für das Anzeigenkonto, gegebenenfalls ein weiteres Mal für Floodlight. Nach der Umstellung sind diese Produkte Ziele am Container, und die Auslieferung übernimmt die Containerdatei selbst. Googles Beschreibung hält fest, dass jedes Google-Ziel weiterhin ein eigenes Tag bekommt – zusammengelegt wird die Auslieferung, nicht die Konfiguration.

Der Gewinn liegt deshalb nicht in der Dateigröße. Ein Container, der drei Ziele bedient, ist größer als einer, der keines bedient. Was entfällt, ist eine Runde im Ladeverlauf: Das Dokument findet den Container, der Container findet die Bibliothek, die Bibliothek meldet den ersten Treffer. Fällt die mittlere Stufe weg, verschiebt sich alles Nachfolgende nach vorn.

Die Kennung entscheidet, nicht der Pfad

Am 9. Juli 2026 hat Google eine Anmerkung zum Verhalten von Containern bei nicht unterstützten Installationswegen veröffentlicht. Der entscheidende Satz lautet, dass die zum Laden verwendete Kennung dieses Verhalten steuert, unabhängig vom benutzten Pfad. Ein mit GTM-… geladener Container arbeitet wie gewohnt. Ein mit einer Produktkennung wie G-… oder AW-… geladener Container ist auf von Google gelieferte Tags und Variablen beschränkt.

Das ist die Stelle, an der ein Aufbau unbemerkt schmaler werden kann. Wer einen bestehenden Google-Tag aufwertet und den alten Schnipsel mit der Messkennung stehen lässt, hat anschließend einen vollwertigen Container in der Oberfläche und eine eingeschränkte Ausführung auf der Seite. Eigene HTML-Tags, fremde Anbieter und selbstgeschriebene Variablen fehlen dann – nicht, weil sie gelöscht wären, sondern weil die Kennung im Quelltext sie nicht zulässt.

Was aus dem config-Befehl wird

Neue Auslieferungsschnipsel sind künftig einheitlich und enthalten den Befehl gtag('config', …) nicht mehr. An seine Stelle tritt ein Auslöser namens gtm init, über den sich das Verhalten beim Start einstellen lässt. Für Bestandsaufbauten ist vorgesehen, dass dieser Auslöser auf den alten Befehl warten kann, damit eine vorhandene Reihenfolge erhalten bleibt.

Was aus dem Schnipsel verschwindet

  gtag('js', new Date());
  gtag('config', 'G-XXXXXXX');    <- im neuen Schnipsel nicht mehr enthalten

Was an seine Stelle tritt

  Auslöser "gtm init" im Container
    steuert, wann initialisiert wird
    kann auf den alten config-Befehl warten, wenn ein
    bestehender Aufbau ihn weiterhin sendet

Was die Kennung steuert (Anmerkung vom 9. Juli 2026)

  geladen mit GTM-…   voller Funktionsumfang
  geladen mit G-…     nur von Google gelieferte Tags und Variablen
  geladen mit AW-…    nur von Google gelieferte Tags und Variablen

Wo eine Einwilligungslösung heute den config-Befehl zurückhält oder umsortiert, ist genau das die Stelle, die vor einer Umstellung nachgesehen werden muss. Der Auslöser kann dieselbe Reihenfolge herstellen, aber er tut es nicht von allein.

Was freiwillig hier bedeutet

Googles Seite sagt es deutlich: Es werden keine Änderungen automatisch vorgenommen, und die Übernahme der neuen Einrichtung bleibt eine Entscheidung. Bestehende Container, Tags, Auslöser und Variablen arbeiten unverändert weiter, und Tags fremder Anbieter bleiben vollständig unterstützt.

Freiwillig heißt allerdings nicht folgenlos. Neue Schnipsel sehen anders aus als alte, und wer im selben Haus zwei Auftritte betreut, betreut ab jetzt womöglich zwei verschiedene Einbauarten. Die Anleitung, die im Wiki steht, gilt dann für den einen Auftritt und nicht mehr für den anderen.

Was sich vorher zählen lässt

Der Nutzen einer Umstellung ist am eigenen Auftritt in wenigen Minuten zu ermitteln, und zwar bevor irgendetwas geändert wird. Im Netzwerkfenster des Browsers, gefiltert auf googletagmanager.com, zeigt sich, wie viele Bibliotheken tatsächlich geladen werden. Ein einzelner Container mit einer Messkennung lädt oft nur zwei Dateien; dort ist wenig zu holen. Ein gewachsener Aufbau mit Anzeigenkonto, Floodlight und einem separat eingebauten Google-Tag lädt vier oder fünf, und dort lohnt sich das Nachrechnen.

Die zweite Zahl steht in der Oberfläche: wie viele Tags eigener Bauart im Container liegen. Sie entscheidet, wie schmerzhaft eine falsche Kennung im Quelltext wäre.

Wofür sich Abwarten anbietet

Die Umstellung ist neu, sie ist freiwillig, und ihr Gewinn ist eine Runde im Ladeverlauf. Das rechtfertigt keinen Eingriff an einem Aufbau, der trägt – wohl aber eine Vorschau auf einem nebensächlichen Auftritt, um den neuen Schnipsel, den Auslöser und die Ausführung einmal gesehen zu haben, bevor die Entscheidung ansteht.

Was sich dagegen sofort lohnt, ist der Blick auf die Kennung im Quelltext. Sie steht heute schon dort, sie steuert ab dem 9. Juli 2026 mehr als vorher, und sie ist die einzige Stelle in dieser ganzen Umstellung, an der ein stiller Funktionsverlust möglich ist.

Was der Container schon mitbrachte: Einstellungsvariablen

Die Zusammenlegung baut auf einem früheren Schritt auf. Im September 2023 ersetzte der Google-Tag im Tag Manager das GA4-Konfigurations-Tag; bestehende Konfigurations-Tags wurden automatisch umgestellt, und zwei Variablentypen übernahmen die Aufgabe, die zuvor „Fields to Set“ in jedem einzelnen Tag erledigt hatte.

• Google tag: Configuration settings enthält Parameter, die beim Laden des Google-Tags gesetzt werden. Googles eigenes Beispiel ist ein Parameter language für eine Website, die in mehreren Sprachen erscheint.
• Google tag: Event settings enthält Parameter auf Ereignisebene. Am Google-Tag gehen sie mit jedem Ereignis mit, an einem GA4-Ereignis-Tag nur mit dessen Ereignissen.

Was ein Tag geerbt hat, zeigt es unter „Show inherited settings“. Ein geerbter Wert lässt sich für ein einzelnes Tag bearbeiten und mit „Reset“ wieder auf den Wert der Variablen zurücksetzen.

Vor einer Umstellung ist ein Container leichter zu überblicken, wenn gemeinsame Parameter in diesen Variablen stehen statt in jedem Tag einzeln. Die lokalen Überschreibungen sind dann die Ausnahmen, die auf eine Liste gehören, denn ein in einem Tag geänderter Wert folgt der Variablen nicht mehr. Diese Liste gehört neben den Blick auf die Kennung im Quelltext.