Serverseitiges Tracking

Was sich tatsächlich ändert: wo das Ereignis zusammengestellt und gesendet wird

Mit einem Browser-Pixel stellt ein Skript, das auf dem Gerät des Käufers läuft, das Ereignis zusammen. Es liest die Seite nach Bestellwert und -inhalten aus, liest seine eigenen Cookies nach Klick- und Browser-Identifikatoren aus und sendet die Nutzdaten von dem Gerät an die Domain der Plattform. Alles an dieser Kette liegt außerhalb Ihrer Kontrolle: Das Skript muss laden, ausführen und seine Anfrage abschließen, bevor der Käufer wegnavigiert, auf einem Gerät, das möglicherweise einen Ad-Blocker und einen Browser ausführt, der die Lebensdauer der Cookies begrenzt.

Bei serverseitiger Übermittlung erstellt Ihr Server das Ereignis aus Datensätzen, die er bereits besitzt — die Bestellung, den Kunden, die Artikelpositionen — und sendet es als Server-zu-Server-Aufruf, authentifiziert mit einem Zugriffstoken, an den Konversions-Endpunkt der Plattform. Der Browser des Käufers ist zum Zeitpunkt des Sendens nicht beteiligt. Das Ereignis wird ausgelöst, weil eine Bestellung in Ihre Datenbank geschrieben wurde, was das zuverlässigste Signal im Geschäft ist.

Auch die Identifikatoren ändern ihre Form. Anstatt sich auf ein Cookie zu verlassen, das der Browser möglicherweise gelöscht hat, sendet der Server gehashte Match-Keys — normalisierte E-Mail-Adresse, Telefonnummer, Name, Postleitzahl — zusammen mit jedem Klick-Identifikator, der erfasst wurde, als der Käufer landete und mit der Bestellung gespeichert wurde, plus IP-Adresse und User-Agent. Die Match-Qualität hängt dann davon ab, was Sie beim Checkout gesammelt haben, und nicht davon, was der Browser beibehalten hat.

Was es behebt und was nicht

Es behebt die Übermittlung. Kaufereignisse, die durch ein blockiertes Skript, eine fehlgeschlagene Anfrage oder das Schließen des Tabs durch einen Käufer bei der Zahlungsweiterleitung verloren gingen, kommen jetzt an, und sie kommen mit Match-Keys an, die aus dem Bestelldatensatz stammen, anstatt aus dem, was im Browser überlebt hat. Es erschließt auch eine Klasse von Ereignissen, die der Browser überhaupt nicht sehen kann: Rückerstattungen, Abonnementverlängerungen, Rückbuchungen, Stornierungen und Offline- oder Telefonbestellungen, die alle lange nach Beendigung der Sitzung stattfinden und die alle wesentlich ändern, worauf die Plattform optimieren sollte.

Es behebt nicht die Zustimmung. Dies ist das häufigste Missverständnis und das teuerste. Die Verpflichtung bezieht sich auf die Verarbeitung personenbezogener Daten, nicht auf die Leitung, über die sie übertragen werden. Das Senden eines Ereignisses über einen Käufer, der die Zustimmung verweigert hat, ist dieselbe Verarbeitung mit einem längeren Weg, und die Zustimmungsentscheidung muss nun vom Browser in Ihren Bestelldatensatz übertragen werden, damit der Server weiß, ob er überhaupt senden darf — eine Aufgabe, die das Pixel implizit erledigte.

Es erstellt keine Identität, die Sie nie gesammelt haben. Ein Gast-Checkout ohne E-Mail und ohne gespeicherten Klick-Identifikator ist ungematcht, egal ob das Ereignis von einem Browser oder einem Server kommt. Es ersetzt auch keine On-Page-Verhaltenssignale: Wenn Sie Scrolltiefe oder In-den-Warenkorb-Interaktionen serverseitig wünschen, muss der Browser sie Ihnen immer noch zuerst melden.

Und es verbessert nicht die Leistung, sondern nur das Reporting. Das Einschalten erhöht sofort die gemeldeten Konversionen und senkt die gemeldeten Kosten pro Akquisition, weil Ereignisse, die immer stattfanden, jetzt gezählt werden. Das ist ein Bruch in der Zeitreihe, kein Ergebnis. Markieren Sie das Datum im Diagramm und lassen Sie niemanden den Folgemonat mit dem Vormonat vergleichen, als ob sich die Kampagnen geändert hätten.

Deduplizierung: der Ereignis-ID-Vertrag

Sobald beide Wege aktiv sind, wird jede vom Browser erfolgreich gemeldete Konversion auch vom Server gemeldet. Die Plattform zählt beide, es sei denn, Sie teilen ihr mit, dass es sich um dasselbe Ereignis handelt, und die Art und Weise, wie Sie es ihr mitteilen, ist ein gemeinsamer Ereignis-Identifikator: Beide Seiten senden denselben Ereignisnamen und dieselbe ID, die Plattform behält das zuerst eintreffende und verwirft das andere innerhalb ihres Deduplizierungsfensters.

