Mit der Einführung des Google Tag Manager (GTM) Server-Containers ermöglicht Google eine neue Art der Datenerhebung und Datenverarbeitung. Themen wie Data Ownership sowie völlige Kontrolle über aggregierte Daten und ihre Qualität klingen vielversprechend. Doch mit neuen Möglichkeiten wachsen auch die Anforderungen an Nutzer und deren Verantwortung im Umgang mit den erhobenen Daten.

Themen wie Consent Management, Datenschutz und Modellierung der Daten werden nicht mehr clientseitig geregelt, sondern liegen in alleiniger Verantwortung des GTM Servers. Der folgende Blockbeitrag soll daher einen Einblick in die Funktionsweise des serverseitigen Trackings mit seinen Vor- und Nachteilen geben, um eine Entscheidungsgrundlage für einen Wechsel auf einen GTM Server zu schaffen.

1. Funktion und Unterschiede

Um einen optimalen Einstieg in das Thema zu finden, werden in den nachfolgenden Abschnitten die Unterschiede der technischen Funktionsweise zwischen dem clientseitigen und serverseitigen Google Tag Manager-Container verdeutlicht und gegenübergestellt.

1.1 Client-Side GTM

Bei der Nutzung eines clientseitigen Google Tag Managers (GTM) wird dessen Container-Script in den HTML-Code der Website eingebunden. Dieser wird bei jedem Seitenaufruf mit allen Ressourcen geladen. Gerade Custom HTML Code, welcher oftmals für Tags von Third Party-Anbietern im Container eingerichtet wurde, wird bei jedem Seitenaufruf in den DOM der Webseite injiziert. Externe Ressourcen werden somit zusätzlich über den Browser auf der Website geladen.

① Seitenaufruf

Der Nutzer ruft die Seite https://mohrstade.com über einen Browser auf. Der Browser fragt dabei die Seiteninhalte und Ressourcen beim Webserver an.

② Auslieferung der Inhalte

Der Webserver liefert die angefragten Seiteninhalte und Ressourcen an den Browser aus. Die HTML-Seite wird anschließend vom Browser mit den bezogenen Informationen aufgebaut.

③ Initialisierung des GTM Containers

