Google Tag Manager und gtag.js verschmelzen: Was sich 2026 ändert

Google führt den Google-Tag und den Google Tag Manager zusammen. Aus zwei bisher getrennten Wegen zur Messung entsteht eine gemeinsame technische Grundlage. Für bestehende GTM-Installationen ist vor allem eine Neuerung interessant: Ein optimierter Container kann Daten direkt an Google-Ziele senden, ohne dafür zusätzlich gtag.js nachzuladen. Für bisher reine Google-Tag-Installationen kündigt Google die Verwaltungsfunktionen des Tag Managers an. [1][2]

Der Begriff „Merge“ trifft die Richtung, verdeckt aber die entscheidenden Unterschiede. Die freiwillige Containeroptimierung, die Kennung im Ladeschnipsel und das geänderte Verhalten von gtag('config', …) sind drei getrennte Themen. Gerade die letzte Änderung kann auch ohne freiwillige Optimierung bestehende Trigger treffen. Dieser Artikel ordnet den Stand vom 19. Oktober 2026 ein und beschreibt eine kontrollierte Umstellung.

Was im Oktober tatsächlich neu ist

Die Zusammenführung wurde bereits vor den Oktoberänderungen beschrieben. Googles aktuelle Übersichtsankündigung trägt das Datum 20. August 2026. Der frühere Beitrag zur Zusammenlegung und zur Lade-ID behandelt die Grundlage. Die jüngsten Release Notes konkretisieren nun zwei betriebliche Änderungen. [1][2]

• 8. Oktober: GTM-Schnipsel mit gtm.js initialisieren den Container beim Laden unabhängig von config-Befehlen. Solche Befehle werden als sichtbare gtag.config-Ereignisse im dataLayer dargestellt; weit gefasste Custom-Event-Trigger können darauf reagieren.
• 12. Oktober: Google dokumentiert die optimierten Container mit direktem Versand an Google-Messprodukte. Einstellungen und Zugriffsverwaltung werden im Container zusammengeführt.

Die Dokumentation verwendet gleichzeitig Gegenwarts- und Zukunftsformulierungen. Daraus ergibt sich kein belegter Stichtag, zu dem jede Property weltweit bereits vollständig umgestellt wäre. Maßgeblich für die konkrete Migration sind das Angebot im jeweiligen Container und die dort angezeigten Änderungen. Ein fehlendes Upgrade-Banner ist kein Anlass, eine neue Installation durch selbst kombinierte Schnipsel zu erzwingen. [1][3]

Google-Tag, gtag.js, GTM und Ziel: vier Begriffe

gtag.js bezeichnet die JavaScript-Bibliothek hinter dem bisherigen Google-Tag. Die Funktion gtag() legt Befehle in einer Warteschlange ab; ein Funktionsaufruf allein ist deshalb noch kein Nachweis für einen versendeten Messwert. Der Google-Tag umfasst die zugehörige Konfiguration. GTM verwaltet Tags, Trigger, Variablen, Arbeitsbereiche und veröffentlichte Versionen. Die Zusammenführung bringt diese Ebenen enger zusammen. [1][9]

Ein Ziel, englisch Destination, ist der angeschlossene Empfänger im Google-Messsystem. Google nennt vier Typen: GA4-Webdatenstrom, Google-Ads-Konto, Floodlight-Konfiguration und Merchant-Center-Conversion-Quelle. Ein Destination-Tag verbindet ein solches Ziel mit dem Container; Parameter am einzelnen Destination-Tag können gemeinsame Einstellungen überschreiben. [4]

Eine gemeinsame Verwaltung ist deshalb keine Zusammenlegung von GA4-Properties oder Anzeigenkonten. Ein Kaufereignis bleibt fachlich zu definieren, ein Ziel bleibt gezielt auszuwählen, und zwei Empfänger erzeugen weiterhin zwei getrennt zu prüfende Datenwege.

Was die Containeroptimierung verändert

Im bisherigen Ablauf konnte GTM für Google-Ziele zusätzlich gtag.js laden. Die Optimierung verlagert den Versand in den Container und führt die Google-Tag-Einstellungen im Bereich Settings zusammen. Bereits konfigurierte Event-Tags und Trigger bleiben laut Google erhalten. Die gemeinsame Übersicht zeigt Ziele und Datenfluss. [2][3]

