Server-side Google Tag Manager - Einführung

In diesem Beitrag geht es darum, wie der Server-side Google Tag Manager im Vergleich zum Standard Client-side Google Tag Manager funktioniert und welche Unterschiede es gibt. Der Artikel soll Einstieg in das Thema bieten und die Vor- und Nachteile des Server-Containers beleuchtet.

#Client-side GTM erklärt

Zunächst schauen wir uns einmal wie Client-Side Tracking im GTM auf einer Website funktioniert. Eine typische Konfiguration nutzt einen Container (ein Stück JavaScript Code-Snippet), der auf der Seite integriert wurde. In diesem Container werden dann alle Tracking-Codes geladen, z. B. Google Analytics, Google-Ads Conversion oder sonstige Third Party Tags. Sobald diese Tags vom GTM in die Website injeziert bzw. geladen wurden, senden die Tags fleißig Daten an den Server des Anbieters. Wenn der Tag im Webbrowser direkt mit dem Endpunkt eines Drittanbieters, z. B. Facebook, Google Ads, etc kommuniziert, können die versendeten Daten eine Menge Informationen enthalten, z.B. welcher Browser, Browser-Version, Betriessystem, Fenstergröße, IP-Adresse, und viel mehr. Das können Daten sein, die der Besucher oder das Unternehmen entweder gar nicht senden wollte oder von denen die Personen (Besucher und Unternehmen) gar nichts mitbekommt.

Das genau ist das Problem, welches Tracking Prevention und GDPR vorgebracht hat. Der Browser der Besucher wird mit 3rd Party Tracking Codes belastet, diese können z.B. über piggy backing, fremden Code reinladen und diese Daten dann an weitere Dritte senden. Viele wissen nicht, was eigentlich der Code macht, der integriert wurde. Das kann tatsächlich zu einem Haftungsrisiko werden.

Auch die Tatsache, dass die meisten Anbieter keine böswilligen Praktiken haben, ist irrelevant. Wichtig ist, dass das Potenzial vorhanden ist, ohne dass der Benutzer oder das Unternehmen es wissen, eine Menge Daten anhäufen können, die gar nicht erst hätten gesammelt werden dürfen.

#Server-side GTM erklärt

Jetzt aber zum Server Side Tagging. Der große Unterschied ist, der serverseitiger Endpunkt führt eine zusätzliche Kontrollebene über alle Datenströme, zwischen dem Besucher, Unternehmen und dem Anbieter.

Man kann den serverseitige Container als einen Staging-Bereich betrachten. Ein Staging-Bereich oder eine Landing Zone für die Daten, der für die Datenverarbeitung während des ETL-Prozesses (Extrahieren, Transformieren und Laden) verwendet wird.

Ohne diesen Staging-Bereich würden all diese Datenströme unkontrolliert von Quellen (Browser, Mobilgerät) zu potenziell gefährlichen Endpunkten fließen.

Wie sieht das Ganze nun aus? Der Client-Side Container wird weiterhin verwendet, hinzukommt aber der Server-Side GTM Container. Im Idealfall hat man nur noch ein einzelnes Tag z. B. den Google Analytics 4, dieser sendet Daten an den Server in die Cloud, also nicht mehr direkt an Google Analytics oder irgendeine 3rd Party Anbieter. Großer Vorteil, dass ganze bleibt im First Party Kontext. Im Server-Side GTM nimmt ein sogenannter Client die Daten entgegen. Ein Client ist eine Komponente, diese nimmt den Datenstrom entgegen, und erstellt aus diesen eingehenden Datenstrom ein Event Data Object.

Clients sind Vermittler die den Datenstrom entgegen nehmen und aus diesen eingehenden Datenstrom ein Event Data Object erstellt. Damit lassen sich dann wie gewohnt Trigger und Tag nutzen.

Hier nochmal beides im Vergleich, diesmal mit Google Analytics zum Vergleich. Mit einem kleinen zusätzlichen Info, dass hier ein Cookie über den sGTM als First Party gesetzt wird, dies wird noch in einem anderen Artikel besprochen.

