Markus Baersch

Sobald mehr als ein globales “Marketing-Pixel” oder ein beliebiger Tracking-Code auf Websites eingebunden werden soll, spielen Tag Management Systeme ihre Stärken aus. Gezieltes Ausspielen von Tags verschiedener Dienste auf einzelnen oder allen Seiten sowie die Messung von einzelnen Events und E-Commerce sind damit ungleich einfacher als bei direkter Implementierung. Kein Wunder also, dass Google Tag Manager, Tealium oder Tag Management Komponenten von Matomo, Piwik PRO und anderen weit verbreitet sind. Was aber, wenn mehr als eine Website bedient werden soll? Bekommt jede Seite einen eigenen Tag Manager oder ist eine zentrale Pflege in einem Multi-Site-Container möglich und sinnvoll? Die Antwort hängt - wie immer - von den Rahmenbedingungen ab.

Hinweis: Dieser Beitrag basiert auf meinem im November 2023 in Ausgabe 3 des Analytics Pioneers Magazins erschienen Beitrag "Multi-Site Tagging: Vor- und Nachteile". Da es aber ein Dauerthema ist, wollte ich ihn hier nun auch in digitaler Form anbieten. Das Magazin bietet regelmäßig umfangreiche Beiträge zu Digital Analytics Themen und ich kann es nicht nur als Autor,  sondern vor allem als Leser empfehlen!

Grundkonzept Multi-Site-Tagging

Die Idee hinter einem Multi-Site- oder Multi-Domain-Setup für Tag Management Systeme ist einfach. Angenommen, ein Unternehmen betreibt eine “allgemeine Website”, einen separaten Online-Shop und drei Produkt-Microsites. Statt z.B. Google Analytics, Facebook Pixel, Google Ads Tracking und andere Tags mehr oder weniger gleich in fünf verschiedenen Google Tag Manager Containern zu installieren und dort zu pflegen, werden alle Sites mit dem gleichen GTM Container versorgt. Dort wird anhand der aktuellen Domain oder aus Informationen in der Datenschicht ermittelt, welche Daten für GA4 Measurement ID, Facebook Pixel ID etc. zu verwenden sind.

Dieser Ansatz bietet eine Reihe von Vorteilen:

Verringerter Erstellungs- und Pflegeaufwand

Abgesehen davon, dass die Erstellung von fünf separaten Containern - auch bei Nutzung der Export- und Importfunktionen - immer länger dauern wird als die Bestückung eines einzelnen GTMs, ist vor allem die spätere Pflege deutlich einfacher.

Ist eine “Version 1” ansonsten erst einmal in fünf Containern installiert, vervielfacht sich der Aufwand bei jeder nachträglichen Anpassung, weil er in allen Einzel-Containern anfällt.

• Neue Events
• Umbenennungen von Events
• Änderungen im Design (in dieser Konstellation z.B. vielleicht auf den Microsites) oder
• das Austauschen von Pixel-IDs

werden entweder zur lästigen Routine oder erfordern eine Automatisierung, mit der alle Container gepflegt werden können. In den seltensten Fällen wird die zweite Lösung wirtschaftlich sinnvoll sein. Der manuelle Weg hingegen birgt die Gefahr, dass sich Fehler in die Implementierung eines oder mehrerer Container einschleichen. Da hat ein gemeinsamer Container als unbestreitbar die Nase vorn!

Zentrale Steuerung

Die Umsetzung einer Änderung, die für alle Standorte relevant ist, kann bei einer zentralen Steuerung in der Regel nicht nur zuverlässiger, sondern meist auch deutlich schneller umgesetzt werden. Statt der Kommunikation mit ggf. mehreren Betreuern genügt hier ein Ticket.

Leider birgt dieser Vorteil auch eine nicht zu unterschätzende Gefahr: Wenn ein Container für fünf Websites zuständig ist, macht dies einen gut funktionierenden Prozess zur Qualitätssicherung unabdingbar. Wo früher “nur” ein Standort Probleme mit einer neuen GTM-Version hatte, können nun alle nutzenden Standorte betroffen sein. Vor allem Kernprozesse wie ein reibungslos funktionierender Checkout in einem Multi-Site-E-Commerce-Setup werden daher ab einem gewissen Punkt nicht mehr ohne automatisierte Tests auskommen.

Dennoch: Die zentrale Steuerung hat in der Regel mehr Vor- als Nachteile, wenn es z.B. um die Kosten für den Einsatz und die laufende Pflege geht.

