Inhalt dieser Seite
- Beispiel aus der Praxis
- Wie funktioniert Server-Side-Tracking?
- Warum gehen beim clientseitigen Tracking Daten verloren?
- Ist Server-Side-Tracking datenschutzkonform?
- Wann lohnt sich Server-Side-Tracking und wann nicht?
- Welcher Aufwand entsteht für Betrieb und Kosten?
- Typische Fehler beim Server-Side-Tracking
- Häufige Fragen
Beispiel aus der Praxis
Ein Onlinehändler stellt fest, dass Google Ads deutlich weniger Käufe meldet als das Shopsystem. Ein Teil der Messsignale geht durch Werbeblocker und Einschränkungen der Browser verloren, weil der Browser jedes Besuchers die Daten direkt an Google, Meta und andere Anbieter schickt.
Mit einem eigenen Tracking-Server unter der Shop-Domain laufen die Daten zuerst über das Unternehmen. Dort entscheidet der Händler, was an welchen Anbieter weitergeht, und kann vorher zum Beispiel IP-Adressen entfernen. Gleichzeitig kommen mehr Signale an.
Wie funktioniert Server-Side-Tracking?
Beim Server-Side-Tracking steht zwischen Browser und Plattformen ein eigener Tagging-Server. Verbreitet ist der serverseitige Google Tag Manager, der zum Beispiel in Google Cloud Run oder bei spezialisierten Hosting-Anbietern betrieben wird.
- Der Browser sendet ein Ereignis, etwa „Kauf abgeschlossen“, an den Tagging-Server unter einer Subdomain der eigenen Website.
- Sogenannte Clients im Server-Container nehmen die Daten an und wandeln sie in Ereignisse um.
- Tags im Server-Container leiten die Ereignisse an Google Analytics 4, Google Ads oder andere Ziele weiter, auf Wunsch gekürzt oder angereichert.
Daneben gibt es direkte Server-zu-Server-Schnittstellen wie die Conversions API von Meta, über die Conversion-Daten aus Shop oder CRM an die Werbeplattform gehen.
Warum gehen beim clientseitigen Tracking Daten verloren?
Clientseitiges Tracking hängt vollständig vom Browser ab, und Browser schränken Tracking zunehmend ein.
- Werbe- und Trackingblocker unterbinden Anfragen an bekannte Tracking-Domains.
- Browser-Einschränkungen: Safari begrenzt per JavaScript gesetzte Cookies seit Intelligent Tracking Prevention 2.1 auf sieben Tage Laufzeit. Wiederkehrende Besucher werden dann als neu gezählt, Conversions nach längerer Entscheidungsphase gehen verloren.
- Fehlende Einwilligung: Ohne Zustimmung darf nicht getrackt werden, daran ändert auch ein Server nichts.
Server-Side-Tracking kann die ersten beiden Effekte abschwächen. Wie groß der Unterschied im Einzelfall ist, lässt sich erst nach einer Messung vor und nach der Umstellung sagen. Belastbare allgemeine Prozentwerte gibt es dafür nicht.
Ist Server-Side-Tracking datenschutzkonform?
Server-Side-Tracking kann datenschutzfreundlicher sein, ersetzt aber keine Einwilligung. Wo § 25 des Telekommunikation-Digitale-Dienste-Datenschutz-Gesetzes (TDDDG) oder die DSGVO eine Zustimmung verlangt, gilt das unabhängig davon, ob die Daten über den Browser oder einen Server laufen.
- Vorteil: Sie entscheiden, welche Daten die Plattformen erhalten, und können etwa IP-Adressen oder Gerätedaten vor der Weitergabe entfernen.
- Pflicht: Der Einwilligungsstatus muss auch im Server-Container beachtet werden, etwa über den Google Consent Mode.
- Transparenz: Der Tagging-Server und alle Empfänger gehören in die Datenschutzerklärung und das Verzeichnis der Verarbeitungstätigkeiten.
Server-Side-Tracking gezielt einzusetzen, um Nutzerentscheidungen oder Blocker zu umgehen, ist rechtlich riskant. Stimmen Sie das Konzept mit Ihrem Datenschutzbeauftragten ab; diese Übersicht ist keine Rechtsberatung.
Wann lohnt sich Server-Side-Tracking und wann nicht?
Server-Side-Tracking lohnt sich, wenn fehlende Conversion-Daten Kampagnen spürbar verschlechtern. Das ist vor allem bei automatisierten Gebotsstrategien der Fall, die auf vollständige Conversion-Signale angewiesen sind.
- Sinnvoll: Onlineshops mit vielen Transaktionen, Unternehmen mit relevantem Werbebudget in Google Ads, Meta Ads oder LinkedIn, Websites mit vielen Tags und Ladezeitproblemen.
- Weniger sinnvoll: kleine Websites mit wenigen Anfragen, fehlendes sauberes Messkonzept, niemand intern oder extern für den laufenden Betrieb zuständig.
EOM prüft im Rahmen von Analytics und Tracking, ob der Aufwand im Verhältnis zum erwarteten Datengewinn steht.
Welcher Aufwand entsteht für Betrieb und Kosten?
Server-Side-Tracking verursacht laufende Kosten für den Server und Pflegeaufwand. Google empfiehlt für den Produktivbetrieb des serverseitigen Tag Managers in Cloud Run mindestens zwei Instanzen, damit bei einem Ausfall keine Daten verloren gehen. Die Kosten hängen vom Traffic ab und lassen sich mit dem Google-Cloud-Preisrechner abschätzen.
- Einrichtung von Tagging-Server, Subdomain und Server-Container
- Anpassung von Web-Container und Einwilligungslogik
- Monitoring, Updates und Tests nach Änderungen an Website oder Plattformen
Typische Fehler beim Server-Side-Tracking
- Der Tagging-Server läuft unter einer fremden Domain statt unter der eigenen Subdomain, dadurch entfällt ein Großteil des Nutzens.
- Der Einwilligungsstatus wird im Server-Container ignoriert.
- Ereignisse werden doppelt gezählt, weil Browser-Tags und Server-Tags parallel an dieselbe Plattform senden, ohne Deduplizierung.
- Nur eine Instanz im Produktivbetrieb, Ausfälle bleiben unbemerkt.
- Kein Messkonzept: Die bestehenden Fehler im Tracking werden auf den Server übertragen.