Was ist serverseitiges Tracking?

Im klassischen Aufbau lädt der Browser des Besuchers die Skripte jedes Anbieters und spricht direkt mit ihnen. Jedes Werkzeug bekommt die Anfrage auf seiner eigenen Domain, führt seinen Code innerhalb der Seite aus und schreibt von dort seine Cookies. Die tatsächliche Kontrolle darüber, was die Seite verlässt, verteilt sich auf Anbieter, die sich untereinander nicht abstimmen.

Das serverseitige Modell verschiebt den Verteilpunkt. Der Browser schickt ein einziges Ereignis an eine Infrastruktur, die du kontrollierst, untergebracht unter einer Subdomain deiner eigenen Website. Ab dort lebt die Tagging-Logik außerhalb des Browsers: dort wird entschieden, welche Felder bleiben, welche gekürzt werden und an welche Ziele sie gehen.

Zwei Dinge, die oft verwechselt werden, gehören auseinandergehalten. Die Erhebung beginnt weiterhin im Browser, denn irgendjemand muss den Klick oder den Seitenaufruf beobachten. Verlagert werden die Verarbeitung und die Verteilung. Von Messung ohne Browser zu sprechen ist deshalb falsch: der Browser bleibt im Kreislauf, nur mit weniger fremdem Code und mit einem einzigen Gegenüber.

Die praktische Folge betrifft die Steuerung. Mit der Verteilung auf dem Server kannst du an einer einzigen Stelle prüfen, was zu welchem Anbieter geht. Das ist sehr schwer nachzuweisen, wenn jedes Skript für sich entscheidet.

Der Aufbau hat drei Teile. Erstens eine Subdomain deiner Website, die auf die Tagging-Infrastruktur zeigt, mit eigenem Zertifikat. Zweitens ein Server-Container mit demselben Modell aus Tags, Triggern und Variablen, das du von der Client-Seite kennst. Drittens eine Komponente namens Client, die eingehende Anfragen abhört, sie beansprucht und in Ereignisse umwandelt, die der Container lesen kann.

Der Weg eines Besuchs sieht dann so aus. Das Tag im Browser ruft nicht mehr die Domain des Anbieters auf, sondern deine Subdomain. Der Client des Containers beansprucht diese Anfrage und baut daraus ein Ereignis mit seinen Parametern. Die Trigger entscheiden, welche Tags auslösen, und jedes Tag öffnet einen Server-zu-Server-Aufruf zum jeweiligen Ziel. Dazwischen kannst du Parameter umschreiben, maskieren oder verwerfen, bevor sie hinausgehen.

Der am meisten unterschätzte Teil ist der Betrieb. Das ist keine Einstellung innerhalb des Werkzeugs, sondern ein Dienst, der in deinem Cloud-Konto läuft und der dimensioniert, überwacht und bezahlt werden muss. Die Dokumentation zur Einrichtung mit App Engine empfiehlt mindestens drei Server im Produktivbetrieb, um das Risiko von Datenverlust bei einem Ausfall zu senken, und beziffert jeden Server auf rund 40 Dollar im Monat, mit einer Instanz aus 1 vCPU, 0,5 GB Arbeitsspeicher und 10 GB Festplatte. Daneben gibt es eine Testkonfiguration, die in den meisten Fällen keine Kosten verursacht und für Testverkehr und die Vorschau gedacht ist, nicht für den Produktivbetrieb. Außerdem gibt es verwaltete Anbieter, die den Server zum Festpreis vermieten.

Die Entscheidung, die davon abhängt, ist keine technische, sondern eine des Betriebs. Einen Tagging-Server aufzusetzen heißt, einen weiteren Dienst in Produktion zu übernehmen, mit monatlicher Rechnung, Überwachung und jemandem, der zuständig ist, wenn er nicht mehr antwortet. Wer das nicht tragen kann, endet mit einem schlechteren System als vorher, denn ein Ausfall des Tagging-Servers reißt die gesamte Messung mit, nicht nur ein Werkzeug.

Dafür gewinnst du zwei konkrete Dinge. Das eine ist die Kontrolle über das, was hinausgeht: du kannst IP-Adressen kürzen, Kennungen aus dem Query-String entfernen oder verhindern, dass ein Anbieter Felder bekommt, die er nie hätte sehen dürfen. In einem Aufbau, in dem jedes Skript seinen eigenen Aufruf macht, ist das kaum nachweisbar. Das andere ist das Gewicht der Seite, weil ein guter Teil des fremden Codes nicht mehr im Browser geladen wird.

Auch das Gespräch mit dem Geschäft ändert sich. Wenn die Führung erwartet, hundert Prozent der heute verlorenen Daten zurückzuholen, sollte man die Erwartung senken, bevor das Budget unterschrieben wird. Die Verbesserung ist meist real und messbar, aber sie ist teilweise und hängt vom Browser des Besuchers ab, von der Einwilligung, die er gegeben hat, und von der Qualität des Aufbaus.

• Halte die Erhebung der Einwilligung auf der Client-Seite und sorge dafür, dass ihr Zustand bis zum Server-Container reist. Der Einwilligungsmodus wird im Web-Container konfiguriert, und der Zustand erreicht den Server als Parameter der Anfrage.
• Dimensioniere den Produktivbetrieb vor der Umstellung: mindestens drei Instanzen, Verfügbarkeitsalarme und ein schriftlicher Rückfallplan.
• Nutze eine eigene Subdomain deiner Website mit gültigem Zertifikat und dokumentiere, wie das DNS auflöst.
• Führe eine Tabelle, welcher Parameter an welchen Anbieter geht, und geh sie jedes Quartal mit dem Datenschutzverantwortlichen durch.
• Migriere in Stufen: ein Ereignis doppelt führen, zwei bis drei Wochen gegen die bestehende Messung vergleichen und erst dann das alte Tag abschalten.
• Halte die tatsächlichen Monatskosten in der Projektakte fest, einschließlich der Wartungszeit.

• Es als Lösung für Rechtskonformität verkaufen. Die Verarbeitung zu verlagern beseitigt nicht die Pflicht, um Erlaubnis zu fragen, bevor Informationen auf dem Gerät des Nutzers gelesen oder geschrieben werden.
• Versprechen, der Verlust durch Blocker verschwinde. Die Wirkung schwankt je nach Blocker und je nach Aufbau des Pfads, und sie muss in den eigenen Daten gemessen werden.
• Die Cookie-Laufzeit als gegeben annehmen. Safari begrenzt die Gültigkeit von Cookies, die in Antworten gesetzt werden, die es als verdecktes CNAME erkennt, auf sieben Tage.
• Den Container ohne Überwachung lassen. Ohne Verfügbarkeitsalarm fällt ein Ausfall erst im Bericht am folgenden Montag auf.
• Die Testkonfiguration in den Produktivbetrieb heben, die für Testverkehr gedacht ist und echter Last nicht standhält.