Server-Side Tracking wird oft als Reparatur für fehlende Daten verkauft. Es repariert einen Teil davon – und einen anderen, größeren Teil ausdrücklich nicht.
Was technisch passiert
Im klassischen Aufbau schickt der Browser seine Meldungen direkt an die Messanbieter. Beim serverseitigen Aufbau schickt er sie zunächst an eine eigene Subdomain – zum Beispiel api.ihredomain.de –, wo ein eigener Container läuft. Dieser verarbeitet die Meldung und leitet sie an die Zielsysteme weiter.
Der Unterschied klingt nach Umweg, hat aber drei konkrete Folgen. Die Anfrage geht an die eigene Domain und wird deshalb von Inhaltsblockern seltener unterbunden. Die dabei gesetzten Cookies sind Erst-Party-Cookies und unterliegen nicht den kurzen Laufzeiten, die Browser für Erkennungsmerkmale aus fremden Quellen erzwingen. Und die Weiterleitung an die Plattformen läuft über den eigenen Server, wodurch Zugriffstoken nicht mehr im Browser liegen und man selbst bestimmt, welche Felder überhaupt übermittelt werden.
Was es tatsächlich verbessert
Zuordnung über längere Zeiträume
Wenn ein Erkennungsmerkmal nach wenigen Tagen verfällt, erscheint ein wiederkehrender Besucher als neuer Besucher. Bei Angeboten mit kurzer Entscheidung fällt das kaum auf. Bei einer Immobilie, einem Investitionsgut oder einer Bewerbung liegen zwischen erster Anzeige und Abschluss regelmäßig Wochen. Genau dort entsteht der Bruch, und genau dort hilft die Erst-Party-Zustellung.
Robustheit gegen Blockierung
Ein spürbarer Anteil der Besucher blockiert Skripte bekannter Messanbieter – teils bewusst, teils durch Voreinstellungen des Browsers oder Netzwerks. Die Zustellung über die eigene Domain umgeht das nicht vollständig, reduziert aber den Verlust deutlich.
Kontrolle über die Datenweitergabe
Das ist aus unserer Sicht der unterschätzte Punkt. Im serverseitigen Aufbau sieht man exakt, welches Feld an welche Plattform geht, und kann Felder gezielt weglassen. Im rein clientseitigen Aufbau überträgt ein fremdes Skript, was es überträgt. Für die Datenschutz-Dokumentation ist der Unterschied erheblich.
Was es ausdrücklich nicht verbessert
Serverseitige Messung ist keine Umgehung der Einwilligung. Wer nicht zustimmt, wird nicht gemessen – daran ändert der technische Weg nichts, und jeder Aufbau, der etwas anderes verspricht, ist ein rechtliches Risiko und kein Vorteil.
Sie repariert auch keine schlechte Ereignisdefinition. Ein Ereignis, das die falsche Handlung misst, misst serverseitig weiterhin die falsche Handlung – nur zuverlässiger.
Und sie erzeugt keine Daten, die es nicht gibt. Wer keine Rückmeldung aus dem Vertrieb einspeist, weiß auch nach der Umstellung nicht, welche Anfragen brauchbar waren.
Serverseitige Messung erhöht die Vollständigkeit vorhandener Signale. Sie erzeugt keine neuen.
Was der Aufbau kostet
Ehrlich gerechnet gehören dazu: eine Subdomain samt Zertifikat, ein gehosteter Container mit laufenden Kosten im niedrigen zweistelligen Bereich pro Monat bei kleinem bis mittlerem Aufkommen, die Umstellung des bestehenden Aufbaus und ein Test, der beide Wege gegeneinander prüft. Dazu kommt ein Auftragsverarbeitungsvertrag mit dem Hoster und ein Absatz in der Datenschutzerklärung, der beschreibt, was dort tatsächlich passiert.
Der Aufwand ist überschaubar, aber er ist real. Er lohnt sich, wenn Werbebudget in relevanter Höhe fließt und Entscheidungen daran hängen. Er lohnt sich nicht als erste Maßnahme auf einer Website, die noch keine sauber definierten Ereignisse hat.
Die Reihenfolge, die wir empfehlen
- Zuerst die Ereignisse klären: Welche Handlung zählt als Erfolg, und wann genau wird sie gemeldet?
- Dann die Einwilligung sauber durchreichen und den Widerruf prüfen.
- Dann, falls Kampagnen laufen, die serverseitige Zustellung aufbauen – mit gemeinsamer Ereigniskennung, damit browser- und serverseitige Meldung desselben Vorgangs zusammengeführt und nicht doppelt gezählt werden.
- Dann die Rückmeldung aus dem Vertrieb ergänzen.
Wer bei Schritt drei anfängt, hat am Ende eine technisch anspruchsvolle Anlage, die verlässlich das Falsche misst.