Bei übereinstimmenden Einstellungen führt der Assistent über Review details zur Prüfung. Bei abweichenden Einstellungen mehrerer Google-Tags erscheint ein Ablauf über Get started, in dem die zusammenzuführende Konfiguration ausgewählt wird. Eine solche Auswahl verdient eine fachliche Prüfung: Ein gemeinsamer Standard darf keine bisher absichtlich unterschiedliche Zielkonfiguration verdecken. [3]

Die neue Oberfläche verschiebt Trigger, Variablen, Vorlagen und Ordner in den aufklappbaren Bereich Advanced. Diese Funktionen werden durch die Umgestaltung nicht abgeschafft. Der einfachere Einstieg macht die Ereignisdefinition im Hintergrund auch nicht entbehrlich. [1]

Warum weniger Nachladen helfen kann

Eine zusätzliche Bibliothek muss entdeckt, angefordert und ausgeführt werden, bevor der davon abhängige Versand beginnen kann. Entfällt diese Stufe, kann sich der erste Messversand beschleunigen. Google nennt bessere Websiteleistung und Datenerfassung als Vorteile. Die herangezogenen Quellen liefern dafür jedoch weder einen allgemein gültigen Prozentwert noch eine garantierte Einsparung in Millisekunden. [2][3]

Die Wirkung hängt vom konkreten Aufbau ab: Cachezustand, Netzverbindung, Containerumfang, andere Skripte, Einwilligungsablauf und Zeitpunkt des Ereignisses beeinflussen das Ergebnis. Ein früherer Messrequest beweist noch keine Verbesserung des sichtbaren Seitenaufbaus. Für einen belastbaren Vergleich braucht es denselben Seitenzustand und mehrere Läufe mit kaltem sowie warmem Cache.

Auch nach der Optimierung bleibt eine Netzwerkkontrolle nötig. Das fehlende Nachladen von gtag.js kann zum erwarteten Ergebnis gehören. Entscheidend ist dann, ob die vorgesehenen Ereignisse beim richtigen Ziel ankommen. Umgekehrt rechtfertigt eine noch sichtbare gtag.js-Anfrage keine pauschale Löschung: Weitere Einbindungen, Plugins oder separate Konfigurationen können weiterhin beteiligt sein.

Die Lade-ID bleibt eine Funktionsgrenze

Google knüpft die ausführbaren Funktionen an die Kennung, mit der der Container geladen wird. GTM-… erlaubt alle konfigurierten Tag-Typen, einschließlich Drittanbietern und Custom HTML. Produktkennungen wie G-… und AW-… beschränken die Ausführung auf Google-Tags. Der bloße Austausch des URL-Pfads ersetzt diese Entscheidung nicht. [5]

Eine Oberfläche mit mehr Verwaltungsfunktionen bedeutet daher nicht automatisch, dass eine mit G- oder AW-Kennung geladene Installation fremde Tags ausführt. Für die Bestandsaufnahme gehören sowohl das tatsächliche Ladesnippet im ausgelieferten HTML als auch die Konfiguration im Konto auf dieselbe Prüfliste. Eine neue GTM-Kennung entsteht nicht durch das Umschreiben eines Präfixes; gültige Kennungen stammen aus der jeweiligen Google-Verwaltung.

gtag.config: ein kleines Ereignis mit großer Reichweite

Die Änderung vom 8. Oktober ist von der freiwilligen Optimierung zu trennen. Ein GTM-Schnipsel wartet nicht mehr auf einen config-Befehl, um den Container zu initialisieren. Gleichzeitig kann ein solcher Befehl als gtag.config im Ereignisstrom erscheinen. Google warnt ausdrücklich vor Custom-Event-Triggern mit Wildcards. [2]

Ein regulärer Ausdruck wie .* akzeptiert auch diesen Namen. Übernimmt ein generisches Weiterleitungs-Tag jeden gefundenen Ereignisnamen, kann dadurch ein technisches Konfigurationsereignis beim nachgelagerten Empfänger landen. Das ist eine mögliche Folge eines solchen Aufbaus, kein Beleg dafür, dass jede Installation zusätzliche Käufe zählt.

Die saubere Grenze liegt zwischen fachlichen Ereignissen und technischen Meldungen. Eine explizite Auswahl zulässiger Ereignisse ist leichter zu prüfen als eine pauschale Weiterleitung. Das folgende Muster illustriert nur diese Auswahl für drei Ereignisnamen; es ist kein vollständiges Trackingkonzept und keine Google-Vorgabe:

