Server Side Tagging mit Google Tag Manager verstehen & einrichten

Was ist Server Side Tagging bzw. der Google Server Side Tag Manager?

Beim reinem clientseitigem Tagging werden integrierte Scripte von Domains der jeweiligen Diensteanbieter nachgeladen. Alle Daten werden direkt vom Client an die Diensteanbieter übermittelt.

Beim ssGTM werden stattdessen alle übermittelten Daten vom Client zunächst an den unter eigener Hoheit stehenden ssGTM Server gesendet. Und von dort erst an die einzelnen Dienste / Datenempfänger verteilt. 

Der weiterhin benötigte Client-Container sollte von eigenen Sub-Domains geladen werden, die im besten Fall unter eigener Kontrolle gehostet werden.

Die Verwaltung der Tags erfolgt – wie beim klassischen Google Tag Manager (Web Client) – über die Oberfläche bei Google.

Vorteile von Server Side Tagging & Unterschiede zum reinen Client Side Tagging

Server Side Tagging bietet gegenüber dem klassischen Client Side Tagging mit dem Google Tag Manager einige Vorteile. Diese fallen je nach Ausgangslage mehr oder weniger stark ins Gewicht.

Wichtigster Vorteil: Längere Cookielaufzeiten im Vergleich zu ITP beschränkten Cookies

Hinter dem Begriff Intelligent Tracking Prevention (ITP) verbirgt sich eine Reihe von Funktionen zum Daten- und Tracking-Schutz der Nutzer. Für das Online-Marketing bedeutet das vor allem verkürzte Cookie-Laufzeiten, welche die Erfolgsmessung (“Conversion-Tracking”) schwieriger machen.

ITP wird derzeit vor allem im Safari-Browser von Apple und im Firefox-Browser eingesetzt.

Mit Server Side Tagging lassen sich diese Beschränkungen umgehen. Die konkrete technische Umsetzung des Server Side Taggings bestimmt, ob und in welchem Umfang dies tatsächlich gelingt.

Die Laufzeit eines Cookies kann technisch normalerweise frei bestimmt werden. Längere Laufzeiten sorgen dafür, dass Nutzer (und deren Customer Journey) für eine längere Zeit wiedererkannt werden können. Kurze Cookie-Laufzeiten sorgen dafür, dass ein Nutzer potenziell und fälschlich als “viele Nutzer” in der Statistik auftaucht. 

Die Mechanismen von ITP verkürzen die vorgegebenen Cookie-Laufzeiten auf der übergeordneten Browserebene.

Dies ist gerade im Marketing für Produkte oder Dienstleistungen mit längeren Kaufentscheidungen oder vorgelagerten Rechercheprozessen problematisch.

Betroffene Cookies	Bedingung	verkürzte Lebensdauer des Cookies
Drittanbieter-Cookies (Third-Party)	keine / alle Drittanbieter-Cookies	7 Tage
Drittanbieter-Cookies (Third-Party)	wenn URL Abfrageparameter enthält (z.B. utm_source, gclid, fbclid)	24 Stunden
Drittanbieter-Cookies (Third-Party)	Safari-Browser	unterbunden
Erstanbieter-Cookies (First Party)	wenn Cookie mit CNAME-Cloaking gesetzt wird	7 Tage
Erstanbieter-Cookies (First Party)	wenn die IP-Adressen des cookie-setzenden Servers (z.B. ssGTM) und des Website-Servers nicht in der vorderen Hälfte identisch sind	7 Tage

Es ist damit zu rechnen, dass die hier dargestellten Regeln in Zukunft eher noch strenger werden.

Datenschutz und Datenhoheit

Die Struktur des ssGTM bietet deutlich mehr Kontrolle über die tatsächlich übermittelten Daten. Insbesondere können diese auf dem eigenen Server um kritische Merkmale (personenbezogenen Daten u.ä.) bereinigt werden.

Man muss – anders als beim rein clientseitigen Tagging – nicht allein darauf vertrauen, dass der Datenempfänger die Bereinigung vornimmt und kritische Daten verwirft. 