Veranschaulichen Sie das Risiko mit einem Beispiel. Angenommen, 1.000 echte Käufe in einem Monat und dass 30% der Browser-Ereignisse verloren gehen — der Browser meldet 700, der Server meldet alle 1.000. Ohne Deduplizierung erfasst die Plattform 1.700 Konversionen gegenüber 1.000 echten, eine 70%ige Übertreibung, und die gemeldeten Kosten pro Akquisition sinken auf etwa 59% des tatsächlichen Werts. Der Optimierer lernt dann aus einem Signal, bei dem einige Bestellungen doppelt und andere einmal gezählt werden, was schlechter ist als jeder Weg allein.

• Leiten Sie die ID von etwas ab, das beide Seiten bereits kennen — die Bestell-ID ist die offensichtliche Wahl. Das unabhängige Generieren einer zufälligen ID auf jeder Seite garantiert, dass sie niemals übereinstimmen.
• Halten Sie die ID bei Wiederholungsversuchen stabil. Ein Wiederholungsversuch, der den Identifikator neu generiert, verwandelt Ihre eigene Fehlerbehandlung in eine Maschine für doppelte Zählungen.
• Stimmen Sie den Ereignisnamen genau ab, einschließlich Groß-/Kleinschreibung und Typ. Plattformen deduplizieren anhand des Paares, sodass ein Browser-Ereignis und ein Server-Ereignis, die sich nur in der Benennung unterscheiden, beide beibehalten werden.
• Senden Sie die Browser-Klick- und Browser-Identifikatoren auch mit dem Server-Ereignis. Sie ermöglichen es der Plattform, die beiden Berichte als denselben Benutzer zu erkennen, nicht nur als dieselbe Bestellung.
• Beachten Sie das Deduplizierungsfenster. Ein Tage später übermitteltes Ereignis — ein verzögerter Webhook, eine Nachlieferung — liegt außerhalb dessen und wird erneut gezählt.
• Testen Sie mit echten Bestellungen, bevor Sie den Zahlen vertrauen, und gleichen Sie die gemeldete Konversionszahl der Plattform mit Ihrer eigenen Bestellzahl für denselben Zeitraum ab. Sie sollten nah beieinander liegen; eine systematische Abweichung in beide Richtungen ist ein Verdrahtungsfehler.

Die Betriebskosten, für die niemand budgetiert

Ein Pixel ist ein Tag, den jemand einmal einfügt. Serverseitige Übermittlung ist ein Dienst, den Sie jetzt besitzen, mit einem Zugriffstoken, einem Schema, einer Wiederholungsrichtlinie und einem Fehlermodus, und jeder davon fällt stillschweigend aus. Ein abgelaufenes Token, eine Plattform-API-Version, die die von Ihnen gesendete Nutzlast nicht mehr akzeptiert, ein Deployment, das die Erfassung des Klick-Identifikators auf der Landingpage unterbrochen hat, ein Hashing-Fehler, bei dem E-Mail-Adressen vor dem Hashing nicht in Kleinbuchstaben umgewandelt und gekürzt wurden – nichts davon führt zu einem Fehler, den das Marketingteam sehen würde. Sie äußern sich als allmählicher Rückgang der Übereinstimmungsqualität oder ein plötzlicher Rückgang der Conversions, der genau wie eine schlechte Werbewoche aussieht.

Die Überwachung ist also nicht optional und einfach: Vergleichen Sie täglich gesendete Server-Ereignisse mit erstellten Bestellungen und alarmieren Sie bei Abweichungen. Beobachten Sie die ereignisbezogenen Diagnosen oder den Übereinstimmungsqualitäts-Score der Plattform, denn eine sinkende Übereinstimmungsrate ist in der Regel ein Datenproblem und kein Zielgruppenproblem. Protokollieren Sie die Antwort auf jede Sendung, anstatt sie einfach zu senden und zu vergessen, da eine abgelehnte Nutzlast sonst nicht von einer erfolgreichen zu unterscheiden ist.

Planen Sie auch Budget für die Consent-Infrastruktur ein. Die Entscheidung muss im Browser erfasst, mit der Bestellung gespeichert und vom Server gelesen werden, bevor er sendet – drei Komponenten, die alle übereinstimmen müssen, in einem System, in dem der Fehler in die eine Richtung stillschweigend und in die andere ein Compliance-Problem ist.

Die ehrliche Zusammenfassung ist, dass serverseitiges Tracking eine Kategorie von Unzuverlässigkeit, die Sie nicht beheben können, gegen eine Kategorie von Wartung tauscht, die Sie beheben können. Das ist in der Regel der richtige Tausch, und es hört auf, der richtige Tausch zu sein, wenn niemand die Pipeline nach dem Quartal, in dem sie gebaut wurde, betreuen wird.