CASE · SERVERSEITIGES TRACKING
Wenn Kunden auf der Website buchen, aber erst nach erledigter Arbeit bezahlen, geht die Spur oft verloren. Auf der Infrastruktur von Stape haben wir für die dänischen Marktplätze Handyhand und HappyHelper ein webhook-basiertes serverseitiges Setup aufgebaut – mit 50 % mehr gemessenen Events und erstmals einem verlässlichen Blick auf den ROAS.
Zwei Marktplätze – ein Messproblem
Handyhand vermittelt lokale Helfer für Alltagsaufgaben, HappyHelper organisiert regelmäßige Reinigung in Privathaushalten – tausende Einsätze pro Monat. Beide Unternehmen sind auf bezahlte Werbung angewiesen, und beide stehen vor derselben Herausforderung: Der Kunde klickt auf eine Anzeige und bucht auf der Website, doch der eigentliche Wert entsteht erst später. Der Auftrag wird erledigt und die Zahlung vom Dienstleister abgewickelt – oft Tage später und auf einem ganz anderen Gerät.
Mit klassischem browserbasiertem Tracking sehen Werbeplattformen deshalb nur die erste Hälfte der Customer Journey. Der tatsächliche Umsatz und die abgeschlossenen Aufträge werden nie der Kampagne zugeordnet, die sie ausgelöst hat.
Safari verschärft das Problem
Laut der Case Study entfielen rund 25,5 % der Nutzer auf Safari – in einzelnen Zeiträumen sogar bis zu 48 % des Traffics und über 50 % der Verkäufe. Safaris Intelligent Tracking Prevention kann Cookies bereits nach 24 Stunden löschen. Für ein Geschäft, bei dem zwischen Buchung und Zahlung Tage vergehen, bricht die Verbindung zwischen Klick und Conversion also gerade bei einer der wertvollsten Nutzergruppen ab.
Die Lösung: Webhooks und serverseitiges GTM auf Stape
Wir haben ein cookieloses serverseitiges Setup in Google Tag Manager aufgebaut, gehostet auf der Infrastruktur von Stape. Die Kernelemente:
- Ein eigener serverseitiger GTM-Container, der Daten aus mehreren Quellen bündelt: Website, Apps, CRM und Offline-Ereignisse.
- Webhooks über den Stape Data Client: Die Backend-Systeme senden einen POST-Request, sobald ein Auftrag erledigt oder eine Zahlung abgeschlossen ist – unabhängig vom Gerät des Dienstleisters.
- Stape Store zur Speicherung verschlüsselter User-IDs, damit das spätere Ereignis der ursprünglichen Buchung und damit dem Anzeigenklick zugeordnet werden kann.
- Stape User ID als stabile Kennung, die nicht von kurzlebigen Browser-Cookies abhängt.
- Consent first: Weitergegeben werden nur First-Party-Daten von Nutzern, die eingewilligt haben – DSGVO-konform.
Ergebnisse
- 50 % mehr gemessene Events im Vergleich zum Setup ohne Webhooks.
- End-to-End-Attribution vom Anzeigenklick bis zum erledigten und bezahlten Auftrag.
- Erstmals echter ROAS – auf Basis des tatsächlichen Umsatzes statt der Buchungen.
- Bessere Optimierung, da die Algorithmen der Werbeplattformen nun Signale zu den Conversions erhalten, die wirklich Wert schaffen.
- Robustheit gegenüber Safari und anderen Browser-Einschränkungen.
- Messung von Ereignissen, die zuvor nicht erfassbar waren.
Was lässt sich daraus lernen?
Der Case ist für jedes Unternehmen relevant, bei dem die Conversion nicht im Browser stattfindet: Marktplätze, Abonnements, Leadgenerierung mit Vertrieb über Telefon oder CRM sowie Dienstleistungen, bei denen die Zahlung nach der Leistung erfolgt. Wenn Ihre wichtigsten Ereignisse im Backend passieren, sollte auch die Messung dort beginnen. Webhooks und serverseitiges Tracking ermöglichen es, die richtigen Signale an Meta, Google und andere Plattformen zu senden – ohne Abstriche bei Einwilligung und Datensicherheit.
Obsidian ist Top-Partner von Stape, und der Case ist auch im Stape-Blog beschrieben. Sie möchten wissen, wie ein ähnliches Setup bei Ihnen aussehen könnte? Erfahren Sie mehr über serverseitiges Tracking bei Obsidian oder sprechen Sie mit unserem Tracking-Team.