Darüber hinaus wird auch der (auch weiterhin benötigte) Client-Container in der Regel von einer eigenen Sub-Domain und von einem Hosting unter eigener Kontrolle geladen. Dieses datenschutzfreundliche Prozessdesign sorgt dafür, dass im Gegensatz zum Abruf des GTM-Containers von gooletagmanager.com keine technisch bedingte Weitergabe der (personenbezogenen) IP-Adresse an Google erfolgt.

Ad-Blocker und Tracking-Blocker umgehen

Man kann den ssGTM so konfigurieren, dass sowohl der GTM-Container (gtm.js) als auch Tracking-Requests (wie /collect/ für GA4) nicht von Ad-Blockern- und Tracking-Blockern blockiert werden. Im klassischen GTM ist dies nicht möglich.

Denkbar sind vor allem folgende Maßnahmen:

• die Auslieferung über eine andere Domain als googletagmanager.com (eigene Sub-Domains).
• die Umbenennung der gtm.js
• die Umbenennung von Tracking-Ressourcen (/collect/ bei GA4).

Ladezeit der Website und Ausführungslast im Client

Gerade, wenn viele Dienste per JavaScript im Client geladen werden, kann dies zu hoher Last auf dem Client (Endgerät) des Nutzers führen. Neben der reinen Ladezeit für die oftmals umfangreichen Tracking-Scripte entfällt beim Server Side Tagging auch die Verzögerung durch die Ausführung der Tracking-Scripte.

Sicherheitsaspekte: Wartung der Content Security Policy (CSP)

Durch den Wegfall der direkten Einbindung der Scripte in die Website sinkt auch der Pflege- und Wartungsaufwand für die Content Security Policy (CPS). Diese kann unverändert bleiben, wenn die Datenweitergabe nicht mehr vom Client an den Dienst, sondern in Hintergrund vom ssGTM zum Diensteanbieter erfolgt.

Unterschied zum “echten” Server Side Tracking

Die Begriffe “Server Side Tagging” und “Server Side Tracking” werden häufig – fälschlicherweise – synonym verwendet.

Beim “echten” Server Side Tracking werden Daten direkt auf dem Website-Server erfasst und direkt an den Tracking-Server (Server-zu-Server Verbindung) gesendet (oder die Daten verbleiben auf demselben Server).

Es findet in der Regel keine Datenerfassung im Client des Nutzers statt. Ebenso wird der Client nicht genutzt, um Daten an den Tracking-Server zu senden. 

Consent bei Server Side Tagging

Der Einsatz von Server Side Tagging ändert nichts daran, dass bestimmte Datenerhebungen und -verarbeitungen nur mit Einwilligung (“Consent”) des Nutzers durchgeführt werden dürfen.

Genau wie bei einer Integration von Diensten oder der Weitergabe von Daten im Client muss die Einwilligung des Nutzers vorliegen, wenn:

• personenbezogene Daten weitergeben werden oder
• Daten auf dem Endgerät des Nutzers über das technisch für den Betrieb der Website unbedingt erforderliche Maß hinaus gespeichert werden (Cookie, Local Storage, Session Storage, o.ä.).

Lohnt sich Server Side Tagging für mich?

Server Side Tagging lohnt sich vor allem:

• bei längeren oder komplexeren Customer Journeys, die sich über mehrere Tage oder Besuche erstrecken.
• wenn eine genauere Attribution für Webanalyse oder Kampagnensteuerung benötigt wird.
• wenn Daten an Dienste gesendet werden sollen, die nicht im Client einsehbar sein sollen (z.B. Gewinnmargen, personenbezogene Daten o.ä.).

Server Side GTM (ssGTM) einrichten – diese Möglichkeiten gibt es

Es gibt verschiedene Methoden einen eigenen serverseitigen Google Tag Manager zu betreiben. Diese unterscheiden sich nicht nur in Komplexität und Kosten, sondern auch in den damit erreichbaren Ergebnissen.

Vor allem im Hinblick auf die in der Regel angestrebte Verhinderung der Kürzung der Cookie-Laufzeiten durch ITP unterscheiden sich die drei folgenden Varianten:

• ssGTM aus der Google Cloud (“automatische Bereitstellung”)
• ssGTM über Drittanbieter wie stape.io
• ssGTM selbst hosten per Docker Image

Zwei Sub-Domains für Live- und Preview-Container des GTM

Alle Varianten haben gemeinsam, dass die ssGTM-Container idealerweise auf zwei Subdomains (für Live- und Preview-Container des GTM) verfügbar gemacht werden. Diese sollten zur Secondlevel-Domain der Website (z.B. domain.com) gehören.

Wir empfehlen unverfängliche Sub-Domains zu nutzen, die nicht offensichtlich auf Tracking o.ä. hinweisen:

Die Sub-Domains sollten per A/AAAA-Records im DNS (beim Webhoster) auf den gewählten Dienst aufgeschaltet werden.

“Fremde” Sub-Domains der Diensteanbieter (xyz.stape.net) sind eher eine “Notlösung”, da diese nicht zur eigenen Domain gehören und dies Einfluss auf die Möglichkeit zum Setzen von Cookies hat. Wir empfehlen die Verwendung eigener Sub-Domains oder Routen auf der Website-Domain („same origin“).

ssGTM aus der Google Cloud (“automatische Bereitstellung”)

Der einfachste Weg zum serverseitiges Google Tag Manager ist die automatische Bereitstellung aus der Google Cloud. Wenn Zahlungsmethoden hinterlegt sind, dauert die Bereitstellung weniger als eine Minute.

Eigene (Sub-)Domains können per DNS verbunden werden, die Nutzung einer Sub-Domain der Google-Cloud ist möglich (aber nicht empfohlen).

Vorteile	Sehr einfache Bereitstellung des ssGTM Containers in der Google Cloud. Auch ohne Nutzung eigener Sub-Domains möglich.
Nachteile	Kein Vorteil verlängerter Cookie-Laufzeiten bei ITP möglich (da sehr wahrscheinlich anderer IP-Kreis als die Website). Hosting bei (ggf. weiterem) Drittanbieter außerhalb der eigenen Datenhoheit.
Kosten	In der Regel geringer als bei den anderen Lösungen
Empfehlung	Nur sinnvoll, wenn die Verlängerung der Cookie-Laufzeiten bei ITP keine Relevanz hat.

ssGTM über Drittanbieter wie stape.io

Ebenfalls relativ einfach möglich ist die Bereitstellung eines ssGTM Setups über Dienste wie stape.io. 

Auch hier sollten eigene Sub-Domains per A/AAAA Records mit dem Dienst verbunden werden. SSL-Zertifikate für die Sub-Domains können von stape.io via letsencrypt erzeugt werden.

Im Standard-Setup werden Cookies beim Einsatz von stape.io von einer anderen als der Website IP gesetzt. Um Cookies unter der selben IP zu setzen, wird ein CDN oder Load-Balancer benötigt, der Anfragen weiterleiten kann (z.B. Cloudflare) – damit kann in stape.io die Funktion „Own CDN“ eingerichtet werden, so dass ssGTM Cookies unter der Website-IP gesetzt werden.

Als Alternative zum Own CDN dient die Funktion “Cookie-Keeper”. Diese soll dafür sorgen, dass Cookies erhalten bleiben bzw. wiederhergestellt werden können, wenn sie gelöscht wurden. Hierzu wird ein Master-Cookie gesetzt, mit dessen Hilfe gelöschte Tracking-Cookies wiederhergestellt werden können. 

Sofern alle Cookies inkl. des Master-Cookies von Nutzern gelöscht werden, dürfte diese Technik jedoch nicht mehr funktionieren (das gilt natürlich auch für nativ serverseitig gesetzte Cookies und ist insofern kein Nachteil).  

Mit der Zusatzfunktion “Custom Loader” können Name der aufgerufenen Dateien oder Ressourcen (zum Beispiel gtm.js) geändert werden. Dies erschwert die Blockierung durch Ad-Blocker und ähnliche Tools erheblich.