Vergleichbares Tagging

Ein weiterer Vorteil ist die Vergleichbarkeit von Daten, die in verschiedenen Analytics-Properties anfallen können. Dies mag im oben genannten überschaubaren Beispiel nicht sehr relevant sein... bei einem größeren Verbund von Standorten innerhalb einer Unternehmensgruppe gewinnt dieser Vorteil jedoch schnell an Bedeutung. Vergleichbare Zahlen in Reportings zu generieren, kann bei einer heterogenen Tagging-Struktur schnell zu einer echten Herausforderung werden. Ein sorgfältig implementiertes zentrales Tagging kann hier wahre Wunder bewirken.

Wann lohnt sich das? Anwendungsbeispiele

Nicht alle Szenarien lassen sich mit einem Multi-Site-Container gut bewältigen. Technisch ist der Weg zwar immer der gleiche, aber vor allem der Aufbau und die laufende Wartung können unter bestimmten Bedingungen zu einer Belastung werden, die den Nutzen übersteigt. Die folgenden Abschnitte zeigen auf, wo sich der Einsatz in der Regel lohnt.

Cross-Domain Tracking

Wenn mehrere Websites die gleiche Analytics-Property mit Daten füttern und ggf. sogar alle weiteren Trackingdaten am Ende in den gleichen Pools bei Meta, Google und Microsoft Ads etc. landen, ist ein gemeinsamer Container meist die bessere Lösung. Zumal in diesem Szenario nicht einmal unterschiedliche IDs verwendet werden müssen, sondern Standard-Tags für Seitenaufrufe und Basis-Tagging der typischen Tracking-Dienste auf allen beteiligten Sites gleich ausgespielt werden können.

Selbst bei unterschiedlichen “Website-Typen” ist in der Regel wenig Aufwand für das Auslösen von Tags zu erwarten. E-Commerce-Ereignisse finden vielleicht nur auf einer der beteiligten Seiten statt, aber das ist in der Regel kein Problem, da die entsprechenden Trigger nur dort im dataLayer stattfinden und die zugehörigen Tags den “Tracking-Betrieb” auf den anderen Seiten nicht stören.

Lediglich die Ermittlung von Werten für benutzerdefinierte Dimensionen kann sich in diesem Anwendungsfall als Hürde erweisen, da Informationen wie z.B. der Seitentyp in einer heterogenen Systemlandschaft selten an der gleichen Stelle im dataLayer zu finden (oder überhaupt vorhanden) sind. Daher kann es notwendig sein, verstärkt mit Regex- und Suchtabellen zu arbeiten, die erst an der einen und dann an der anderen Stelle suchen, um einen Wert zu ermitteln.

Gleiches gilt übrigens auch für die wesentliche Aufgabe, den Consent Status auf allen beteiligten Seiten auszulesen und beim Tagging zu berücksichtigen. Sind hier unterschiedliche Consent Management Systeme im Einsatz, kann der Aufbau eines Multi-Site-Containers knifflig werden und erfordert in der Regel individuelle Lösungen über JavaScript-Variablen und andere Hilfsmittel, um bei allen Sites nur dann Tags auszulösen, wenn dies erlaubt ist.

Gleichartige Websites

Vergleichsweise einfach ist die Nutzung, wenn zwar eine größere Anzahl von Websites existiert, diese aber alle einem ähnlichen Zweck dienen und idealerweise mit dem gleichen CMS und Template (zumindest strukturell) betrieben werden. Ein Verbund von internationalen Online-Shops, Portalen oder Blogs in verschiedenen Sprachen und auf eigenen länderspezifischen Domains bedient zwar in der Regel jeweils unterschiedliche Analytics-Properties und Werbekonten, ist aber ansonsten technisch identisch und hat in der Regel ähnliche Anforderungen an ein Tracking-Setup. Unter der Voraussetzung, dass sich die Mehrsprachigkeit nicht in den Tracking-Daten widerspiegeln muss (wie bei Eventnamen oder Parameterwerten), ist ein Multi-Site-Container eine gute Lösung. Solange die anderen Rahmenbedingungen stimmen.

Überschaubare Anzahl an Sonderlösungen

So ist es zwar üblich, dass es in solchen Setups Tags gibt, die nur auf einigen oder nur auf einer der nutzenden Sites gespielt werden sollen, aber deren Anzahl muss sich in einem gewissen Rahmen bewegen, damit der Container übersichtlich und “wartbar” bleibt.

