Google Tag Manager mit Zielen statt Google-Tags: Umstellung, Vorteile & Stolpersteine

Inzwischen ist die mit dem "neuen" Tag Manager UI angefangene Umstellung zur Vereinheitlichung von gtag.js und gtm.js in die entscheidende Runde gegangen: Google-Tags werden als "alt" markiert, und die neuen Tag-Typen für GA4, Google Ads und Floodlight (und Merchant-Center-Conversion-Quellen als weiterer neuer Tag-Typ) verbinden den GTM-Container ab sofort direkt mit den jeweiligen Zielen, also der GA4-Property oder dem Werbekonto. Simo Ahava hat das Feature (wie immer) bereits ausführlich vorgestellt (Optimized Tagging Experience in Google Tag Manager). Hier geht es neben Stolperfallen und Besonderheiten dennoch um den Umstellungsprozess selbst, damit alle Infos an einer Stelle stehen - so, wie es im verlinkten ersten Beitrag ursprünglich geplant war. Wer vor der Umstellung steht oder neue Container mit den neuen Tag-Typen plant, findet im Folgenden Hinweise aus meiner (noch jungen) Praxis, die Fehler vermeiden und Zeit sparen können.

Viel los in der alten Container-Übersicht

Der erste Kontakt mit dem neuen Format findet schon auf der Startseite des GTM statt, bevor überhaupt ein Container geladen ist. Die Aufteilung zwischen Google-Tag und Container in der Übersicht ist weg. Die Liste ist daher ggf. unendlich viel länger - und leider unübersichtlicher. Dass gtag.js und gtm.js zusammenwachsen, wirkt sich so bereits auf die tägliche Arbeit aus, bevor man ein einziges Tag umgestellt hat. Ich bin ehrlicherweise nur moderat begeistert davon 😐

Spannend wird es auf der Übersichtsseite eines bestimmten Containers. Wie inzwischen gewohnt, zeigt sie die Übertragungswege als Grafik. Ausgangslage ist hier i. d. R.: Container → Google-Tags → Ziele. Neu ist die "Einstiegs-Card" zur Umstellung ("Schnelleres und einfacheres Tagging mit optimierten Zielen"), die erscheint, sobald der Cursor über eines der dargestellten Google-Tags fährt.

Vorhandene Google-Tags umstellen

Schritt 1: Google-Tags auswählen

Ein Klick auf "Jetzt starten" öffnet einen Assistenten, der die Umstellung auf direkt angebundene Ziele (Destinations) begleitet. Unter "Containerkonfiguration optimieren" wählt man die Google-Tags aus, die in den Container "verschoben" werden. Man steigt also bei einem Tag ein und kann weitere Tags im Container gleich mit auswählen - der Assistent muss nicht für jedes Tag neu gestartet werden. Das ist sinnvoll, weil hier gleich die gemeinsamen Einstellungen generiert werden (müssen).

Pro Tag lässt sich die Berechtigung für die optionale Verknüpfung zwischen den GTM-Einstellungen und dem ehemaligen Google-Tag in der jeweiligen Verwaltungsoberfläche wählen (z. B. "Lesezugriff"). Mehr dazu im Abschnitt "Destinations <> Links".

Hier wartet bereits die erste Stolperfalle: Ein Tag kann mehrere Ziele bündeln - vor allem, aber nicht nur ein GT--Tag (z. B. ein ehemaliges Ads-Google-Tag, das zusätzlich an eine GA4-ID sendet, oder umgekehrt). Der Tag Manager braucht für jedes bisherige Ziel ein eigenes Ziel-Tag. Fehlt es, geht das Ziel bei der Umstellung verloren bzw. funktioniert im Browser nicht mehr (dazu später mehr).

Schritt 2: Containereinstellungen auswählen

Deutlich schwieriger ist die Wahl auf der nächsten Seite. Haben die umzustellenden Google-Tags unterschiedliche Einstellungen, muss man sich für die Settings eines Tags als Containerstandard entscheiden … oder "nicht importieren" wählen und damit einen neuen Satz an Einstellungen im Standardzustand erzeugen. Wer "nur" ein GA4- und ein Google-Ads-Tag umzustellen hat, kann vorher per "View settings" vergleichen, welche Settings wo stecken, und den neuen Zustand festlegen.