Vorteile	Hohe Kontrolle und schnelle Bereitstellung. Technisch einfacher als der Eigenbetrieb via Docker-Image. Viele zusätzliche Funktionen (“PowerUps”), zum Beispiel zur Umgehung von Ad-Blocker-Regeln, sind verfügbar.
Nachteile	Laufende Kosten (ab 20 EUR / Monat). Gleiche IP für GTM und Website ist nur über den Einsatz von CDN oder Load-Balancern möglich, die Anfragen weiterleiten können (z.B. Cloudflare).
Kosten	Höherer laufende Kosten als im Eigenbetrieb via Docker-Image.
Empfehlung	Gute Wahl bei Einschränkungen im Hosting bzw. wenn kein Docker und / oder Ressourcen für das Setup verfügbar sind. Empfehlung, wenn „Own CDN“ eingerichtet werden kann. Empfehlung für Webseiten und Shops auf SaaS-Plattformen (z.B. Webflow, Shopify).

ssGTM selbst hosten per Docker Image

Der technisch aufwendigste Weg einen ssGTM zu betreiben ist das Hosting des von Google bereitgestellten Docker-Images auf einem eigenen Server – im Idealfall auf demselben Server / auf derselben IP, auf der auch die Website läuft. 

Dieses Setup erfüllt auch auf längere Sicht die Anforderungen, um bei ITP in vollem Umfang der Verkürzung der Cookielaufzeiten – auch von serverseitig gesetzten Cookies – entgegenzuwirken.

Der ssGTM als cookie-setzender Server ist hier kaum bzw. nicht mit vertretbarem Aufwand von der Website / dem cookie-lesenden Server (Website-Server) zu unterscheiden.

Vorteile	Volle Kontrolle und geringe laufende Kosten.
Nachteile	Technisch anspruchsvolleres Setup als über Drittanbieter wie stape.io oder automatische Bereitstellung per Google Cloud.  Erfordert Docker bzw. die Möglichkeit Docker-Images zu hosten (geht nicht bei allen Hostern). Funktionen zur Umgehung von Ad-Blocker-Regeln müssen – wenn gewünscht – selbst entwickelt / aufgesetzt werden.
Kosten	Unterschiedlich. Im besten Fall kann der ohnehin vorhandene Server die Last des ssGTM mit tragen, sodass nur die einmalige Implementierung anfällt, aber kaum laufende Kosten für Hosting o.ä.
Empfehlung	Gute Wahl bei eigener IT oder sehr professionellen Hosting. Wenn „Own CDN“ eingerichtet werden kann, ist stape.io die mächtigere und leichter zu administrierende Lösung.

Anleitung: Token für Server Side Container im GTM erhalten

Für den serverseitigen GTM gibt es einen Konfigurations-Schlüssel, der benötigt wird, um beim selbst oder über andere Dienste gehosteten ssGTM den eigenen Container zu identifizieren.

Bei der automatischen Bereitstellung über die Google Cloud wird kein Konfigurations-Schlüssel benötigt. 

Um den Konfigurations-Schlüssel zu bekommen, wie folgt vorgehen:

1.) auf die drei Punkte klicken und “Container erstellen”

2.) “Server” auswählen (und oben den Namen eindeutig anpassen, z. B.  “domain.com ssGTM”)

3.) Tagging-Server manuell bereitstellen

Anleitung: ssGTM selbst hosten per Docker Image

Google stellt ein Docker Image bereit, mit dem man selbst einen serverseitigen GTM auf einem eigenen Server betreiben kann. Um einen ssGTM per Docker-Image zu betreiben, sind folgende Dingen nötig:

• Webserver mit laufendem Docker und der Möglichkeit Images zu laden
• ssGTM Konfigurations-Schlüssel (siehe oben)
• zwei konnektierte Sub-Domains (hier tmlive.domain.com und tmprev.domain.com)
• SSL-Zertifikate für die beiden Sub-Domains
• Die Möglichkeit Cronjobs einzurichten (optional, aber empfohlen)

Beispiel für V-Host Konfigurationen (mit APACHE 2 Webserver)

Die HTTP(S)-Aufrufe an beide Sub-Domains müssen vom Webserver verarbeitet und an die später zu startenden Docker-Instanzen durchgereicht werden.

