Client-Side-Tracking: Messung im Browser
Beim Client-Side-Tracking laufen alle Messskripte im Browser. Ein typischer Aufbau: Der Google Tag Manager lädt auf jeder Seite die Tags für Google Analytics, Google Ads, Meta und vielleicht ein Affiliate-Netzwerk. Jedes Skript sammelt Daten zum Besuch und schickt sie selbst an seinen Anbieter.
Um wiederkehrende Besucher zu erkennen, speichern die Skripte Cookies oder nutzen den Web Storage des Browsers. Google Analytics 4 setzt dafür ein First-Party-Cookie unter Ihrer Domain. Der Vorteil dieses Verfahrens: Es ist schnell eingerichtet, braucht keine eigene Infrastruktur, und fast jedes Werkzeug liefert einen fertigen Code für den Browser.
Server-Side-Tracking: ein eigener Server dazwischen
Beim Server-Side-Tracking mit dem Google Tag Manager arbeiten zwei Container zusammen. Der Web-Container im Browser schickt die Ereignisse als einen einzigen Datenstrom an einen Server-Container. Dieser läuft in einer Cloud-Umgebung, bei Google in der Regel auf Cloud Run in Ihrem eigenen Google-Cloud-Projekt. Im Server-Container nehmen sogenannte Clients die Anfragen an und wandeln sie in Ereignisse um. Tags im Server-Container geben diese Ereignisse dann an die einzelnen Dienste weiter, zum Beispiel an Google Analytics oder über die Conversions API an Meta.
Laut Google haben nur Sie Zugriff auf die Daten im Server, bis Sie sie an einen Dienst weitergeben. Google empfiehlt dringend, den Server unter einer Subdomain Ihrer eigenen Domain zu betreiben.
Die Unterschiede im Überblick
- Datenfluss: Clientseitig spricht der Browser mit jedem Anbieter einzeln. Serverseitig spricht er nur mit Ihrem Server, die Anbieter erhalten ihre Daten von dort.
- Kontrolle: Auf dem Server können Sie Anfragen prüfen, Werte vereinheitlichen, Angaben wie die IP-Adresse entfernen oder Anfragen ganz verwerfen, bevor etwas weitergeht. Sie können Daten auch anreichern, etwa um die Marge einer Bestellung, ohne dass dieser Wert im Browser sichtbar wird.
- Ladezeit: Je weniger Skripte im Browser laufen, desto weniger Arbeit hat das Gerät des Besuchers. Wie viel das bringt, hängt davon ab, wie viele Tags vorher im Browser liefen.
- Cookies: Safari löscht laut WebKit Cookies, die per JavaScript gesetzt wurden, wenn der Besucher sieben Tage lang nicht mit der Website interagiert. Ein Server-Container unter Ihrer Subdomain kann Cookies in der Serverantwort setzen, auf Wunsch mit dem Attribut HttpOnly. HttpOnly-Cookies beschreibt Google als beständiger und sicherer. Ob Safari diese Cookies länger als sieben Tage zulässt, hängt davon ab, ob Safari den Server über den CNAME-Eintrag oder die IP-Adresse einem Drittanbieter zuordnet. Das sollten Sie nach der Einrichtung messen.
- Aufwand: Clientseitig genügt ein Codeschnipsel. Serverseitig brauchen Sie zusätzlich einen Server, eine Subdomain sowie laufende Pflege und Überwachung.
Grenzen und Kosten des Server-Side-Trackings
Server-Side-Tracking ersetzt den Browser nicht. Was ein Besucher auf der Seite tut, erfährt der Server nur, weil der Web-Container es ihm meldet. Werkzeuge, die das Verhalten auf der Seite selbst aufzeichnen müssen, laufen weiterhin im Browser.
Dazu kommen laufende Kosten. Google rechnet in seiner Anleitung für Cloud Run mit rund 45 US-Dollar pro Server und Monat und empfiehlt für den Livebetrieb mindestens zwei Server, damit bei einem Ausfall keine Daten verloren gehen. Bei mehr Anfragen startet Cloud Run automatisch weitere Server, und die Kosten steigen mit.
Einwilligung: serverseitig heißt nicht einwilligungsfrei
Auch beim Server-Side-Tracking beginnt jede Messung mit einer Anfrage aus dem Browser, und in aller Regel werden Cookies auf dem Gerät gesetzt oder ausgelesen. Für das Speichern und Auslesen von Informationen auf dem Endgerät verlangt § 25 TDDDG grundsätzlich eine Einwilligung. Ausnahmen gibt es nur eng begrenzt, vor allem für das, was für den vom Nutzer ausdrücklich gewünschten Dienst unbedingt erforderlich ist; bei Analyse und Werbung liegt das meist nicht vor. Gibt der Server personenbezogene Daten wie die IP-Adresse oder Bestelldaten an Dienste weiter, braucht es zusätzlich eine Rechtsgrundlage nach der DSGVO. Ob und wofür Sie eine Einwilligung brauchen, hängt von der jeweiligen Verarbeitung ab. Die Einzelheiten sollten Sie mit Ihrem Datenschutzbeauftragten klären.
Technisch muss die Entscheidung aus dem Banner bis zum Server gelangen, denn eine Ablehnung im Cookie-Banner muss auch im Server-Container beachtet werden. Den Consent Mode richten Sie laut Google im Web-Container ein; initialisiert werden muss die Einwilligung laut Tag-Manager-Hilfe in jedem Container. Das Google-Tag überträgt die Einwilligung mit jeder Anfrage, und die Google-Tags im Server-Container richten sich danach. Bei Tags anderer Anbieter im Server-Container, etwa der Meta Conversions API, muss die Einrichtung die Einwilligung ausdrücklich prüfen.
Wann sich Server-Side-Tracking lohnt
Server-Side-Tracking lohnt sich vor allem, wenn mehrere Werbe- und Analysedienste dieselben Daten brauchen, wenn Sie genau steuern wollen, welche Angaben an wen gehen, oder wenn Conversions mit den richtigen Werten bei den Werbeplattformen ankommen sollen. Für eine kleine Website mit Google Analytics als einzigem Dienst lohnt sich der Aufwand selten.
Im Consent Management koppeln wir im Google Tag Manager jedes Tag an die passende Einwilligungsbedingung. Mit Server-Side-Tracking und einer klaren Banner-Gestaltung lassen sich Messlücken verringern, ohne die Entscheidung der Nutzer zu umgehen. Laufen Affiliate-Netzwerke und andere bezahlte Kanäle parallel, kommt eine Tracking-Weiche hinzu. Sie legt fest, welcher Kanal einen Verkauf gemeldet bekommt, wenn mehrere beteiligt waren, damit dieselbe Bestellung nicht doppelt vergütet wird.
Sie überlegen, Ihr Tracking auf den Server zu verlagern, oder möchten Ihren bestehenden Aufbau prüfen lassen? Dann kontaktieren Sie uns gerne oder lesen Sie mehr über unser serverseitiges Tracking!