Zur Orientierung: Ein GA4-Tag trägt in der Regel deutlich mehr Einstellungen als ein Google-Ads-Tag, dessen Konfiguration oft noch nie jemand angesehen, geschweige denn geändert hat. Ads-Tags weichen also seltener vom Standard ab, während in GA4-Tags oft Regeln für internen Traffic, Cross-Domain-Tracking, Verweisausschlüsse etc. stecken.

Spätestens wenn mehrere unterschiedlich gestaltete Einstellungen zusammengelegt werden müssen, helfen ggf. die API und/oder ein GTM-MCP, um z. B. Domains für Verweisausschlüsse aus mehreren Tags zu übernehmen statt nur aus einem oder IP Regeln zu generieren. Für den Vergleich vorab gibt es ein kleines Script als Gist: Es liest die Settings beliebig vieler IDs aus dem öffentlichen gtag.js (ohne API-Zugriff oder Login) und stellt sie nebeneinander, Abweichungen sind markiert. Es zeigt außerdem, welche Ziele in einer ID stecken. Nur die IP-Bereiche für internen Traffic stehen nicht im gtag.js und müssen in GA4 (leider auch nicht per API erreichbar) nachgesehen werden. Für einen ersten Blick auf potenzielle Konflikte ist diese Übersicht allerdings m. E. bereits sehr hilfreich... spätestens bei einem Multi-Site-Container.

Wichtig zu wissen: Ob Nutzerdaten erhoben werden (und nach welcher Methode), lässt sich nicht mehr je Ziel getrennt (in den Standardeinstellungen) festlegen. Wer das für Ads nutzen will, muss es in den gemeinsamen Settings erlauben - und es gilt dann automatisch für alle Ziele, die der Container bedient. Per Standard "offene" Optionen sind allerdings z. T. in den einzelnen Ziel-Tags wieder per Konfigurationsparameter wie ads_data_redaction zu "schließen". Weiter unten gibt es ein Beispiel und eine Liste zu allen Parametern. Für das Ausschalten von automatischer Sammlung von Nutzerdaten habe ich aber beispielsweise keinen wirkungsvollen Parameter gefunden. Hier das explizite Senden per user_data unter den gewünschten Bedingungen selbst in die Hand zu nehmen, erscheint mir dafür die einzige Option für granulare Kontrolle.

Unvermeidbare Kontrolle nach der Umstellung

Nach der Umstellung stehen keine Google-Tags mehr "im Weg", die Grafik zeigt den direkten Weg Container → Ziele. Wichtiger ist die Liste der ausstehenden Änderungen darunter:

• geänderte Tags (Google-Tag → Ziel-Tag) plus
• neue Einträge vom Typ "Einstellung"
  • automatische Ereignisermittlung,
  • Domains konfigurieren,
  • von Nutzern bereitgestellte Daten,
  • Liste unerwünschter Verweise,
  • Sitzungs-Zeitüberschreitung,
  • …

Welche Einstellungen hier auftauchen, hängt von den Settings des als Vorbild gewählten Google-Tags ab. "Gemeinsame Einstellungen für alle Tags" betrifft dabei auch Settings, die nicht in der Liste stehen, weil sie im Standard arbeiten. "Enhanced Measurement" für GA4 gilt im definierten Umfang ab der Umstellung daher ebenso für Google Ads. Gleiches gilt für Filterregeln, Cross-Domain-Linking, internen Traffic … der ganze Kram halt. Das kann je nach Ausgangslage komplex werden.

