Deduplizierung von Conversions

Im Affiliate-Marketing verhindert die Deduplizierung von Conversions, dass mehrere Datensätze derselben zulässigen Aktion doppelte Conversions oder Provisionen erzeugen. Sie ist erforderlich, wenn Ereignisse erneut gesendet werden, Bestätigungsseiten neu geladen werden oder Browser- und Server-Tracking dieselbe Bestellung melden. Der Abgleichsschlüssel und der Ereignisumfang müssen Duplikate von legitimen wiederholten Aktivitäten unterscheiden.

Warum kann dieselbe Conversion zweimal eingehen?

Ein Kunde kann eine Bestätigungsseite aktualisieren, ein Server kann eine Anfrage nach einer Zeitüberschreitung erneut senden oder ein Programm kann Browser- und Serverübermittlung gleichzeitig verwenden. Auch zwei Integrationen können dasselbe geschäftliche Ereignis übermitteln. Das sind Übermittlungsszenarien und nicht unbedingt zwei verschiedene Käufe.

Doppeltes Ereignis oder legitimes neues Ereignis?

Die gewünschte Behandlung hängt davon ab, welche Aktionen provisionsfähig sind. Ein Programm, das mehrere zulässige Ereignisse aus einer Bestellung vergütet, benötigt möglicherweise detailliertere Schlüssel als ein Programm, das nur Bestellungen berücksichtigt.

Was sollte der Schlüssel enthalten?

Verwenden Sie stabile Kennungen aus der Quelle und einen passenden Umfang, etwa Händlerkonto, Ereignistyp sowie Transaktions- oder Rechnungs-ID. Verwenden Sie nicht ausschließlich einen Zeitstempel: Separate Ereignisse können denselben Zeitpunkt haben, und erneute Übermittlungen können später eintreffen. Halten Sie die Abgleichsregeln über alle Integrationen hinweg konsistent.

Was sollte getestet werden?

• Wiederholte Übermittlung mit identischen Daten.
• Browser- und Serverereignisse, die in beliebiger Reihenfolge eintreffen.
• Gleichzeitige Anfragen für dieselbe Aktion.
• Eine neue Bestellung oder Verlängerung für denselben Kunden.
• Ein korrigierter Betrag oder eine spätere Rückerstattung.

Legen Sie fest, welche Quelle maßgeblich ist, wenn zwei Meldungen voneinander abweichen. Wer stillschweigend das erste Ereignis akzeptiert, behält möglicherweise den falschen Betrag bei; wer beide akzeptiert, zahlt unter Umständen zu viel. Die Deduplizierung klärt die Ereignisidentität; die Validierung klärt die geschäftliche Berechtigung und die korrekten Werte.

Was kann die Deduplizierung nicht leisten?

Die Deduplizierung entscheidet nicht, welcher von zwei tatsächlich unterschiedlichen Empfehlungen die Provision erhalten soll. Ebenso wenig stellt sie fest, ob eine Transaktion echt oder eine Werbemethode zulässig ist. Dafür sind neben der Behandlung von Duplikaten auch Regeln zur Attribution und Betrugsprüfung erforderlich.

Wie kann ein Administrator ein Duplikat untersuchen?

Quellenkennungen vergleichen

Prüfen Sie Händler, Bestellung oder Rechnung, Ereignistyp, ursprünglichen Wert und Übermittlungsquelle. Zwei Datensätze, die zu ähnlichen Zeitpunkten eingehen, können zwei echte Verkäufe sein, während eine Aktion, die mehrere Minuten später erneut eingeht, ein erneuter Übermittlungsversuch sein kann. Verwenden Sie die stabile geschäftliche Kennung und verlassen Sie sich nicht allein auf eine zeitliche Nähe.

Fragen zu einem Dual-Tracking-Setup

1. Verwenden Browser- und Servermeldungen dieselbe Quellkennung der Bestellung?
2. Stimmen ihre Währungen und provisionsfähigen Werte überein?
3. Welche Quelle ist maßgeblich, wenn die Beträge voneinander abweichen?
4. Wie werden Aktualisierungen von neuen Conversions unterschieden?
5. Werden Verlängerungs- und Rückerstattungsereignisse separat gekennzeichnet?
6. Lässt sich die angewandte Entscheidung anhand eines Prüfprotokolls nachvollziehen?

Die Dokumentation zum Schutz vor wiederholten Ereignissen von Post Affiliate Pro beschreibt Plattformkontrollen. Prüfen Sie die tatsächlichen Abgleichsregeln, statt anzunehmen, dass eine einzelne Einstellung jede Überschneidung von Browser- und Servermeldungen behebt.

Was passiert, wenn sich dasselbe Ereignis ändert?

Eine Korrektur kann eine Aktualisierung erfordern, statt die zweite Meldung vollständig zu unterdrücken. Beispielsweise kann auf eine Bestellung über 100 $ später eine Rückerstattung über 20 $ folgen. Der ursprüngliche Verkauf sollte nicht verschwinden, und die Rückerstattung sollte nicht als neuer Verkauf gelten.

Die Referenz zu Rückerstattungen von Stripe veranschaulicht separat gekennzeichnete Zahlungsanpassungen. Verknüpfen Sie diese Quelldatensätze mit der passenden ursprünglichen Transaktion und wenden Sie die Affiliate-Richtlinie an. Bei der Deduplizierung müssen aussagekräftige Aktualisierungen erhalten bleiben, während wiederholte Meldungen keine zusätzlichen Vergütungen auslösen dürfen.

Für jedes provisionsfähige Ereignis eine Identität festlegen

Eine Transaktions-ID ist nur innerhalb eines festgelegten Umfangs sinnvoll. Dieselbe Kennung kann in unterschiedlichen Händlerkonten oder Ereignistypen vorkommen. Verwenden Sie bei Abonnements die Identität eines Abrechnungsereignisses oder einer Rechnung, statt jede Zahlung mit derselben Kunden- oder Abonnement-ID zu unterdrücken.

Bei einem hypothetischen Checkout mit Dual-Tracking melden sowohl das Pixel als auch das Postback die Bestellung order-1042. Der Tracker sollte eine einzige Verkaufsprovision erstellen. Eine spätere zulässige Verlängerung benötigt eine eigene Identität; eine Rückerstattung benötigt ein mit dem ursprünglichen Verkauf verknüpftes Anpassungsereignis und darf keinen weiteren Verkauf darstellen.

Führen Sie ein Protokoll akzeptierter Ereignisse und gestalten Sie erneute Übermittlungen idempotent. Die Webhook-Leitlinien von Stripe veranschaulichen, warum Ereignis-IDs und Ereigniskontext bei wiederholten Zustellungen wichtig sind. Testen Sie neben einfachen Seitenaktualisierungen auch gleichzeitige Eingänge und verzögerte erneute Übermittlungen.

Informationen zu den entsprechenden Einstellungen in Post Affiliate Pro finden Sie in der Dokumentation zum Schutz vor Betrug . Prüfen Sie die Konfiguration und Integrationsanforderungen anhand der Regeln Ihres Programms.