Auch ein Übermaß an Tags, Variablen und Triggern, die nur einer Site dienen, kann hinderlich sein, wenn dafür 99 weitere Sites die Last “mittragen” müssen. Stichworte wie Ladezeiten und Minimierung der Browserlast kommen hier ins Spiel. So kann es im Extremfall sogar vorkommen, dass ein ursprünglich sinnvolles Multi-Site-Setup so unausgewogen wird, dass es in mehrere Teile zerlegt oder einzelne Sites aus dem Container “entlassen” und mit einem eigenen GTM versorgt werden sollten.

Auch bei technisch unproblematischen Konstellationen kann es administrativ zu komplex werden, wenn die “Nutzerlandschaft” vielfältig ist.

Verantwortung, Zugriff und Pflege

Solange es nur wenige Personen (oder zumindest Abteilungen im Unternehmen) gibt, die für die Pflege des Tagging verantwortlich sind, und es eine gemeinsame Dokumentation und einen einigermaßen stabilen Prozess für Änderungen gibt, können mehrere Parteien zum Setup beitragen. Beispiele sind die Aufteilung der Verantwortung zwischen der internen IT, dem Marketing und einer externen Agentur.

Mit zunehmender Anzahl von Unternehmen, Ländern, Sprachen, externen Dienstleistern und ggf. “lokal relevanten” Tags steigt sowohl der administrative Aufwand als auch das Risiko unerwünschter Nebeneffekte von Anpassungen. Selbst bei einer zentralen und gut organisierten Qualitätssicherung ist das Handling in einem international agierenden Konzern z.B. dann problematisch, wenn in jedem Land eigene Agenturen an der Entwicklung und/oder dem Tagging der jeweiligen Websites beteiligt sind. Hier auf einen gemeinsamen Google Tag Manager Container umzusteigen, mag mit “Zones” in einem 360 Account noch realistisch sein, so dass verschiedene abgeschottete Teile existieren.

In allen anderen Fällen ist es immer noch möglich, einen Teil des Taggings zu zentralisieren und alles, was den nutzenden Websites gemeinsam ist (wie z.B. ein gemeinsames "Analytics Base Tagging"), aus den einzelnen GTM Containern auszulagern und in einen gemeinsamen Container zu implementieren, der dann von den lokalen Tag Managern nachgeladen wird.

Kompromiss: “Basis-Tracking” zentralisieren

Was auf den ersten Blick kompliziert erscheinen mag, führt letztlich dazu, dass zumindest für Analytics die oben genannten vergleichbaren Zahlen generiert werden können, ohne den “Local Heros” und ihren Agenturen den eigenen Tag Manager wegzunehmen.

Ein gemeinsamer Basis-Tagging-Container kann im Prinzip wie ein normaler Multi-Site-Container aufgebaut werden, nur dass er nicht direkt in die Website eingebunden wird (zumindest nicht als alleiniger Tag Manager), sondern aus einem bestehenden Container nachgeladen wird. Alle individuellen Einstellungen wie Dimensionswerte, IDs für Tags und Pixel sowie andere Initialisierungsinformationen werden dann zunächst vom “ladenden Container” in den dataLayer geschrieben und dann der gemeinsame Basiscontainer nachgeladen.

Sollen auf einzelnen Websites individuelle Events genutzt werden, die über den Standardumfang hinausgehen, so können diese entweder direkt in den lokalen Containern implementiert werden oder (besser!) es wird ein “Communication Layer” zwischen lokalem Container und zentralem Multi-Site-Container vereinbart und genutzt, der den Wunsch, ein bestimmtes Event zu messen, vom Format des eigentlichen Tracking-Dienstes entkoppelt.

Abstraktion von Tracking-Ereignissen

Dies kann so aussehen, dass der lokale Container bei einem “Analytics Event” alle notwendigen Daten zum Event in den dataLayer schreibt und dabei einen bestimmten Event-Namen im dataLayer verwendet, der im zentralen Container als Trigger dient und dann mit den im dataLayer gespeicherten Informationen zum Event z.B. ein GA4-Event macht, anstatt dass der lokale Container direkt ein GA4-Event enthält und “selbst feuert”.

Bei der Verwendung im lokalen GTM macht dies kaum einen Unterschied. Statt eines GA4 Events (um bei diesem Beispiel zu bleiben) wird ein anderer Tag-Typ verwendet, um den Namen und die Eigenschaften des Events in den dataLayer zu schreiben.