Settings, die bisher im Google-Tag (in GA4 bzw. Google Ads) gepflegt wurden, gelten nach der Umstellung nicht mehr automatisch. Sie müssen als Container-Einstellung existieren, sonst gehen sie stillschweigend verloren. Deshalb wird eine "Verknüpfung" zwischen GTM und den Zielen angeboten: Bei einem umgestellten GA4-Tag lassen sich dann keine individuellen Tag-Settings mehr vornehmen, die beim Ausspielen via GTM ohnehin wirkungslos wären. Mit Lesezugriff erscheinen stattdessen in den Tag-Einstellungen der Datenstrom-Ansicht in GA4 die Settings aus dem GTM-Container.

Das betrifft tatsächlich nur die Einstellungen des Google-Tags. Settings des Ziels selbst (z. B. Signals, Events erstellen/ändern in GA4, API Secret für den Datenstrom etc.) kommen weiterhin aus GA4 bzw. Google Ads.

Wegfall Conversion Linker

Falls ein Tag vom Typ "Conversion-Verknüpfung" die Umstellung überlebt hat, kann es guten Gewissens manuell entfernt werden. Ein fehlender Linker hatte schon vorher keine Auswirkungen, solange irgendein Google-Tag (GA4 oder Ads) gefeuert hat - der GTM hat bis dato trotzdem stets gemeckert. Das entfällt nun. Einen serverseitigen Linker im ssGTM sollte man dagegen behalten, denn er setzt üblicherweise robustere Cookies, als es der GTM im Browser vermag.

Nacharbeiten an den Einstellungen

Bei den künftig im GTM verwalteten gemeinsamen Einstellungen ist minimale Nacharbeit nötig: Der entstehende Cross-Domain-Filter ist i. d. R. unnötig streng.

Sind mehrere GA4- oder Google-Ads-Tags im Spiel, müssen zudem die bisherigen individuellen Einstellungen der weiteren Tags nachgetragen werden (zum Beispiel IP-Filterregeln).

Destinations <> Links

Im Bereich "Einstellungen" des Tag Managers finden sich nicht nur die Optionen, die man vorher aus den Tag-Einstellungen kannte, sondern vor allem (oben) eine Liste der Ziele, die der Container bedient. "Optimiert" heißt hier: Das Laden findet komplett ohne Google-Tag statt.

Die letzte Spalte zeigt den Status der Verknüpfung zwischen GTM und Ziel. Ohne Link sind die im GTM effektiv geltenden Einstellungen - wie oben beschrieben - faktisch "unsichtbar", wenn man nur auf das Tag in GA4 oder Google Ads schaut. Wer dort Einstellungen vornimmt, konfiguriert wirkungslose Optionen, solange das Tag via GTM-Destination ausgespielt wird. Der Lesezugriff per Link ist daher ein nicht unwichtiges "Transparenz-Feature", das in der derzeitigen Form leider noch eher wackelig wirkt.

Wichtig: Für die Zustellung der Hits aus dem Container an die Ziele ist der Link irrelevant! Es ist daher kein K.-o.-Kriterium, wenn man (wie bisher) keinen Zugriff auf die eigentlichen "Google-Tags" der Zielsysteme hat (z. B. keinen Google-Ads-Zugriff). Die Verbindung ist unidirektional: Ist sie aktiv, kann man aus dem Zielsystem auf die Einstellungen des Tag Managers zugreifen, nicht umgekehrt. Die Verbindungen zu anderen Diensten finden sich außerdem in den Einstellungen des Containers, wo sie sich nachträglich aufheben lassen.

Neue Einstellung "Datenübertragung verwalten"

In den Einstellungen des Containers gibt es eine neue Option, die aus den bisherigen Tag-Einstellungen nicht bekannt ist: die "Kontrolle der Datenübertragung". Das klingt (nicht nur im Beitrag von Simo) erst mal toll, um Basic Consent Mode durchzusetzen. Da es ohnehin nur für Google-Tags relevant ist, halte ich an meinen bestehenden Trigger-Konzepten fest und kann hier bisher keine eigenen Erfahrungen beisteuern.

Feste IDs in den Ziel-Tags

Vor einer ersten Vorschau gibt es einen weiteren Punkt zum Nachbessern: Der Assistent ersetzt Variablen/Konstanten in der ID der bisherigen Google-Tags durch die konkrete ID. Aus {{GA4 Measurement Id}} wird im neuen Ziel-Tag so z. B. G-123456.