Der in der Website integrierte Web-Container des clientseitigen Google Tag Managers wird geladen. Dabei werden die Inhalte des Containers (gtm.js) beim Google Tag Manager Server (https:// www.googletagmanager.com/) angefordert.

④ Tags

Der clientseitige GTM sendet über im GTM Container eingerichtete Tags für jede Interaktion einen HTTP-Request an den zugehörigen Endpunkt des Tag-Vendors. Dabei wird der Request im Client selbst schon in das richtige Datenformat strukturiert.

1.2 Server-Side GTM

Mit dem GTM Server-Container lässt sich innerhalb eines Google Cloud Projektes ein eigener Daten-Endpunkt in einer Serverumgebung erstellen. Theoretisch befinden sich die Daten dann im eigenen Besitz. Das folgende Schaubild stellt den technischen Ablauf der Datenverarbeitung dar.

① Seitenaufruf

Der Nutzer ruft die Seite https://mohrstade.com über einen Browser auf. Der Browser fragt dabei die Seiteninhalte und Ressourcen beim Webserver an.

② Auslieferung der Inhalte

Der Webserver liefert die angefragten Seiteninhalte und Ressourcen an den Browser aus. Die HTML-Seite wird anschließend vom Browser mit den bezogenen Informationen aufgebaut.

③ Initialisierung des GTM Containers

Der in der Website integrierte Web-Container des clientseitigen Google Tag Managers wird geladen. Dabei werden die Inhalte des Containers (gtm.js) beim Google Tag Manager Server (https:// www.googletagmanager.com/) angefordert.

④ Tags (Clientseitig)

Der auf der Seite geladene GTM Client enthält Tags, welche die Aufgabe besitzen, fortlaufende Interaktionen auf der Website an den Server-Container zu senden. Hierfür wird das Feld Transport-URL des Universal Analytics-Tags mit der Endpoint-URL (https://ssgtm.mohrstade.de/) des Server-Containers überschrieben. Fortlaufende Hits werden von nun an direkt an den eingerichteten GTM Server gesendet. Können alle Daten innerhalb eines Tags abgebildet werden, lässt sich die Kommunikation zwischen Client und GTM Server auch auf einen Datastream reduzieren.

⑤ Datastream

Über die im clientseitigen Container enthaltenen Tags entsteht ein Datastream, welcher alle ausgehenden Hits (HTTP-Requests) an den Endpunkt des GTM Server übermittelt.

⑥ Clients

Innerhalb des Server-Containers lassen sich sogenannte Clients konfigurieren, die als eine Art Listener auf eingehende HTTP-Requests warten, um sie anschließend in ein einheitliches Event-Format zu übersetzen. Dabei lassen sich mehrere Clients für bestimmte Formate und Vendoren definieren. Die Clients führen dann einen virtuellen Container mit dem Event-Objekt aus, in dem Tags, Trigger und Variablen auf das Event reagieren. Ähnlich wie beim clientseitigen GTM.

⑦ + ⑧ Tags (Serverseitig)

Die unterschiedlichen Tags strukturieren die Daten in das benötigte Format und senden den HTTP-Request an ihre jeweiligen Endpunkte. Anschließend spielt der Client eine HTTP-Status-Message zurück an die ursprüngliche Datenquelle.

Der Prozess zeigt, dass der GTM Server als eine Art Proxy zwischen den vom Browser gesendeten HTTP-Requests und dem eigentlichen Daten-Endpunkt der zugehörigen Tools steht. Der GTM Server selbst arbeitet dabei als HTTP-API-Endpunkt, an den jeder Browser, jedes Gerät oder jegliche andere HTTP- fähige Datenquelle Anfragen stellen kann.

Idealerweise wird dieser Endpunkt durch eine Subdomain in derselben Domänenhierarchie abgebildet wie die Website, die die Requests sendet. In diesem Beispiel wird der Request von mohrstade.de an unseren GTM Server auf ssgtm.mohrstade.de gesendet. Dieses Vorgehen impliziert eine Weiterverarbeitung der Anfrage im First Party-Kontext, was sich wiederum erheblich darauf auswirkt, wie Cookies gespeichert und gelesen werden können/dürfen. Zudem kann der serverseitige Google Tag Manager Cookies serverseitig setzen. Browser wie Safari begrenzen die Laufzeit von clientseitig (durch JavaScript-Code) gesetzten Cookies, während dies nicht für serverseitig gesetzte Cookies gilt. So kann beispielsweise der serverseitige Client für Google Analytics im Safari Browser das zur Wiedererkennung genutzte FPID (= First Party Identifier) Cookie serverseitig für 24 Monate setzen, während dies clientseitig im Safari Browser aktuell nur für sieben Tage möglich ist.

2. Vorteile

Die Einführung eines GTM Servers bietet, wie bereits beschrieben, einige Vorteile. Neben der Kontrolle über Daten und ihrer Datenqualität bietet die Einführung eines serverseitigen Trackings auch Vorteile für den Nutzer und die allgemeine Website-Performance. In den folgenden Abschnitten wird daher expliziter auf die genannten Punkte eingegangen.

2.1 Entlastung des Clients

Ein wesentlicher Vorteil des GTM Servers ist die browserseitige Entlastung des Clients durch zusätzliches Third Party-JavaScript. Wie im vorherigen Abschnitt beschrieben, besteht die Aufgabe des clientseitigen GTM darin, die einzelnen Skripte diverser Vendoren auszuführen, sobald diese getriggert werden. Dies sorgt dafür, dass eine Vielzahl an Requests an unterschiedliche Daten-Endpunkte gestellt werden, mit denen der Browser kommunizieren muss. Es existieren also mehrere ausgehende Datenströme.

Mithilfe des serverseitigen GTM, findet dieser Schritt jedoch erst im Client des GTM Servers statt. Der Server lässt sich so konfigurieren, dass jede eingehende HTTP-Anfrage in das vom Vendor benötigte Format abgebildet wird. Theoretisch lässt sich so die gesamte Last durch Marketing-Pixel und anderem Third Party-JavaScript auf einen einzigen Datastream reduzieren, der als Endpunkt den GTM Server ansteuert.

2.2 Kontrolle und Datenqualität

Der GTM Server dient wie erwähnt als eine Art Schnittstelle zwischen Browser/Gerät und Daten-Endpunkt. Jeder Request wird vor der Weiterleitung von dem GTM Server verarbeitet. Dabei können die Daten vor Weiterleitung beliebig konfiguriert werden.

Daten wie die IP Adresse des eingehenden Request oder ein mitgesendeter User-Agent können vor der Weiterleitung entfernt werden. Für Google Analytics wird diese Möglichkeit bereits in den vordefinierten Tags angeboten. Damit bietet der serverseitige GTM die Möglichkeit der Anonymisierung bzw. Entfernung der IP Adresse des Clients, bevor der Request auf dem gewünschten Endpoint eingeht. Auch kann eine Prüfung und Entfernung von PII Daten auf dem serverseitigen GTM skalierfähiger erfolgen. Der serverseitige Google Tag Manager leistet daher auch einen nicht zu unterschätzenden Beitrag zum Datenschutz. Werden Third Party-Skripte nicht mehr auf der Webseite ausgeführt, sondern die Funktionalität über den Google Tag Manager abgebildet, ist mehr Kontrolle beim Setzen von Cookies (insbesondere Third Party-Cookies) gegeben. Hinzu kommt, dass volle Kontrolle darüber besteht, welche HTTP-Anfragen überhaupt von dem Server verarbeitet werden. Universal Analytics wurde oftmals Opfer von Spam-Traffic, wodurch die Validität und Aussagekraft der Daten beeinträchtigt war. Über den GTM Server kann dieses Problem vermieden werden, indem beispielsweise eine benutzerdefinierte Dimension ergänzt wird, die erst bei ausgehenden Requests am Server gesetzt wird.

2.3 First Party-Data und Ownership

Ist der GTM Server als zwischengelagerter HTTP-Endpunkt in der Lage, auf die eingehenden HTTP-Requests der Website als deren untergeordnete Subdomain zu antworten, agieren diese im sogenannten “Same-Site“ oder auch “First Party-Kontext“ miteinander. Dies hat wiederum einen erheblichen Einfluss darauf, wie die erhobenen Daten verarbeitet und von Tracking-Blockern behandelt werden. Die eigentliche Verarbeitung und Zuordnung der HTTP-Anfrage geschieht nicht mehr clientseitig, wodurch die Datenkommunikation nicht mehr im direkten Third-Party Kontext steht. Neben dem Kontext der Datenverarbeitung spielt also auch der Punkt “Data Ownership“ eine zentrale Rolle in der Nutzung eines GTM Servers.

2.4 Entlastung der Content Security Policy

Einen weiteren Vorteil der Reduzierung der Anzahl von HTTP-Endpunkten, mit denen der Browser kommuniziert, betrifft die Content Security Policy (CSP) der Website. Eine CSP regelt und beschränkt HTTP-Verkehr zum und vom Browser/Gerät des Benutzers. Wenn Third Party-JavaScript (Bsp.: Facebook Pixel etc.) implementiert wird, welches Inhalte aus einer externen Datenquelle auf der Website lädt, muss die CSP vom Entwickler angepasst werden, damit das Script Daten vom Browser des Benutzers senden und empfangen darf. Je mehr Third Party-JavaScript verwendet wird, desto ineffizienter wird die CSP und deren Performance. Indem die Anzahl der HTTP-Endpunkte durch den Einsatz des GTM Servers reduziert wird, muss der Browser mit weniger Endpunkten kommunizieren, wodurch die Stabilität der CSP gewährleistet wird.

3. Nachteile

Neben den vielversprechenden Vorteilen, die ein server- seitiges Tracking von Daten mit sich bringt, gibt es dennoch einige berechtigte Kritikpunkte und Nachteile, die beachtet werden sollten, wenn man sich für die Einrichtung eines GTM Servers entscheidet. Der folgende Abschnitt befasst sich mit den wesentlichen Kritikpunkten am Einsatz des GTM Servers.

3.1 Consent Management

Spätestens seit Inkrafttreten der DSGVO ist Consent Management ein heiß diskutiertes Thema. Website-Betreiber sind seit- dem verpflichtet, die explizite Einwilligung des Nutzers für die Erhebung und Weiterverarbeitung seiner Daten einzufordern und greifen daher oftmals auf rechtlich standardisierte Consent Management-Tools zurück.

In den meisten Fällen wird die Zustimmung hierbei in einem Cookie oder Eintrag im Local Storage des Browsers gespeichert. Wird ein GTM Server als Endpunkt zwischengeschaltet, besteht jedoch die Möglichkeit, einen einzigen Data Stream für die HTTP-Requests zu definieren. Jegliche Art von Anfrage wird clientseitig somit an einen Endpunkt gestellt, welcher im Idealfall im Same Site-Kontext mit der Website agiert. Dieser Data Stream kann im Server-Container wiederum in dutzende Marketing- und Analytics-Requests aufgeteilt werden.

Die Client-Templates im GTM Server-Container können jedoch keine clientseitigen Consent-APIs nutzen, wie sie von TCF 2.0 rechtlich vorgeschlagen werden.

3.2 Umgehen von Tracking Blockern

Browser-Anbieter fokussieren sich fortschreitend auf die Privatsphäre ihrer Nutzer und deren Datenschutz. Standardeinstellungen in Browsern wie Firefox oder Safari verhindern mittlerweile per default ein Tracking durch Drittanbieter. Hinzu kommen zahlreiche Browser Plug-Ins/Add-ons (Bsp. Ghostery) welche ein domainübergreifendes Tracking im Third Party-Kontext grundlegend blockieren. Die etwaige Zustimmung für die Weiterverarbeitung der Nutzerdaten wird somit dem eigentlichen Consent Management bevormundet und übergangen.

Die Blockierung durch standardmäßige Browsereinstellungen beruht hierbei unter anderem auf vordefinierten Listen (Bsp. disconnect.me), welche bekannte Tracker identifizieren, aber auch algorithmisch und gerätespezifisch, wie bei der Intelligent Tracking Prevention (ITP). Browser Plug-Ins/Add-ons blockieren hingegen lediglich Anfragen an bekannte HTTP-Endpoints (z.B. google-analytics.com/collect).

Verwendet man nun einen eigenen GTM Server als Endpunkt (Bsp. ssgtm.mohrstade.de), welcher dem eigentlichen Dat- en-Endpunkt als Mittelsmann dient, greift die beschriebene Klassifizierung-Logik von Browser-Anbietern und Browser-Erweiterungen nicht mehr. Bis dato wird somit ein missbräuchlicher Einsatz ermöglicht, was jedoch keinen Anreiz zur Verwendung eines GTM Servers geben sollte. Auf der anderen Seite wird es allerdings nur eine Frage der Zeit sein, bis Browser-Anbieter und bekannte Tracking-Blocker die zugrunde liegende Heuristik anpassen.

3.3 Kosten

Der Server-Container lässt sich zur Zeit nur auf der Google Cloud Plattform einrichten. Hier ist zu beachten, dass laufende Kosten für die Nutzung entstehen.
Die Kosten des serverseitige Google Tag Managers setzen sich im Wesentlichen aus zwei Positionen zusammen:

Minimale Instanzen

Minimale Instanzen beschreiben das Minimum an dauerhaft aktiven Instanzen auf dem GTM Server. Zwar verfügt die Google Cloud Platform über Auto Scaling-Funktionalitäten, um jedoch sicherzustellen, dass bei sprunghaftem Anstieg des Traffics genügend Kapazitäten zur Verfügung stehen, können beispiels- weise 3 Instanzen dauerhaft online gestellt werden. Die Performance und ebenfalls das Auto Scaling hat sich seit Einführung des serverseitigen Google Tag Manager deutlich verbessert, so- dass eine geringe Anzahl von Instanzen ~3 normalerweise aus- reichend für den Traffic einer normal besuchten Webseite ist.

Als Anhaltspunkt kann eine Abwägung anhand der Google Analytics Requests dienen:

Universal Analytics – ca. 35 Request/Sek.

Google Analytics 4 – ca. 20 Requests/Sek.

Maximale Instanzen

Mit den maximalen Instanzen kann festgelegt werden, wie viele Instanzen höchstens durch das Auto Scaling aktiviert werden dürfen. Ist die Last höher als die mögliche Last, die von den maximalen Instanzen abgearbeitet werden kann, kann die Bearbeitung und Weiterleitung der Requests nicht mehr gewährleistet werden.

Die Kosten der Instanzen können variieren. Als Orientierung können Kosten pro Instanz mit ca. 40 bis 50 USD pro Monat angesetzt werden.

3.4 Intransparenz

Die bereits genannte Möglichkeit, diverse HTTP-Requests anhand eines ausgehenden Data Streams abzubilden, macht es schwer nachvollziehbar, welche Verwendung die Daten letztendlich finden, da sie alle auf den gleichen Endpunkt verweisen. Im Server-Container können die Requests von Clients anschließend umstrukturiert und an die jeweiligen Endpunkte der Anbieter versendet werden. Dieser Schritt ist jedoch nicht mehr transparent für den Nutzer und liegt außerhalb dessen Einfluss. Umso wichtiger wird die Transparenz und Dokumentation darüber, was genau dort passiert und an welche Plattformen und Tools die Daten übergeben werden.

3.5 Know-how

Bereits die Nutzung eines clientseitigen GTM setzt gewisse Kenntnisse im Umgang mit gängigen Web-Technologien wie HTML, CSS und JavaScript voraus. Mit der Verwendung einer eigenen Server-Umgebung zur Datenaggregation und Datenkonfiguration entstehen jedoch zusätzlich wesentlich komplexere technische Aufgaben und Anforderungen an Nutzer. Einen zentralen Punkt stellt hierbei die benutzerdefinierte Konfiguration der Clients dar.

4. Empfehlung

Der serverseitige Google Tag Manager bietet aktuell bereits einige interessante Vorteile in Bezug auf Tracking und Datenschutz Features. Die Verfügbarkeit von Clients und Templates für Tags und Variablen ist aktuell recht begrenzt. Allerdings ist die Möglichkeit, diese selbst zu entwickeln oder von den Vendoren bereitgestellt zu bekommen, ein Kernbestandteil des serverseitigen Google Tag Managers. Die Bereitstellung von Tags durch Vendoren wird derzeit schon intensiv genutzt. Beispielsweise hat Facebook ein Tag für die Facebook Conversion API in der Tag Template Gallery des Tag Managers bereitgestellt. Zudem bietet der serverseitige Google Tag Manager nicht nur die Möglichkeit, die Daten an einen Vendor zu versenden, sondern diese auch direkt in einen BigQuery Table zu schreiben.

Es ist davon auszugehen, dass der serverseitige Einsatz des Google Tag Managers in Zukunft an Bedeutung gewinnen wird. Daher ist es empfehlenswert, sich schon jetzt mit der Funktionsweise vertraut zu machen und erste (parallele) Tests zur Nutzung im Rahmen eines produktiven Setups zu planen.

Dieser Beitrag steht Ihnen ebenfalls in hochwertiger Form eines Whitepapers als PDF zum Download zur Verfügung.

Zum Whitepaper