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 25. 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 ist die JavaScript-Bibliothek für den bisherigen Google-Tag. Die Funktion gtag() reiht Befehle zunächst ein; erst deren Verarbeitung kann eine Messanfrage auslösen. Der Google-Tag enthält die dazugehörigen Einstellungen. GTM verwaltet diese Messbausteine in einem Container. Ein Tag sendet beispielsweise einen Kauf, ein Trigger bestimmt den Auslösezeitpunkt und eine Variable liefert etwa die Bestellsumme. Arbeitsbereiche sammeln Änderungen; veröffentlichte Versionen halten einen freigegebenen Stand fest. [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]

GA4-Properties und Anzeigenkonten bleiben getrennt. Für einen Kauf muss weiterhin feststehen, wann das Ereignis entsteht und welches Konto die Daten erhalten soll. Beispielsweise sollte ein Aufruf des Warenkorbs nicht schon als abgeschlossene Bestellung gelten. Bei zwei Empfängern ist der Versand an jedes Ziel einzeln zu prüfen.

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 gleichen Einstellungen beginnt die Prüfung über Review details. Bei unterschiedlichen Google-Tags führt Get started zur Auswahl der gemeinsamen Einstellungen. Entscheidend ist, welche bisherige Einstellung erhalten bleibt und welche überschrieben wird. Absichtlich unterschiedliche Vorgaben dürfen nicht unbemerkt durch denselben Standard ersetzt werden. [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]

Ein Vergleich braucht dieselbe Seite, dieselben Tags und denselben Einwilligungszustand. Ein kalter Cache enthält die benötigten Dateien noch nicht; ein warmer Cache kann bereits geladene Dateien wiederverwenden. Mehrere Läufe in beiden Zuständen zeigen, ob der Versand tatsächlich früher beginnt. Eine frühere Messanfrage beweist dabei noch keinen schnelleren sichtbaren Seitenaufbau.

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]

Die im HTML eingebettete Ladeanweisung zeigt, welche Kennung tatsächlich verwendet wird. Diese Angabe muss zur Konfiguration im Google-Konto passen. Mehr Funktionen in der Oberfläche schalten bei einer G- oder AW-Kennung nicht automatisch Tags anderer Anbieter frei. Eine gültige GTM-Kennung entsteht auch nicht durch bloßes Ändern der Anfangsbuchstaben.

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 ist ein Suchmuster. Das Muster .* passt auf jeden Ereignisnamen, also auch auf gtag.config. Ein Tag, das sämtliche passenden Namen weiterleitet, kann deshalb eine technische Konfigurationsmeldung mitsenden. Daraus entsteht aber nicht automatisch ein zusätzlicher Kauf; dafür müsste die nachgelagerte Konfiguration die Meldung entsprechend behandeln.

Eine Liste erlaubter Namen trennt beispielsweise Produktansicht, Warenkorb und Kauf von technischen Meldungen. Das folgende Muster erlaubt genau diese drei Namen. ^ und $ begrenzen den vollständigen Namen, | trennt die Alternativen. Das ist ein Beispiel und keine vollständige Ereignisliste oder 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

Ein Destination-Tag kann laut Google automatisch einen Seitenaufruf an das Ziel senden. Bei einer Single-Page-Anwendung wechselt der sichtbare Inhalt teilweise ohne neues Laden des HTML-Dokuments. Deshalb braucht der erste Aufruf ebenso wie jeder beabsichtigt gemessene Routenwechsel eine klare Regel: Welcher Mechanismus sendet den Seitenaufruf, und läuft daneben noch ein zweiter? [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]

Ein Versionsrückwechsel stellt Berechtigungen nicht wieder her. Ein Beispiel: Während der Optimierung erhält ein verknüpftes Konto Lesezugriff. Ein späterer Rückwechsel auf die alte Containerversion entfernt diesen Zugriff nicht automatisch. Deshalb gehören die bisherigen Kontoverknüpfungen und Rechte zur Sicherung. Nach der Umstellung lassen sich diese Angaben im Bereich External Account Links getrennt kontrollieren. [3]

Einwilligung und serverseitiges Tagging bleiben eigene Prüfungen

Eine CMP verwaltet die Auswahl im Einwilligungsbanner. Die Zusammenführung ersetzt diese Aufgabe nicht. Im Basic Consent Mode bleiben Google-Tags ohne passende Einwilligung blockiert. Im Advanced Consent Mode können trotz Ablehnung Messanfragen ohne Cookies versendet werden. denied bedeutet daher nicht in jedem Aufbau, dass keine Anfrage an Google erfolgt. [7]

Die Consent-Initialisierung setzt die Ausgangswerte vor den davon abhängigen Tags. Dafür sind in GTM die vorgesehenen Template-APIs zuständig. Ein über Custom HTML eingereihter gtag-Consent-Befehl kann erst nach bereits wartenden Meldungen verarbeitet werden. Die Prüfung braucht deshalb vier Fälle: noch keine Auswahl, Zustimmung, Ablehnung und späterer 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 verlangt unter anderem eine Bestellbestätigungsseite, einen websiteweiten Google-Tag und Bearbeitungsrechte. Im Ablauf werden beispielsweise Transaktionskennung, Zwischensumme der Bestellung und Währung zugeordnet. Bereits vorhandene Kaufmessungen können zu Doppelzählungen führen. Ein Testkauf muss deshalb zeigen, welche Werte wirklich übertragen werden. Nach einer Umgestaltung der Bestätigungsseite ist außerdem zu prüfen, ob die ausgewählten Elemente weiterhin stimmen. [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. Ein Suchlauf betrifft nur die ausgewählten und erfolgreich abgerufenen Versionen. Ein fehlender Treffer beweist nicht, dass eine Einstellung niemals vorhanden war; Suchfehler und unvollständige Abrufe sind möglich.

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.

Für die Umstellung sind drei Nachweise besonders hilfreich: die tatsächlich verwendete Lade-ID, das Ergebnis der Prüfung auf gtag.config und ein protokollierter Testkauf. Zusammen zeigen diese Prüfungen, welcher Container läuft, welche Ereignisse weitergeleitet werden und welche Kaufdaten ankommen. Berechtigungen und Einwilligungsabläufe bleiben zusätzliche Prüfpunkte.