Wer genau wissen will, was vorher dort stand, lässt sich die Details der Änderungen anzeigen. Dort sind alte und neue ID (und der geänderte Tag-Typ) zu sehen:

Wer vorher eine Variable vom Typ "Konstante" verwendet hat, sollte sie wieder einsetzen. Konstanten werden beim Kompilieren des Containers korrekt aufgelöst, das Ziel bleibt damit in der Übersicht (und im Verhalten) "optimiert". Andere Variablentypen für die ID sind dagegen problematisch: Such- und RegEx-Tabellen funktionieren nur unter bestimmten Bedingungen, dataLayer- oder JavaScript-Variablen brauchen eine andere Lösung.

Das gilt auch, wenn eine solche Variable "nur" dazu dient, bei bestimmten Hostnamen auf eine andere GA4-Property umzuschalten. Man sitzt damit im selben Boot wie umfangreiche Multi-Site-Setups, deren IDs für GA4, Google Ads oder Floodlight vom Hostnamen oder anderen Merkmalen abhängen. Mehr dazu im Abschnitt "Multi-Site".

Erhalt der bisherigen Funktionen des Google-Tags

Davon abgesehen bleibt bei den neuen Ziel-Tags vieles gleich: Konfigurations- und Event-Parameter sowie Einstellungsvariablen werden 1:1 übernommen und funktionieren wie bisher. Das gilt auch für "Update"-Tags in Single Page Applications (in einigen Umstellungen bereits getestet).

Typische Konfigurationsparameter wie send_page_view oder server_container_url sind ebenso nutzbar wie alle anderen Konfigurationsparameter für ein Google-Tag. Aber: Es kann keine Einstellung wieder aktiviert werden, die durch die gemeinsamen Einstellungen des Containers bereits ausgeschaltet ist. Umgekehrt funktioniert es allerdings, sodass einzelne Features in einem Ziel mit Parametern wie allow_ad_personalization_signals auf false wieder deaktiviert werden können.

Hinweis: Eine Teilumstellung ist natürlich durchaus möglich. Wer nur GA4 umstellen kann und mehrere Ads-Konten wegen völlig unterschiedlicher Settings oder aufwendiger Bestimmung des korrekten Kontos weiter über Google-Tags bedienen will oder muss, kann das tun. Das kann der Fall sein, wenn sich die Unterschiede selbst mit individuellen Parametern als Ausnahmen von der Standardkonfiguration nicht granular genug in einem gemeinsamen Destination-Tag abbilden lassen. Die Übersicht zeigt dann, welche Ziele direkt bedient werden und welche nicht.

Unterschiede in der Vorschau

Sind alle Vorbereitungen erledigt, ist eine Vorschau über den Tag Assistant Pflicht. Das gilt immer, hier aber besonders, denn es gibt ein paar Neuerungen. So tauchen die im Container enthaltenen gemeinsamen Einstellungen in der Vorschau als eigener Block "Tag Settings" auf.

Außerdem zeigt nun der GTM selbst - und nicht wie vormals nur das Debugging eines Ziel-Tags - im Bereich "Gesendete Treffer", was wirklich verschickt wurde. Ein passender Auslösestatus im Bereich "Tags" reicht daher nicht: "Erfolgreich" heißt bei Konfigurationsproblemen noch nicht, dass wirklich etwas versendet wurde. Requests daher ggf. direkt im Browser prüfen (Network-Tab oder mit dem Tracking Auditor).

Besonders wichtig ist das bei mehreren Zielen desselben Typs: jede Property und jedes Ads-Konto einzeln prüfen! Sonst lernt man ggf. auf die teure Art - über Lücken in den Daten -, dass ein "sauber" gefeuertes Tag noch keinen Hit bedeutet. Wer bei aktiver Vorschau die Network-Requests filtert und auf gtag/js?id=DUMMY stößt: Das ist in der Vorschau normal und kein Überbleibsel eines Google-Tags. Ziel ist, nach der (vollständigen) Umstellung ohne aktive Vorschau keine gtag/js-Requests mehr zu finden - und auch kein gtag/destination (siehe Multi-Site).

