Was ist Server Side Tracking mit Google Analytics?
Neben dem klassischen clientseitigen Tracking, bei dem Tracking-Daten direkt aus dem Browser des Besuchers an Google Analytics gesendet werden, gibt es zwei weitere Möglichkeiten, wie Informationen in deine GA4-Property gelangen können. Diese Ansätze werden unter dem Begriff Google Analytics Server Side Tracking zusammengefasst.
Server Side Tagging
Die erste Möglichkeit besteht darin, die Tracking-Daten zunächst vom Browser des Nutzers an einen eigenen Server zu senden – idealerweise unter der eigenen Domain erreichbar. Von dort werden sie dann an Google Analytics weitergeleitet. Der eigene Server, auch Tagging-Server genannt, fungiert dabei als Vermittler zwischen Browser und Analytics-Plattform. In diesem Fall spricht man von serverseitigem Tagging.
Server Side Tagging für Google Analytics 4 mit dem Google Tag Manager
Eine besonders etablierte Lösung für das serverseitige Tagging bietet Google selbst mit dem Servercontainer des Google Tag Managers (GTM) an. Hierbei wird ein spezieller GTM-Container auf einem eigenen Server (z. B. via Google Cloud und App Engine oder selbst gehosted) eingerichtet, der eingehende Tracking-Daten entgegennimmt und verarbeitet.
Server-to-Server Tracking
Die zweite Möglichkeit besteht darin, Tracking-Daten gar nicht erst im Browser des Nutzers zu erfassen, sondern direkt auf dem Webserver der Website oder des Onlineshops. In diesem Fall spricht man von Server-to-Server-Tracking. Hierbei ist der Browser des Nutzers nicht beteiligt, wodurch gängige Tracking-Prevention-Technologien oder Adblocker wirkungslos bleiben. Gleichzeitig ist die Datenerfassung auf serverseitig bekannte Ereignisse beschränkt – zum Beispiel Kaufabschlüsse oder das Absenden eines Formulars. Nutzerinteraktionen wie Scrolltiefe oder Verweildauer im aktiven Tab können auf diesem Weg hingegen nicht erfasst werden.
Server-to-Server Tracking für Google Analytics 4 mit dem Google Measurement Protocol
Google Analytics bietet für diesen Anwendungsfall das Measurement Protocol an. Es erlaubt, Ereignisdaten direkt vom eigenen Webserver an eine GA4-Property zu senden. Allerdings ist das Measurement Protocol laut Google nicht dafür gedacht, die browserseitige Datenerhebung vollständig zu ersetzen, sondern soll vielmehr als Ergänzung dienen – etwa zur Verknüpfung von Serverdaten mit Nutzerinteraktionen im Browser.
Lese-Tipp: Auf Analyticskiste.blog gibt es einen umfangreichen Beitrag, der einen strukturierten Überblick über das Measurement Protocol und dessen Einsatzmöglichkeiten gibt 🙂
Vorteile von Server Side Tracking/Tagging mit Google Analytics 4
Welche Vorteile ergeben sich, wenn du einen eigenen Server einsetzt, an den Tracking-Daten zunächst gesendet werden, bevor sie an Google Analytics weitergeleitet werden?
Eine kurze Übersicht:
- Das Laden von Google Skripten von einem eigenen Server
- Das Verwenden von serververwalteten Cookies
- Das Anpassen von Daten auf dem Weg zu Google Analytics
- Flexibilität bei komplexeren Setups (Multi-Property)
- Das Google-Tag als First-Party-Datensammler
Diese Vorteile wollen wir uns im Folgenden einmal genauer betrachten, um zu verstehen, was dahinter steckt.
1. Google Skripte von einem eigenen Server laden
Durch den Einsatz eines eigenen Servers ist es nicht nur möglich, Tracking-Daten darüber zu leiten, sondern auch die für Google Analytics notwendigen Skripte direkt von diesem Server zu laden – darunter gtm.js (Google Tag Manager) und tag.js (Google Tag).
Das bedeutet: Der Browser des Nutzers muss keine direkte Verbindung mehr zu Google-Servern aufbauen. Dadurch wird die IP-Adresse des Nutzers nicht automatisch an Google übermittelt – ein relevanter Vorteil in Hinblick auf Datenschutz und Compliance, insbesondere mit Blick auf DSGVO-Anforderungen.
Du benötigst Hilfe in der Einrichtung? Hier ist ein Tutorial!
In diesem Tutorial erfährst du Schritt für Schritt, wie Du den Google Tag Manager (GTM) Webcontainer sowie das Google-Tag von deinem eigenen Tagging-Server laden kannst.
2. First-Party-Cookies – Serververwaltete Cookies
Cookies speichern Informationen innerhalb des Browsers des Nutzers. Analysetools nutzen Cookies, um zufällig generierte Nutzer-IDs zu speichern, um die Wiedererkennung von Nutzern innerhalb und zwischen Sitzungen zu ermöglichen.
Um den Einfluss von Server Side Tagging auf die durch Google Analytics gesetzten Cookies zu verstehen, ist folgende Unterteilung verschiedener Cookies wichtig:
- Third-Party-Cookies: Werden von einer Domain gesetzt, die nicht mit der der besuchten Website übereinstimmt.
- First-Party-Cookies: Werden von der gleichen Domain oder einer Subdomain der Website gesetzt.
Browser behandeln diese beiden Cookie-Typen unterschiedlich: Third-Party-Cookies werden zunehmend blockiert oder automatisch gelöscht, während First-Party-Cookies in der Regel länger erhalten bleiben.
Server Side Tagging ermöglicht es, First-Party-Cookies besonders robust zu setzen – und zwar serverseitig.
Dazu muss man verstehen, wie Cookies überhaupt gesetzt werden:
- Clientseitig per JavaScript: Flexibel, aber leicht manipulierbar und anfällig für Sicherheitsprobleme.
- Serverseitig über den Set-Cookie-Header in der HTTP-Antwort: Weniger flexibel, dafür sicherer und mit Eigenschaften wie HttpOnly oder Secure besser kontrollierbar.
Gerade weil viele sicherheitsrelevante Cookies (z. B. Login-Cookies) via Set-Cookie-Header und entsprechenden Eigenschaften wie HttpOnly gesetzt werden, können Browser diese Cookies nicht ohne weiteres limitieren oder löschen – was wir uns beim Tracking zunutze machen können.
Fazit: Die Kombination aus First-Party-Domain und serverseitig gesetztem Cookie erhöht die Resilienz des Trackings erheblich. Nutzer können zuverlässiger wiedererkannt werden, was erheblich die Datenqualität verbessert.
Wichtig: Dieser Vorteil greift nur, wenn der Server unter der gleichen Domain (oder einer Subdomain) wie die Website erreichbar ist. Andernfalls wird das Cookie (Egal ob durch JavaScript oder Set-Cookie-Header gesetzt) als Third-Party behandelt – mit den bekannten Nachteilen.
Gut zu wissen: Wie funktioniert der serververwaltete Cookie bei Google Analytics 4?
Im Fall von Google Analytics 4 lautet der Name des serververwalteten Cookies standardmäßig FFID (wahrscheinlich für „First-Party ID“). Der Name kann jedoch individuell angepasst werden.
Der FFID-Cookie speichert im Browser des Nutzers eine Client-ID, mit der Nutzer über mehrere Seitenaufrufe und Sitzungen hinweg eindeutig identifiziert werden können.
Dabei wichtig zu verstehen:
Auch weiterhin wird ein JavaScript-verwalteter Cookie mit einer eigenen cid gesetzt. Bei der Kommunikation mit dem Tagging-Server schickt der Browser beide Informationen mit – die cid im Ereignis-Body und die FFID im Header. Der Server tauscht dann die clientseitige ID gegen die serverseitig gesetzte FFID aus, bevor die Daten an Google Analytics gesendet werden.
Auf diese Weise entsteht ein robusteres und konsistenteres Nutzer-Tracking – mit deutlich höherer Widerstandsfähigkeit gegenüber Browserrestriktionen oder Adblockern.
3. Anpassen von Daten, bevor sie an Google Analytics gesendet werden
Da der Tagging-Server als Zwischenstation zwischen dem Browser des Nutzers und Google Analytics 4 fungiert – und wir die volle Kontrolle über diesen Server haben – bietet sich eine zentrale Möglichkeit: Wir können die Tracking-Daten auf dem Weg zu Google Analytics verändern.
Das bedeutet konkret:
- Wir können Daten entfernen, die wir nicht an Google übermitteln möchten.
- Und wir können Daten hinzufügen, die im Browser nicht vorhanden oder aus Datenschutzgründen dort nicht sichtbar sein sollen – wie z. B. Einkaufs- oder Margeninformationen.
Im GTM-Servercontainer lassen sich solche Datenmanipulationen gezielt über sogenannte Transformationen umsetzen, ohne dass diese Daten im Browser des Nutzers auftauchen.
Schauen wir uns beide Szenarien an:
Szenario 1: Entfernen von Daten auf dem Tagging-Server
Ein wesentlicher Grund, Daten zu entfernen, ist der Datenschutz. Abhängig von der eigenen Auslegung der DSGVO und dem gewünschten Datenschutzniveau können bestimmte Parameter, die bei clientseitigem Tracking automatisch übermittelt würden, gezielt entfernt werden.
Einige Beispiele:
- User-Agent: Dieser enthält Informationen über das Gerät und den Browser des Nutzers. Möchte man diese Daten nicht an Google weitergeben, kann man sie serverseitig filtern – allerdings verzichtet man dann in GA4 auf entsprechende Auswertungen zu Geräten, Browsern oder Betriebssystemen.
- IP-Adresse: Ein häufiges Anliegen ist die vollständige Anonymisierung der IP-Adresse. Der eigene Tagging-Server kann so konfiguriert werden, dass IP-Adressen gar nicht erst an Google übermittelt werden.
- PII (Personally Identifiable Information): Dazu zählen Informationen wie E-Mail-Adressen im Klartext, Telefonnummern oder Namen. Die Übermittlung von PII an Google Analytics ist streng untersagt – und wird von Google hart sanktioniert. Werden solche Daten in deiner GA4-Property erkannt, kann Google die gesamte Property (oder sogar das gesamte Konto) ohne Vorwarnung deaktivieren. Server Side Tagging bietet hier ein wichtiges Sicherheitsnetz: Es erlaubt dir, eingehende Daten zu prüfen und potenzielle PII zuverlässig zu entfernen, bevor sie an Google Analytics gesendet werden.
Szenario 2: Hinzufügen und Anreichern von Daten
Noch spannender als das Entfernen von Daten ist das gezielte Anreichern von Ereignissen mit zusätzlichen Informationen, die im Browser nicht verfügbar sind.
Beispiele:
- Debugging: Du kannst die aktuelle Version deines GTM-Servercontainers als Parameter mitsenden, um beim Debugging oder in Berichten zu sehen, mit welcher Konfiguration bestimmte Events verarbeitet wurden.
- Profit-Tracking / Deckungsbeitrag: Mithilfe einer Anbindung z. B. an eine Firestore-Datenbank lässt sich der Deckungsbeitrag einer Bestellung (nicht nur der Umsatz) berechnen. Diese zusätzliche Information kann dann zusammen mit dem Kauf-Event an Google Analytics gesendet werden.
Besonders interessant wird es, wenn diese angereicherten Daten in Google Ads zur Optimierung genutzt werden:
Kampagnen können so nicht nur auf Umsatzbasis, sondern wertebasiert auf Profit/Kosten-Nutzen-Verhältnis optimiert werden. Das bietet eine neue Qualität in der Kampagnensteuerung – besonders für performanceorientierte Unternehmen mit engen Margen.
4. Flexibilität bei größeren Setups
Mit Google Analytics 4 hat sich die Konto-Struktur im Vergleich zu Universal Analytics grundlegend verändert. Innerhalb einer Property gibt es keine Ansichten (Views) mehr mit separaten Zugriffsrechten oder Filterlogiken. Das erschwert komplexere Setups – zum Beispiel bei international tätigen Unternehmen, die ihre Daten sowohl pro Land als auch gesamt analysieren möchten.
Ein typisches Beispiel:
Ein Onlineshop mit separaten Domains für Deutschland (shop.de) und Frankreich (shop.fr). Ziel ist es, beide Länder-Websites einzeln auszuwerten, gleichzeitig aber auch konsolidierte Reports über alle Länder hinweg zu erhalten.
Die Lösung:
Man benötigt drei Properties – eine je Land und eine übergreifende Property. Zwar gibt es in Google Analytics 360 die Möglichkeit, sogenannte Rollup- und Subproperties zu nutzen, doch diese Funktionen sind kostenpflichtig und nur in der Enterprise-Version verfügbar.
Clientseitig (also ausschließlich mit dem Google Tag Manager Webcontainer) wäre es mit hohem Konfigurations- und Wartungsaufwand möglich, alle Tracking-Daten gleichzeitig in mehrere Properties zu senden – allerdings ist das fehleranfällig und schwer skalierbar.
Mit einem eigenen Tagging-Server wird dieses Setup deutlich einfacher:
Man kann im GTM-Servercontainer mehrere GA4-Tags hinzufügen und somit festlegen, dass eingehende Ereignisse gleichzeitig an mehrere Properties weitergeleitet werden – etwa in die Länder-Property und die Gesamt-Property. So entsteht eine Art „kostenloses Rollup-Property“-Setup, ohne dass zusätzliche Konfigurationen auf Browser-/Frontend-Seite notwendig sind.
Wichtig: Damit auch die serververwalteten Cookies korrekt funktionieren, muss der Tagging-Server unter verschiedenen Domains oder Subdomains erreichbar sein – z. B. data.shop.de und data.shop.fr. Nur so bleiben die Cookies innerhalb der jeweiligen First-Party-Kontexte gültig.
5. Google Tag als First-Party Datensammler
Wenn Google Analytics über den Google Tag Manager Servercontainer integriert ist, wird das Google Tag zu einem zentralen Datensammler – und zwar nicht nur für GA4, sondern auch für andere Tools wie Meta (Facebook), TikTok oder sogar interne Systeme.
Das bedeutet:
Anstatt für jedes Tracking-Tool eigene Pixel im Frontend zu platzieren, wird das Google Tag im Browser einmal ausgelöst und sendet die Rohdaten an den eigenen Servercontainer. Dort entscheidet die Serverkonfiguration, an welche Tools diese Daten weitergegeben werden sollen.
Vorteile:
- Weniger Code im Frontend: Das reduziert Ladezeiten und Konflikte mit Consent-Layern oder Adblockern.
- Einheitliche Datengrundlage: Alle Tools erhalten konsistente, bereinigte und aufbereitete Daten.
- First-Party-Kontext: Auch Tools wie Meta profitieren davon, dass serververwaltete Cookies eine persistente Wiedererkennung gewährleisten.
Natürlich ist für eine datenschutzkonforme Umsetzung zusätzliche Konfiguration nötig – insbesondere im Hinblick auf den Google Einwilligungsmodus (Consent Mode). Aber korrekt umgesetzt, können auch andere Plattformen als Google Analytics von den Vorteilen des Server Side Taggings profitieren.
Nachteile von Server Side Tracking/Tagging mit Google Analytics 4
So viele Vorteile das Server Side Tagging auch bietet – es bringt auch zwei wesentliche Herausforderungen mit sich: mehr Komplexität in der Einrichtung und zusätzliche Betriebskosten für die notwendige Infrastruktur.
1. Komplexität des Setups – Mehr Konfigurations- und Wartungsaufwand
Im Gegensatz zum klassischen Setup mit einem GTM-Webcontainer oder dem gtag.js im Browser, erfordert das Server Side Tagging den zusätzlichen Einsatz eines Google Tag Manager Servercontainers. Dieser muss – wie der Webcontainer – ebenfalls eingerichtet, angepasst und regelmäßig gewartet werden.
Wie hoch der Mehraufwand ist, hängt stark vom Anwendungsfall ab:
- Wenn nur Google Analytics-Ereignisse weitergeleitet werden sollen, hält sich der zusätzliche Aufwand in Grenzen.
- Komplizierter wird es, wenn auch Google Ads-Conversions serverseitig verarbeitet werden sollen. Zwar ist die Integration gut durchdacht und fügt sich sauber in das Google-Ökosystem ein, aber sie erfordert etwas Einarbeitung.
- Noch aufwendiger ist die Integration von Drittanbieter-Tools (z. B. Meta/Facebook, TikTok, Affiliate-Plattformen), da diese in der Regel keine offiziellen Server Side Tags für den GTM-Servercontainer bereitstellen. Hier sind oft Lösungen von Drittanbietern und eigene Anpassungen notwendig.
Tipp für Einsteiger
Server Side Tagging lässt sich auch schrittweise einführen. Ein möglicher Ablauf:
- Start mit Google Analytics 4
- Erweiterung um Google Ads Conversion Tracking
- Mittelfristige Planung zur Anbindung weiterer Drittanbieter (z. B. Meta)
Währenddessen können bestehende clientseitige Pixel (z. B. Facebook) weiterlaufen – sie werden durch die Einführung des Server Side Trackings für GA4 nicht gestört.
2. Kosten für den Betrieb des GTM-Server-Containers (Tagging-Servers)
Beim clientseitigen Tracking erfolgt die gesamte Verarbeitung im Browser – also ohne zusätzliche Infrastrukturkosten. Beim Server Side Tagging hingegen wird die Verarbeitung auf einen eigenen Server ausgelagert, der natürlich betrieben, gehostet und überwacht werden muss.
In unserem separaten Beitrag zum Server Side Tagging findest du einen Überblick über verschiedene Hosting-Optionen und deren Kosten.
Kosten für einen Tagging-Server kurz zusammengefasst
Für kleinere bis mittlere Unternehmen ist ein spezialisierter Hosting-Anbieter in der Regel die beste Lösung.
Dienste wie GTM-Hosting, Stape und Taggrs bieten einfache Einrichtung des Servercontainer-Hostings mit klar kalkulierbaren Kosten:
- Bis 20.000 Tracking-Anfragen/Monat oft kostenfrei
- Bis 500.000 Anfragen meist unter 25 € pro Monat
Damit bleibt Server Side Tagging auch für kleinere Unternehmen wirtschaftlich umsetzbar – insbesondere, wenn man den Mehrwert durch bessere Datenqualität, Datenschutz und Tracking-Stabilität berücksichtigt.
Fazit
Server Side Tracking mit Google Analytics 4 eröffnet neue Möglichkeiten, die mit einer rein clientseitigen Integration nicht realisierbar sind. Dazu zählen insbesondere:
- die Nutzung von First-Party-Daten und -Cookies,
- die gezielte Anpassung von Ereignisdaten, bevor sie an Google Analytics gesendet werden,
- sowie die flexible Umsetzung komplexer Tracking-Setups mit mehreren GA4-Properties – ohne hohen Mehraufwand im Frontend.
Darüber hinaus lässt sich über einen eigenen Tagging-Server auch ein zentraler Daten-Hub aufbauen: Die erfassten Nutzerdaten können nicht nur an Google Analytics, sondern auch an Drittanbieter-Plattformen wie Meta oder TikTok gesendet werden – konsistent, datenschutzkonform und aus einer First-Party-Quelle.
Natürlich bringt Server Side Tagging auch Herausforderungen mit sich: Es ist technisch komplexer, erfordert sorgfältige Planung und verursacht zusätzliche Kosten. Dennoch stellt sich für viele Unternehmen nicht die Frage, ob, sondern wann sie diesen Schritt gehen.
Denn eines ist klar: Die zunehmende Einschränkung von Third-Party-Cookies, Adblockern und browserseitigen Tracking-Preventions verschlechtert die Datenqualität im klassischen Webtracking kontinuierlich.
Server Side Tagging ist ein zentraler Hebel, um dieser Entwicklung zu begegnen – mit besseren Daten, höherer Kontrolle und gleichzeitig mehr Datenschutz für die Nutzer.