Der bestätigte Vorgang sollte die Grundlage sein
Eine Bestellung kann im Shop gespeichert sein, während die abschließende Meldung aus dem Browser ausbleibt. Vielleicht wurde die Seite geschlossen, ein Skript nicht ausgeführt oder eine Verbindung unterbrochen. Wenn die Messung ausschließlich diesen letzten Browseraufruf nutzt, können tatsächlicher Vorgang und gemeldetes Ergebnis auseinanderfallen.
Server-to-Server bedeutet, dass dein System ein Ereignis direkt an ein anderes System überträgt. Für Meta bietet die Conversions API diesen Übertragungsweg. Metas eigenes Business SDK unterstützt damit Web-, App- und Offlineereignisse vom Server. Entscheidend ist, dass der Auslöser zur vereinbarten Bedeutung passt, etwa eine erfolgreich angenommene Anfrage oder bestätigte Bestellung.
Eine Serverweiterleitung und ein Backendereignis sind zu unterscheiden
Beim Server-Side-Tagging werden Messdaten in einem eigenen Servercontainer verarbeitet und weitergeleitet. Das kann die Kontrolle über Empfänger und Datenumfang verbessern. Eine solche Verarbeitung ist jedoch nicht gleichbedeutend damit, dass jeder Vorgang unabhängig vom Browser erfasst wird.
Wenn die Nachricht ursprünglich nur im Browser entsteht, kann sie bereits vor der Serverweiterleitung fehlen. Eine Anbindung an den bestätigten Vorgang im Shop oder Formularsystem hat eine andere Grundlage. Prüfe deshalb die Quelle jedes wichtigen Ereignisses. Ein neuer Servercontainer allein schließt keine beliebige Messlücke.
So kann ein brauchbarer Ablauf aussehen
Das folgende Beispiel beschreibt einen angenommenen Shopablauf. Es enthält keine echten Kundendaten. Vor der Übertragung wird geprüft, welche Verarbeitung für diesen Vorgang und Zweck zulässig ist.
- Der Shop bestätigt und speichert die Bestellung.
- Der Vorgang erhält eine eindeutige, stabile Ereignis-ID.
- Das System stellt Ereignisname, tatsächlichen Zeitpunkt sowie vereinbarten Wert und Währung bereit.
- Die zulässigen Daten werden über die vorgesehene Schnittstelle übertragen.
- Erfolg oder Fehler der Übertragung wird protokolliert.
- Eine notwendige Wiederholung verwendet dieselbe Vorgangsidentität.
Ein Kauf darf nicht zweimal als neuer Kauf erscheinen
Wer Browserpixel und Conversions API kombiniert, kann denselben Vorgang über beide Wege melden. Meta verwendet laut seinem Business SDK Ereignisname und Ereignis-ID, um entsprechende Browser- und Serverereignisse als identisch zu erkennen. Die gemeinsame Kennung muss deshalb zusammenpassen.
Lege die ID für den tatsächlichen Vorgang fest und erzeuge bei einem erneuten Versand keine neue Identität. Bei neuen Käufen sind dagegen neue Kennungen erforderlich. Prüfe die Doppelzählungsvermeidung mit bekannten Testvorgängen. Eine bloß ankommende Servermeldung zeigt noch nicht, dass sie richtig mit der Browsermeldung zusammengeführt wird.
Zuordnung, Datenqualität und Geschäftsergebnis sind eigene Fragen
Die Plattform muss eine eingegangene Meldung unter den jeweiligen Bedingungen zuordnen können. Welche zulässigen Angaben dafür vorhanden sind, hängt von Kontaktweg und Einrichtung ab. Eine korrekte Ereignis-ID dient zunächst der Wiedererkennung des Vorgangs. Sie ist kein Ersatz für die passende Ereignisdefinition oder die übrige Datenprüfung.
Auch mit einer Serveranbindung bleiben Grenzen. Eine vollständige Zuordnung aller Käufe zu Anzeigen oder eine bestimmte Umsatzsteigerung ist nicht garantiert. Vergleiche Plattformmeldungen mit den tatsächlichen Vorgängen und erläutere Abweichungen. Mehr gemeldete Ereignisse können eine bessere Erfassung bedeuten; sie sind für sich genommen noch kein zusätzliches Geschäft.
Serverseitige Übertragung braucht dieselbe sorgfältige Datenentscheidung
Server-to-Server ist eine technische Verbindung, keine pauschale Ausnahme von Datenschutzanforderungen. Lege Zweck, Empfänger, zulässige Felder und den Umgang mit Einwilligungsentscheidungen fest. Google beschreibt, wie entsprechende Signale auch im serverseitigen Tagging berücksichtigt werden.
Eine gehashte E-Mail-Adresse wird durch die Umwandlung nicht automatisch anonym. Bei weiterhin möglicher Zuordnung können personenbezogene Daten vorliegen. Übertrage deshalb nur die für den geprüften Zweck erforderlichen und zulässigen Angaben. Inhalte aus Nachrichten, besondere persönliche Angaben und ungeprüfte Freitextfelder gehören nicht automatisch in ein Werbeereignis.
Die Verbindung muss im Alltag überwacht werden
Eine Schnittstelle kann ausfallen oder eine Meldung ablehnen. Plane einen sichtbaren Kontrollweg und eine begrenzte Wiederholung fehlgeschlagener Übertragungen. Dabei müssen Vorgangsidentität und tatsächlicher Ereigniszeitpunkt erhalten bleiben. Jemand im Betrieb sollte erkennen können, welche Meldungen noch offen sind.
Kontrolliere außerdem Änderungen an Formularen, Zahlungsabläufen und angebundenen Systemen. Vergleiche regelmäßig eine überschaubare Stichprobe bestätigter Vorgänge mit den übertragenen Ereignissen. Eine gepflegte Serveranbindung ist damit ein wichtiger Teil verlässlicher Messung: Sie verbindet den tatsächlichen Geschäftsschritt mit der technischen Meldung und ihrer überprüfbaren Verarbeitung.