Performance: Was bringt die Umstellung?

Nach der Umstellung wird der GTM-Container selbst erst mal größer, nicht kleiner. Das liegt vor allem an den Settings, die nun zur Größe beitragen. Die Gesamtlast sinkt trotzdem, weil x-mal gtag.js wegfällt. Bei einmal GA4 und mehreren parallelen Google Ads Konten sind das gern um die 400 KB Einsparung (und natürlich weniger Requests). Ein konkretes Beispiel aus einem umgestellten Projekt mit GA4 via Server-Container und (einmal) Google Ads, gemessen beim Aufruf der Startseite ohne weitere Events, Conversions etc.: Die geladenen Scripts sinken von 3 auf 1, das Script-Volumen von 495 auf 219 KB (ca. 56 % Einsparung), die Google-Requests von 10 auf 7. Die Ads-Hits bleiben unverändert.

Vor allem bei selbst gehostetem GTM mit First-Party-Bereitstellung kann die Umstellung ein Faktor sein - sofern man nicht ohnehin ein Google Tag Gateway nutzt oder in einem Abrechnungsmodell pro Request steckt, bei dem sich der Vorteil kaum auf die (eigenen) Kosten auswirkt.

Multi-Site-Setups

Multi-Site-Setups mit vielen verschiedenen GA4-, Google-Ads- oder Floodlight-IDs kann der GTM derzeit nicht aus dem Stand umstellen. Je nach Gestaltung der bisherigen Google-Tags ist weder die Umstellung machbar noch ein Neuaufbau nach dem bisherigen Schema möglich. Ich hoffe, dass Google hier nachbessert. Auch darüber hinaus können solche Container in der Pflege komplex werden. Und wenn es wie oben beschrieben unterschiedliche Tag-Settings geben muss, die man auch mit Anpassungen einzelner Ziel-Tag-Konfigurationen via Parameter nicht herstellen kann, bleibt der Weg ggf. dauerhaft verwehrt, und man muss bei den "alten" Google-Tags bleiben. Was sicher noch eine ganze Zeit lang kein Problem darstellt.

An einem Beispiel lassen sich die Stolperfallen gut zeigen. Darin gibt es bisher je ein Google-Tag für GA4 und Google Ads. Der GTM erkennt durchaus, dass die Platzhalter keine echten IDs sind, und zeigt folgerichtig zehn weitere "Tags" an. Sie stehen für die unterschiedlichen IDs der GA4- und Google-Ads-Konten von 5 verschiedenen Websites:

Nur das eine Tag mit den variablen IDs umzustellen, geht leider nicht. Daher muss vor der Umstellung eine Wahl getroffen werden, welche Einstellungen "am besten" passen, und die dazugehörende Ziel-ID wird anstelle der Variable eingetragen. Das ist für alle Google-Tags zu wiederholen, die dynamische IDs verwenden. Durchläuft man nun den Assistenten mit den umgestellten Google-Tags, kann danach wieder ein Wechsel erfolgen, und die Suchtabellen-Variablen werden wieder eingesetzt.

Ein GA4-Tag zum Beispiel mit einer {{Suchtabelle}} als Quelle der ID führt dann dazu, dass alle aufgelösten IDs aus der Tabelle in den GTM einkompiliert werden und in der Übersicht der Ziele als "optimiert: ja" erscheinen. Auch RegEx-Tabellen funktionieren, solange der GTM eine faire Chance hat, die IDs dort zu extrahieren. Die Komplexität der Regeln spielt dabei keine Rolle; auch nicht der Eingangswert. Meint: Es muss nicht zwingend der Page Hostname sein, an dem die Bestimmung hängt.

Stolperfallen bei der Auflösung

