Serverseitiges Tracking ist inzwischen Pflicht
Browserseitiges Tracking verliert seit Jahren Events. Werbeblocker, Safaris Intelligent Tracking Prevention, die Standardschutzfunktionen von Firefox und abgelehnte Cookie-Einwilligungen entfernen Conversion-Events, bevor sie eine Werbeplattform erreichen. Die Gebotsstrategie optimiert dann auf die verbleibenden Conversions, und die stammen überwiegend von Menschen mit lockereren Datenschutzeinstellungen. Die Stichprobe wird dadurch kleiner und verzerrt.
Was der Server sendet
Serverseitiges Tracking über Metas Conversions API und Googles Data Manager / Enhanced Conversions sendet dieselben Events von einem Server, den die Agentur kontrolliert, abgeglichen und dedupliziert mit dem Browser-Pixel. Gesendet wird nur für Besucher, die eingewilligt haben. Für diese Besucher kommen die Events auch dann an, wenn ein Werbeblocker oder Safaris ITP das Browser-Pixel stoppt.
Die Server-Kopie ist eine zweite Nachricht mit demselben Event-Namen und Zeitstempel, einer Event-ID, die sie mit der Browser-Kopie teilt, gehashten Identifikatoren wie E-Mail oder Telefonnummer, dem Click-Identifier aus der Landing-URL sowie Bestellwert und Währung. Das meiste davon ist kein Tagging-Problem. Der Click-Identifier kommt einmal an, beim ersten Seitenaufruf, während die Conversion später stattfinden kann, etwa nach einem Formular, einem Telefonat oder einer manuellen Freigabe. Irgendetwas muss ihn an dem Datensatz speichern, aus dem am Ende eine Conversion wird.
Wir speichern die Klick-ID in einer Spalte am Lead-Datensatz, damit sie noch da ist, wenn der Lead zwei Wochen später konvertiert. Jede Conversion wird zu einer Zeile, die sich erneut senden und mit den Berichten der Werbeplattform abgleichen lässt, und darauf baut jede spätere Fehlersuche auf. Die Match-Qualität hängt vom Event ab: Eine Angebotsanfrage oder ein Checkout bringt E-Mail-Adresse und Telefonnummer mit, ein anonymer Produktaufruf fast nichts.
Wo die Deduplizierung bricht
Beide Kopien erreichen die Plattform, die sie anhand der gemeinsamen Event-ID zu einer einzigen zusammenführen soll. Ist diese ID falsch, werden die beiden Kopien als zwei Conversions gezählt. Die gemeldeten Conversions steigen künstlich, die Kosten pro Akquisition sehen besser aus, als sie sind, und die Gebotsstrategie optimiert auf eine Zahl, die es nicht gibt. Dieser Fehler ist schlimmer als gar kein serverseitiges Tracking, weil er in die Richtung versagt, die alle gern glauben.
Deshalb wird die ID einmal auf dem Server erzeugt und mit der Seite an den Browser übergeben. Die zweite Falle sind Wiederholungen: Aufrufe an eine Werbeplattform laufen in Timeouts, und ein erneuter Versuch muss dieselbe Event-ID verwenden, weil eine neue ID die Conversion verdoppelt. Der Versand ist idempotent, und der Datensatz hält fest, ob schon erfolgreich gesendet wurde.
Beide Seiten sollten außerdem dieselben Parameter senden. Tun sie das nicht, kann die Zahl der Events stimmen, während die Match-Qualität sinkt, und das fällt leicht nicht auf.
Consent, und was schriftlich festgehalten wird
Serverseitiges Tracking wird manchmal als Weg an der Einwilligung vorbei verkauft. Tracking trotz abgelehnter Einwilligung ist nach DSGVO unzulässig, und das bauen wir nicht. Ein Server hat kein Cookie-Banner: Liegt die Einwilligung nur im Browser, sendet der Server auch Events von Besuchern, die abgelehnt haben, weil er davon nie erfahren hat.
Deshalb wird die Einwilligung als Feld an jedem Event-Datensatz gespeichert, und der Server liest es vor jedem Versand. Bevor etwas davon gebaut wird, halten wir je Event schriftlich fest:
den Event-Namen und die genaue Nutzeraktion, die ihn auslöst
die gesendeten Parameter und welche davon personenbezogene Daten sind
die Identifikatoren, die zum Matching dienen, und wie sie gehasht werden
wie lange die Rohdatenzeile des Events aufbewahrt wird, bevor sie gelöscht wird
Dieses Dokument ist der Leistungsumfang. Ein Festpreis funktioniert nur, wenn das Ergebnis so genau beschrieben ist, und dasselbe Dokument macht die Integration später überprüfbar.
Nach dem Launch
Für eine Agentur zeigt sich der Effekt in Zahlen, die der Kunde ohnehin beobachtet. Die gemeldeten Conversions nähern sich der tatsächlichen Zahl, und die Kosten pro Akquisition sinken meist, weil die Gebote auf einer vollständigeren, wenn auch nie vollständigen Datenbasis laufen.
Was wir nicht liefern können, ist eine saubere Messung dieser Rückgewinnung. Die Events, die der Browser verloren hat, wurden nie erfasst, es gibt also keine Ausgangsbasis, und ein Vorher-nachher-Vergleich wird durch die neu startende Lernphase und durch modellierte Conversions verzerrt, die schon für die fehlenden einspringen. Steigende gemeldete Conversions zeigen, dass die Integration funktioniert. Sie messen nicht, wie viel Nachfrage vorher unsichtbar war.
Nach dem Launch fällt eine ausgefallene Integration leicht nicht auf, weil das Browser-Pixel weiter Zahlen liefert. Deshalb vergleichen wir die Event-Zahlen von Browser und Server und markieren Abweichungen, und Änderungen an API-Versionen werden vorab eingeplant. Wer das nach dem Launch übernimmt, steht im Leistungsumfang.
Außerdem verschiebt sich die Verantwortung: Gehasht oder nicht, Kundenkennungen liegen in einer Datenbank auf der Seite des Kunden und werden von dort gesendet, und das gehört in den Vertrag.
Wie wir solche Projekte abgrenzen und bepreisen, steht unter Leistungen.