^(view_item|add_to_cart|purchase)$

Ein bestehender Trigger darf erst nach Abgleich aller beabsichtigten Ereignisse eingeschränkt werden. Sonst verschwinden berechtigte Messungen zusammen mit dem unerwünschten Ereignis. Ebenso wenig sollte gtag.config ungeprüft in page_view umbenannt werden.

Warum alte config-Zeilen nicht blind entfernt werden dürfen

Die Ankündigung beschreibt neue einheitliche Auslieferungsschnipsel ohne config-Befehl und eine Initialisierung über den von Google als gtm init bezeichneten Trigger. Dieser Start ist vom gesonderten Consent-Initialization-Ablauf zu unterscheiden. Gleichzeitig bleibt gtag('config', …) Bestandteil der dokumentierten gtag.js-Installation. Google verlangt für Aufbauten, die weiterhin auf diesen Befehl angewiesen sind, einen passenden Google-Tag-Schnipsel. Eine Aussage über neue Snippets ist deshalb keine Löschanweisung für jeden bestehenden config-Aufruf. [1][6]

Die Installationshilfe behandelt insbesondere Mischformen aus GTM-Schnipsel und lose angehängter Konfiguration. Bei einem echten GTM-Aufbau mit Drittanbieter-Tags bleibt der GTM-Schnipsel erhalten; Google-Konfiguration und notwendige Parameter werden in GTM gepflegt. Bei einer reinen gtag.js-Installation gehört der vollständige, dafür vorgesehene Schnipsel auf die Seite. Ein zusätzlich eingebautes zweites System ohne Bestandsprüfung schafft dagegen weitere mögliche Doppelungen. [6]

Automatische Seitenaufrufe und doppelte Ereignisse

Googles Definition hält fest, dass das Hinzufügen eines Destination-Tags automatisch ein Seitenaufrufereignis für dieses Ziel sendet. Das ist besonders bei Single-Page-Anwendungen und bereits selbst gesteuerten Seitenaufrufen relevant. Die vorhandene Konfiguration muss zeigen, welcher Mechanismus für den ersten Seitenaufruf und welcher für Routenwechsel verantwortlich ist. [4]

Für die Prüfung zählt der tatsächliche Versand: Ereignisname, Zielkennung, Seitenadresse und bei Käufen die Transaktionskennung. Zwei erfolgreiche Tag-Auslösungen im Vorschaumodus sind noch kein Beweis für zwei korrekte Käufe. Ein einzelner erfolgreicher Browserrequest beweist umgekehrt nicht, dass keine zweite Quelle im CMS oder Plugin denselben Kauf sendet.

Berechtigungen: Der Rollback hat eine Grenze

Die Optimierung verknüpft den Container mit angeschlossenen Google-Produktkonten. Google beschreibt dabei standardmäßig Lesezugriff sowie eine nachträgliche Verwaltung der Verknüpfungen. Das betrifft die Sichtbarkeit und Zusammenarbeit über Produktgrenzen hinweg. [1]

Besonders relevant für Agenturen: Berechtigungen werden nicht versioniert. Ein Rollback auf eine frühere Containerversion setzt solche Zugriffsänderungen nicht automatisch zurück. Der Migrationsnachweis sollte deshalb neben dem Containerexport auch die vorherigen Kontoverknüpfungen und Zugriffsrechte enthalten. Nach der Umstellung gehört External Account Links in die Kontrolle. [3]

Einwilligung und serverseitiges Tagging bleiben eigene Prüfungen

Die Zusammenführung ersetzt weder eine CMP noch die Übermittlung von Einwilligungszuständen. Bei Basic Consent Mode bleiben Google-Tags bis zur passenden Freigabe blockiert. Advanced Consent Mode kann bei verweigerter Einwilligung Messungen ohne Cookies senden. Weniger JavaScript bedeutet daher nicht automatisch weniger Datenübertragung; denied ist nicht gleichbedeutend mit vollständiger Netzwerksperre. [7]

In GTM gehört das Setzen der Standardzustände in den vorgesehenen Consent-Initialization-Ablauf. Google empfiehlt dafür Template-APIs; ein Custom-HTML-Tag mit einem eingereihten gtag-consent-Aufruf ist kein gleichwertiger Ersatz. Die Prüfung umfasst die Zustände vor einer Auswahl, nach Zustimmung, nach Ablehnung und nach einem Widerruf. [8]