Diese Art der Implementierung hat (nicht nur) den Vorteil, dass das Basis-Tagging weiterhin zentral betrieben und gepflegt werden kann, ohne dass die Tagging-Anforderungen einzelner Websites, bestehende Prozesse oder sonstige Rahmenbedingungen angepasst werden müssen. Vielmehr wird damit eine Abstraktionsschicht zwischen dem (lokalen) Tag Manager und der Analytics-Implementierung geschaffen. Vorteil: Soll GA4 einmal durch ein anderes Tool ersetzt oder durch ein “paralleles Tool” ergänzt werden, so kann dies an einer Stelle geschehen, ohne dass x einzelne lokale Container überhaupt angefasst werden müssen. Daher spielt diese Variante ihre Stärken gerade in Konstellationen aus, in denen die Unterschiede in der Nutzung und den IT-Rahmenbedingungen der jeweiligen Websites dominieren und vergleichsweise viele Websites mit Tracking versorgt werden sollen.

Auch bei unterschiedlichen Einwilligungsmanagern wird durch das Hinzufügen der Einwilligungslage in der "Abstraktionsschicht" sichergestellt, dass der Multi-Site-Container immer auf die gleiche Weise erkennt, was erlaubt und was verboten ist. Alternativ wird der Multi-Site-Container überhaupt nur geladen, wenn eine Einwilligung für den darin enthaltenen Dienst vorliegt - was allerdings die Nutzung auf ein Tool beschränkt und z.B. das Ausspielen von “Ersatz-Webanalyse ohne Einwilligung” bei fehlender Einwilligung für Google Analytics ausschließt.

Aufwand für QA nicht unterschätzen!

Welche Lösung auch immer gewählt wird: Ein Multi-Site-Container erfordert im Echtbetrieb vor allem eine gute und stets aktuelle Dokumentation sowie besondere Sorgfalt bei Anpassungen. Auf dem Weg zur Veröffentlichung einer Änderung muss an einer Stelle sinnvoll entschieden werden, welche Auswirkungen zu erwarten sind und wie umfangreich ein Test sein muss, bevor eine neue Version live gehen kann.

Dabei sind verschiedene Faktoren zu berücksichtigen:

• Werden komplett neue Tag-Typen verwendet oder wird nur ein weiterer Event-Tag zu einem bereits verwendeten Service hinzugefügt?
• Kommt benutzerdefiniertes JavaScript zum Einsatz?
• Erfolgt die Ausspielung auf allen oder nur auf einzelnen Seiten?
• Wie “stabil” und eindeutig sind die Trigger-Bedingungen, unter denen ein neuer Tag ausgeführt werden soll?

Bevor man sich also an die Umsetzung macht, muss sorgfältig geplant werden, welche Rollen und Verantwortlichkeiten wie zu verteilen sind - eventuell auch abweichend vom aktuellen Stand. "Einzelentscheidungen" sind hier besonders kontraproduktiv, da Widerstände zum Scheitern des gesamten Konzepts führen können. Daher sollte ein solches Projekt - wie jedes andere auch - mit allen Beteiligten kommuniziert, gesteuert und abgestimmt werden.

Umsetzung in Google Tag Manager

Der Unterschied zwischen einem “normalen” GTM-Container und einem Multi-Site-Container besteht häufig darin, dass pro Hostname oder Domain unterschiedliche IDs verwendet werden sollen. Am Beispiel der Measurement ID, die in einem Multi-Site-Container auf drei verschiedenen Domains verwendet werden soll, kann dies in Form einer einfachen Suchtabellen-Variable geschehen:

Hierbei wird für verschiedene Hosts aus Domain 1 bis Domain 3 die jeweilige Measurement-ID für GA4 anhand des Wertes der Variablen “Page Hostname” ermittelt. Wird keine Übereinstimmung gefunden, landen die Daten in einer vierten, als Default definierten Property, in der z.B. Traffic aus Staging-Umgebungen gesammelt werden kann.

Wem diese Konstruktion (egal ob als Suchtabelle oder Regex-Tabelle) bekannt vorkommt, liegt richtig: Viele Container für einzelne Websites nutzen diese Möglichkeit bereits, um Developer-Traffic nicht in der normalen Property für Filter zu markieren, sondern direkt in eine separate Property zu schicken. Mit genau dem gleichen Schema können auch mehrere Websites mit einer vom “verwendenden Host” abhängigen ID versorgt werden. Nicht nur für GA4 IDs, sondern auch für IDs anderer Services, Conversion-Labels, Cookie-Namen und andere Parameter, die von der jeweiligen Domain abhängen.