#Vorteile

Okay, jetzt haben wir das Konzept verstanden, aber warum benötigt man das? Warum ist das so wichtig und wertvoll für das Marketing, Analytics, etc. Schauen wir uns also einige Vorteile an.

• Performance. je nach Konfiguratino kann die JavaScript Last verringert werden, wenn man nur noch einen Client-side Tag nutzt, was dazu führt, dass die Seitenladezeit verringert wird, da die Last aus dem Browser auf den Server verlagern wird. Die Tags können dann über den Server versendet werden.
• Kontrolle der empfangenen Daten, die dann auf dem Server verarbeitet werden können, bevor diese dann an die Anbieter weitergegeben werden. Es können also keine Techniken, wie u.a. Fingerprinting verwendet werden. Zusätzlich kann man das Risiko von PII-Lecks reduzieren oder vermeiden, da diese erst rausgefiltert werden, bevor sie an den Drittanbieter versendet werden.
• Separierung. Websites und Apps werden so von Tracking-Systemen „entkoppelt“.
• Werbeblockern umgehen. Mit serverseitigem Tagging kann man eine benutzerdefinierte Subdomäne erstellen, an die die Daten gesendet werden, z. B. data.domain.com. Am anderen Ende wartet ein Server-side GTM-Container auf die Daten. Sobald die Daten empfangen und verarbeitet wurden, sendet der Container die Daten weiter an Google Analytics.
• ITP/ETP umgehen. Wenn das Cookie Server-Side – also im First Party Kontext – gespeichert wird, so kann es mit, z. B. 2 Jahre Laufzeit konfiguriert werden.

#Nachteile

Und da wir über einige Vorteile gesprochen haben, gibt es auch einige Nachteile. Werfen wir also auch einen Blick auf diese.

• Kosten - Da die Hits auf einem Server auf der Google Cloud Platform gesammelt werden, verursacht das Kosten. Die Bereitstellung einer virtuellen Machine (VM) bedeutet im Wesentlichen, dass man Rechenleistung in der Google Cloud Platform mietet. Hier ist die Kostenstruktur etwas komplizierter, da in der Produktivumgebung, Server hinzugefahren werden können, um die Infrastruktur zu skalieren. Dazu hat Trakken einen Artikel geschrieben.
• Komplexität – Diese Technologie erfordert noch mehr technisches Wissen. Das Rabbithole in das man hinabsteigen muss, wird hier noch tiefer. Der Marketer muss noch mehr zu Entwickler werden.
• Fehlersuche – wegen der höheren Komplexität ist das Debuggen schwieriger. Externe Personen, z.B. von einer Agentur, könnte nicht sehen, was auf dem Server passiert, es sei denn, man gibt den Zugriff auf Ihren Google Tag Manager-Container oder den Vorschaumodus frei.
• Adaption – Server-side GTM sendet normalerweise an die Server von Google Analytics. Wenn eine vollständige Migration zu einer serverseitigen Implementierung angestrebt wird, werden Zeit und die Kosten zu einem Faktor. Möglicherweise muss darauf gewartet werden, dass bestimmte Anbieter ihre eigenen Vorlagen herausbringen, oder man muss Zeit und Geld von Entwicklung, Aktualisierung und Wartung von benutzerdefinierten Templates einplanen. -
• Client-Side Tracking wird nicht ersetzt. Man könnte es ersetzen, zum Beispiel man sendet alle die Daten mit einem selbsterstellten Code von der eignen Websites zum Server-side Container. Dadurch verliert man aber Flexibilität und verursacht auch hier Kosten, dafür gewinnt man Kontrolle.
• DSGVO sollte nicht umgangen werden, da es trotzdem das Einverständnis (Consent) des Besucher benötigt. Dabei spielt es keine Rolle, ob die Daten vom Server oder von der Kundenseite aus senden oder erfassen werden.