• Was nicht zu funktionieren scheint, ist das "teilweise" Auflösen einer ID. Das passiert gern bei Google Ads, wo das bisherige Tag mit einem Konstrukt wie AW-{{Suchtabelle}} bedient wird und aus der Suchtabelle nur die Conversion-IDs der Konten kommen. Solche Ziele werden nicht einkompiliert, sondern bestenfalls zur Laufzeit per gtag/destination nachgeladen (≈ 170 KB, also so groß wie vorher gtag.js). Die Ads-Hits kommen dann zwar an, gespart wird aber nichts. Schlimmer: Im selben Container bekam GA4 auf keiner der Sites mehr Daten, obwohl die GA4-IDs selbst sauber einkompiliert waren. In einem anderen Fall ging zwar nicht "gar nichts" raus, aber nach dem Laden der Seite dauerte es über eine halbe Minute, bis GA4-Hits endlich den Browser verließen. Die Vorschau zeigte für das Tag freilich "erfolgreich" an - es hat ja gefeuert.
• Ebenso zu beachten: Eine in der Tabelle vorhandene ID für ein "echtes Google Tag" mit GT-xxxx ist kein Ziel! Es ist die ID eines Tags zur Bedienung eines Ziels. Es muss daher die Ziel-ID des Ads-Kontos sein, die typischerweise AW-xxxx lautet, wobei xxxx die Conversion ID des Kontos ist, welche bei allen Conversions übereinstimmt. In einer zur Not separaten Variable die IDs vollständig anzubieten, löst das Problem und die Ziele werden als "optimiert" dargestellt.
• Standardwerte in den Tabellen wie "UNKNOWN" o. Ä., mit denen man blockierende Trigger für Sites ohne ID baut, sind ein weiterer Stolperstein. Dieser wird erst dann sichtbar, wenn man versucht, einen umgestellten Container zu veröffentlichen. Man muss daher auf Standardwerte verzichten, die keine ID sind, und die blockierenden Trigger umbauen: statt "ID enthält Unknown" z. B. gegen undefined prüfen oder auf "ID enthält -", denn ein Minus als Trenner ist in jeder Tag-ID zu finden.
• IDs müssen "final" und vollumfänglich bekannt sein. Kommt eine ID ins Spiel, die dynamisch angepasst wird o. Ä., wird das entsprechende Ziel nicht funktionieren und im schlimmsten Fall die Übertragung auch an die anderen IDs stören!

Wer für die Herstellung der passenden Bedingungen z. B. eine Suchtabelle hinzufügen muss, weil sonst nur die Conversion ID des Ads Kontos aus einer Suchtabelle kommt und das "AW-" fehlt, muss die IDs nicht doppelt in zwei Suchtabellen pflegen. Denn verrückterweise funktioniert es auch, wenn man alle IDs als Konstanten anlegt und dann in beiden Suchtabellen verwendet. Die eine liefert also nur je Site die passende ID anhand der Konstante aus, die andere schreibt noch "AW-" davor - das ist alles. Eine solche Variable liefert vollständig auflösbare IDs und die Umstellung gelingt. Ungerechterweise gilt das nicht, wenn man statt einer Regex- oder Suchtabelle eine einfache benutzerdefinierte JavaScript-Variable verwendet, die dem Ergebnis der Conversion-ID-Tabelle das fehlende "AW-" voranstellt. Das Ads-Ziel wird dann wieder zur Laufzeit nachgeladen, und GA4 fiel im Test ebenfalls komplett aus. Schade 😉

Wenn nichts mehr hilft