Wenn diese Variablen konsequent überall dort verwendet werden, wo sonst IDs fest in Tags etc. eingetragen werden, kann derselbe Container auf allen Websites, die von den jeweiligen Suchtabellen abgedeckt werden, die gleiche Vermessungsarbeit nutzen.

Datenschicht als ID-Quelle

Eine Alternative zur Erkennung anhand des Hostnamens ist die Kommunikation der jeweiligen IDs durch die verwendende Website selbst. Zum Beispiel per dataLayer. Diese Methode ist aus Sicht des Tag Managers pflegeleichter und erlaubt das Onboarding neuer Domains ohne neue Containerversion. So verlockend diese Alternative auch erscheinen mag, so schwierig ist die Umsetzung in einer heterogenen CMS-Landschaft. Laufen hingegen alle Websites auf der gleichen Basis (und immer in der gleichen Version), kann ggf. die gesamte “Initialisierungsarbeit” auf diese Weise vom CMS übernommen werden.

Völlig gleichartige Setups lassen sich mit diesem Konzept relativ einfach realisieren. Auch deren Pflege hält sich in Grenzen - selbst dann, wenn z.B. nur für einzelne Websites oder Teile einer einzelnen Website Ausnahmen gelten. Dies kann z.B. ein Google Ads-Tag sein, das nur für bestimmte Sites relevant ist.

Sonderregelungen für einzelne Domains

Hierfür bieten sich beispielsweise blockierende Trigger an, die das Auslösen von Google Ads Remarketing-Tags verhindern, wenn für die aktuelle Domain keine passende Google Ads Konto-ID in der Suchtabelle gefunden wurde.

Das Beispiel zeigt einen solchen Trigger, der Ereignisse aller Art (Seitenaufrufe, benutzerdefinierte Ereignisse, Klicks oder andere Trigger-Typen) abfangen kann, indem er auf den regulären Ausdruck “.*” prüft, wann immer der Wert der Google Ads ID undefiniert ist.

Alternativ können entsprechende (zusätzliche) Bedingungen in die auslösenden Trigger aufgenommen werden. Tipp: Bei Variablen, für die es keinen Default-Wert gibt, wie z.B. die oben gezeigte Measurement-ID einer Sammel-Property, kann ein Default-Wert “NONE” als Text solche Bedingungen nicht nur besser lesbar machen, sondern würde auch bei Ergebnissen wie “null” oder leeren Strings im dataLayer (falls dies die Quelle der IDs sein sollte) für eine zuverlässigere Blockierung sorgen.

Das Vorhandensein einer für ein Tag benötigten ID kann somit als weitere Bedingung in das Trigger-Konzept aufgenommen werden - so wie zuvor schon bestimmte dataLayer-Events, CSS-Klassen bei Klicks, Übereinstimmungen in Seitenpfaden oder entsprechende Consent-Bedingungen.

Bei Bedarf kombiniert mit Bedingungen, die nur vom aktuellen Hostnamen abhängen, kann so ein bestehendes “Single-Site”-Trigger-Konzept mit vertretbarem Aufwand auf Multi-Site-Betrieb umgestellt und gepflegt werden.

Fazit

Ein Multi-Site-Tagging-Konzept kann, wie gezeigt, wesentliche Vorteile beinhalten und ist überall dort ein potenzieller Gewinn, wo mehrere Websites “aus einer Hand” mit Tracking versorgt werden. Die Vermeidung von Fragmentierung, die Einsparung von Zeit und Ressourcen und die Vergleichbarkeit der Ergebnisse in Zahlen sind in der Regel gute Gründe genug. Zumindest solange Aspekte wie Internationalität, Zeitzonen, Agenturlandschaft, Historie oder “Mix-Setups” aus teilweise direkt eingebauten und per Tag Manager nachgerüsteten Tags keine allzu großen Hürden darstellen.

Selbst der Einsatz unterschiedlicher Consent Manager muss kein Hindernis sein, solange die Tracking-Anforderungen selbst ähnlich genug sind, um den Aufbau eines gemeinsamen Containers zu rechtfertigen. Wer gerade sein Tagging von Universal Analytics auf GA4 umgestellt hat, wird den Aufwand für den Aufbau eines Multi-Site-Containers vermutlich scheuen. Aber: Spätestens beim nächsten Systemwechsel könnte es sich lohnen 😉