Zusätzlich müssen SSL-Zertifikate für beide Sub-Domains konfiguriert werden, ferner wird SSL für beide Sub-Domains erzwungen.

<VirtualHost *:80>
    ServerName tmlive.domain.com

    RewriteEngine On
    RewriteCond %{HTTPS} off
    RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI}
</VirtualHost>

<VirtualHost *:443>
    ServerName tmlive.domain.com

    SSLEngine On
    SSLProxyEngine On
    ProxyRequests Off
    ProxyPreserveHost On
    SSLProxyVerify none
    SSLProxyCheckPeerCN off
    SSLProxyCheckPeerName off
    SSLProxyCheckPeerExpire off

    ProxyPass / http://localhost:**8080**/
    ProxyPassReverse / http://localhost:**8080**/

    SSLCertificateFile /etc/apache2/ssl/cb.com.crt
    SSLCertificateKeyFile /etc/apache2/ssl/cb.com.key
    SSLCertificateChainFile /etc/apache2/ssl/cb.com-CA.crt

</VirtualHost>

<VirtualHost *:80>
    ServerName tmprev.domain.com

    RewriteEngine On
    RewriteCond %{HTTPS} off
    RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI}
</VirtualHost>

<VirtualHost *:443>
   ServerName tmprev.domain.com

    SSLEngine On
    SSLProxyEngine On
    ProxyRequests Off
    ProxyPreserveHost On
    SSLProxyVerify none
    SSLProxyCheckPeerCN off
    SSLProxyCheckPeerName off
    SSLProxyCheckPeerExpire off

    ProxyPass / http://localhost:**8079**/
    ProxyPassReverse / http://localhost:**8079**/

SSLCertificateFile /etc/apache2/ssl/cb.com.crt
SSLCertificateKeyFile /etc/apache2/ssl/cb.com.key
SSLCertificateChainFile /etc/apache2/ssl/cb.com-CA.crt
#SSLCACertificateFile /etc/apache2/ssl/cb.com-CA.crt
</VirtualHost>

Docker Instanzen starten (Images laden)

Im nächsten Schritt werden zwei Docker Instanzen (Preview und Live) gestartet (WICHTIG: Preview zuerst!).

Im jeweiligen Befehl werden angepasst:

• der Name der Docker-Instanzen (hier “gtm-preview” und “gtm-live”)
• die Ports (-p und -e) passend zur Konfiguration des Webservers (hier 8080 für Live und 8079 für Preview) 
• GTM Konfigurations-Schlüssel
• PREVIEW_SERVER_URL (im Befehl zum Start der Live-GTM Instanz)

docker run -d\
    --name gtm-preview \
    -p 8079:8079 \
    -e CONTAINER_CONFIG='XXXXXXXXXXXXXXXXXXXXXX' \
    -e RUN_AS_PREVIEW_SERVER=true \
    -e PORT=8079 \
    gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable

docker run -d\
    --name gtm-live \
    -p 8080:8080 \
    -e CONTAINER_CONFIG='XXXXXXXXXXXXXXXXXXXXXX' \
    -e PREVIEW_SERVER_URL='https://tmprev.domain.com' \
    -e PORT=8080 \
    gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable

Docker-Instanzen testen

Wenn alles eingerichtet ist, können die beiden Instanzen mit einem Aufruf nach folgendem Muster getestet werden:

• LIVE-Instanz des GTM: https://tmlive.domain.com/healthz 
• PRIVEW-Instanz des GTM: https://tmprev.domain.com/healthz

Cronjob für Image-Updates einrichten

Es empfiehlt sich, die beiden Docker-Instanzen nachts per Cronjob neu zu starten. So werden automatisch neue Updates im Google Image verwendet.

crontab -e
0 3 * * * docker restart gtm-preview gtm-live

Tracking im ssGTM für einzelne Tools einrichten

Informationen, wie man das Server-seitige Tagging je Tool einrichtet, findet man hier

• Server-seitiges Tracking für GA4 / Google Analytics 4
• Server-seitiges Tracking für Google Ads
• Server-seitiges Tracking für LinkedIn-Ads

Anleitungen zu weiteren Tools wie Meta und Pinterest sind in Vorbereitung.