All das ist manchmal nicht zu lösen. Wenn z. B. die IDs aus komplexen Konstrukten kommen, aus unbekannten Variablentypen - oder erst zur Laufzeit aus dem dataLayer gelesen werden. Das ist nicht der Standard, aber es kommt vor. In einem solchen Fall helfen nur noch "Pflaster" in Form weiterer Destinations, die dem Container hinzugefügt werden und die dann eine eingetragene oder aus einer Konstante stammende ID besitzen. Die gute Nachricht: sie müssen gar nicht feuern. Pro ID ein Ziel-Tag mit fester ID bzw. Konstante an einem Trigger, den ich "Never" genannt habe und der nie auslöst, reichte in meinem selbst produzierten "Extremfall" in einem Testcontainer aus. Im Trigger-Konzept selbst arbeitet man weiterhin je Dienst mit einem einzigen Ziel-Tag und den IDs aus komplexem Code oder für den GTM "undurchdringlichen" Variablen. Die anderen Ziel-Tags im Container dienen faktisch nur als "Registrierungs-Tags". Das ist nicht schön, aber der sparsamste Weg, den ich bisher gefunden habe. Für Staging vs. Live mit unterschiedlichen GA4-Properties ist das sicher vertretbar; größere Multi-Site-Instanzen sollten aber auch ohne diese Maßnahme umzustellen sein. Ansonsten lässt man diese idealerweise weiter nach dem "alten" System mit Google-Tags laufen.

Ergebnis der Reduktion

Bei den 5 Sites aus diesem Beispiel bedeutet das: Das Script-Volumen sinkt von 556 auf 236 KB (-58 %). Die Kehrseite: Die einkompilierten Ziele aller Sites lassen gtm.js um ca. 55 KB wachsen. Das ist eine schöne Bilanz. Idealerweise erreicht man diese ohne das Hinzufügen weiterer Destination-Tags, denn dann stecken im Container neben den eigentlichen Destinations die "Dummy"-Ziele für jeweils 5 IDs mal zwei Dienste. Ich halte dieses Vorgehen daher bestenfalls im Extremfall oder für eine Umstellungszeit für sinnvoll.

Nicht zu vernachlässigen ist so oder so der Aufwand für den oben beschriebenen Abgleich der Einstellungen aller beteiligten Tags. Je mehr Tags beteiligt sind, desto größer fällt die Arbeit aus. Selbst mit dem Script zum Auslesen kommt hier üblicherweise einiges an Arbeit zusammen, was das Zusammenlegen von IP-Regeln, Ausschlüssen etc. betrifft. Ganz von Hand kommt das Thema daher irgendwann an seine Grenzen und die API ist der bessere Weg, einen Container auf das neue System zu heben.

Ausgehende Requests prüfen!

Bei Multi-Site ist der Blick auf die ausgehenden Requests und das Timing daher besonders wichtig. Funktioniert die Site, auf der man testet, "zufällig" dank der Auswahl bei der Umstellung, entgehen einem sonst die Probleme auf den anderen Sites. Bei einem "Gate" für Live vs. Staging per Suchtabelle sollte man daher z. B. nicht nur die Live-Website, sondern tatsächlich auch die Stage vermessen. Wer eine Suchtabelle wie beschrieben umstellt und nur ein nicht auflösbares Ziel im Spiel hält, wiegt sich beim ersten Check in trügerischer Sicherheit. Die Liste der Ziele in der UI beweist leider nichts - dort erscheinen auch Ziele aus Suchtabellen, an die der Container ggf. gar nicht senden kann.

Fazit

Natürlich ist es zu begrüßen, dass man sich im neuen System den "Umweg" über Google-Tags sparen kann. Bei vermutlich mehr als 90 % aller Websites, die den Tag Manager für GA4, Google Ads und Floodlight nutzen, sind konstante IDs im Einsatz. Die Einsparungen und das bessere Ladeverhalten sollte man dort mitnehmen, spätestens bei der nächsten Anpassung des Containers. Die Umstellung lohnt sich auch dann, wenn es etwas Zeit kostet, die Settings sorgfältig zu prüfen und wie beschrieben nachzuarbeiten.

Für komplexe Multi-Site-Container mit sehr unterschiedlichen Einstellungen bin ich aus den genannten Gründen noch nicht so begeistert - das wird sich aber ggf. noch ändern. Der wichtigste Tipp für alle, die eine Umstellung oder einen Neubau mit Destinations statt Google-Tags angehen: ausgehende Requests im Browser oder in der Vorschau prüfen, nicht nur den Status der Tag-Auslösung! Dann sollte nichts schiefgehen, und die Vorteile werden nicht mit Datenverlust bezahlt 😉