Auch ein serverseitiger Container entsteht durch die Zusammenführung nicht von selbst. Googles serverseitige Architektur setzt weiterhin einen eigenen Servercontainer voraus. Bei vorhandener Serveranbindung müssen der tatsächliche Requestweg und die übermittelten Consent-Signale erhalten bleiben. Der direkte Versand aus einem optimierten Webcontainer ist kein Nachweis für eine Migration auf serverseitiges Tracking. [10]

Visual Tagging: leichterer Einstieg mit klaren Grenzen

Zur gemeinsamen Plattform gehört auch Visual Tagging in Tag Assistant. Der geführte Ablauf ermittelt Informationen anhand ausgewählter Elemente auf einer Bestellbestätigungsseite und richtet Tags, Trigger und Variablen im Hintergrund ein. Die Übersichtsankündigung beschreibt den Funktionsumfang als Beta für Kauf-Conversions in Google Ads; weitere Anwendungsfälle sollen schrittweise folgen. Das ist kein belegter Universalersatz für jede bestehende dataLayer-Integration. [1][11]

Die Detailanleitung setzt unter anderem eine Bestellbestätigungsseite, einen websiteweit eingebundenen Google-Tag und Bearbeitungsrechte voraus. Werte wie Transaktionskennung, Bestellsumme und Währung werden im Ablauf zugeordnet. Google warnt außerdem vor einer möglichen Doppelzählung, wenn bereits eine Kauf-Conversion eingerichtet ist. Ein komfortabler Assistent ersetzt deshalb weder einen kontrollierten Testkauf noch die Prüfung, ob eine veränderte Seitengestaltung die erkannten Elemente beeinflusst. [11]

Eine kontrollierte Umstellung in sieben Schritten

Für die Bestandsaufnahme eignet sich der GTM-Containerverlauf mit Tiefensuche. Das Werkzeug durchsucht gespeicherte Container-Versionen nach Tags, Triggern, Variablen und Konfigurationsbegriffen, etwa einer Zielkennung oder analytics_storage. Der Zugriff erfordert eine Google-Anmeldung und ist auf Lesen beschränkt. Die Prüfung der Konfiguration ergänzt die Kontrolle des tatsächlichen Messversands im Browser; Einwilligungsabläufe und Kontoberechtigungen bleiben gesondert zu prüfen.

1. Bestand erfassen: eingebettete Schnipsel, Kennungen, CMS-Plugins, Ziele, config-Parameter, Ereignisweiterleitungen und Einwilligungsintegration dokumentieren. Bei mehreren Containern auch deren Zuständigkeiten festhalten.
2. Ausgangslage sichern: veröffentlichte Containerversion exportieren und Kontoverknüpfungen sowie Berechtigungen separat erfassen. Eine Referenzmessung mit Seitenaufruf, Routenwechsel und Testkauf anlegen.
3. Angebot prüfen: den Optimierungsassistenten des konkreten Containers öffnen und Unterschiede der Einstellungen fachlich auflösen. Arbeitsbereichsänderungen vor der Veröffentlichung kontrollieren.
4. Trigger abgleichen: Wildcard-Regeln auf gtag.config prüfen und technische Ereignisse von beabsichtigten Geschäftsereignissen trennen.
5. Vorschau testen: Tag Assistant mit Netzwerkanalyse verbinden. Zielkennung, Ereigniszahl, Parameter, Einwilligung und gegebenenfalls Serverroute prüfen. Automatische und selbst erzeugte Seitenaufrufe gemeinsam betrachten.
6. Version veröffentlichen: einen klar benannten Stand mit dokumentierten Änderungen und Rückfallweg freigeben. Rechteänderungen gesondert behandeln.
7. Nachkontrolle durchführen: dieselben Testfälle im veröffentlichten Stand wiederholen. Fachliche Kennzahlen anschließend über einen passenden Vergleichszeitraum beobachten; veränderte Trafficmenge oder Kampagnen sind keine belastbare Performancekontrolle.

Die technische Richtung ist sinnvoll: weniger getrennte Konfiguration, ein direkterer Versand und eine gemeinsame Verwaltung. Der Nutzen entsteht aber erst, wenn Ereignisse, Ziele und Verantwortlichkeiten eindeutig bleiben. Der wichtigste Sofortcheck im Oktober ist deshalb die Kombination aus tatsächlicher Lade-ID, Wildcard-Triggern und verbliebenen config-Abhängigkeiten.