Konverzióduplikáció

Az affiliate marketingben a konverzióduplikáció megakadályozza, hogy ugyanazon jogosult művelet több rögzítése ismétlődő konverziókat vagy jutalékokat eredményezzen. Erre akkor van szükség, ha az eseményeket újrapróbálják elküldeni, újratöltik a köszönőoldalakat, vagy a böngészős és szerveroldali követés ugyanazt a rendelést jelenti. Az egyeztetési kulcsnak és az esemény hatókörének különbséget kell tennie a duplikátumok és a jogszerűen ismétlődő tevékenységek között.

Miért érkezhet be kétszer ugyanaz a konverzió?

Az ügyfél frissítheti a visszaigazoló oldalt, a szerver újrapróbálkozhat egy időtúllépés miatt meghiúsult kéréssel, vagy a program egyszerre használhat böngészős és szerveroldali adatküldést. Két integráció ugyanazt az üzleti eseményt is beküldheti. Ezek kézbesítési helyzetek, nem feltétlenül két különböző vásárlás.

Duplikált esemény vagy jogos új esemény

A megfelelő kezelés attól függ, mely műveletek után jár jutalék. Ha egy program egy rendelés több különálló, jogosult eseménye után is fizet, részletesebb kulcsokra lehet szüksége, mint egy kizárólag rendelésszinten működő programnak.

Mit tartalmazzon a kulcs?

Használjon stabil forrásazonosítókat és megfelelő hatókört, például a kereskedői fiókot, az eseménytípust, valamint a tranzakció- vagy számlaazonosítót. Ne használjon önmagában időbélyeget: külön eseményeknek is lehet azonos időpontja, az újrapróbálkozások pedig később is beérkezhetnek. Az integrációkban következetesen alkalmazza az egyeztetési szabályokat.

Mit kell tesztelni?

• Azonos adatok ismételt elküldése.
• Böngészős és szerveroldali események beérkezése mindkét lehetséges sorrendben.
• Ugyanazon műveletre vonatkozó egyidejű kérések.
• Új rendelés vagy megújítás ugyanannak az ügyfélnek.
• Javított összeg vagy későbbi visszatérítés.

Ha két jelentés eltér, határozza meg, melyik forrás a mérvadó. Ha csendben az első eseményt fogadja el, előfordulhat, hogy a hibás összeg marad érvényben; ha mindkettőt elfogadja, túlfizetés történhet. A duplikációszűrés az esemény azonosságát kezeli; az ellenőrzés pedig az üzleti jogosultságot és a helyes értékeket állapítja meg.

Milyen problémát nem old meg?

A duplikációszűrés nem dönti el, hogy két valóban különböző ajánlás közül melyik után jár a jóváírás. Azt sem állapítja meg, hogy egy tranzakció valódi-e, vagy megengedett-e egy promóciós módszer. Ezekhez attribúciós és csalásvizsgálati szabályokra van szükség a duplikátumok kezelésén felül.

Hogyan vizsgálhatja ki egy adminisztrátor a duplikátumot?

Hasonlítsa össze a forrásazonosítókat

Keresse meg a kereskedőt, a rendelést vagy számlát, az eseménytípust, az eredeti értéket és az adatküldés forrását. A hasonló időpontban beérkező két rekord két valódi értékesítés is lehet, míg ugyanannak a műveletnek a több perces eltéréssel történő beérkezése újrapróbálkozást jelezhet. Ne csak az időbeli közelségre épülő szabályt használja, hanem a stabil üzleti azonosítót.

Kérdések kétcsatornás követés esetén

1. A böngészős és szerveroldali jelentések ugyanazt a forrásbeli rendelésazonosítót használják?
2. Az összegek pénzneme és a jutalékalapként figyelembe vett értékek összhangban vannak?
3. Melyik forrás a mérvadó, ha az összegek eltérnek?
4. Hogyan különböztetik meg a frissítéseket az új konverzióktól?
5. A megújítási és visszatérítési események külön azonosítót kapnak?
6. Az alkalmazott döntés rekonstruálható egy auditnapló alapján?

A Post Affiliate Pro ismétlődő események elleni védelmének dokumentációja ismerteti a platform vezérlőit. Ne feltételezze, hogy egyetlen beállítás minden böngészős és szerveroldali átfedést kezel; ellenőrizze a tényleges egyeztetési szabályokat.

Mi történik, ha ugyanaz az esemény megváltozik?

Egy korrekció esetén a második jelentés teljes elutasítása helyett frissítésre lehet szükség. Például egy 100 dolláros rendelés után később 20 dollár visszatérítés történhet. Az eredeti értékesítésnek nem szabad eltűnnie, a visszatérítést pedig nem szabad új értékesítésként kezelni.

A Stripe visszatérítésekről szóló referenciája szemlélteti a külön azonosított fizetési korrekciókat. Kapcsolja ezeket a forrásrekordokat a megfelelő eredeti tranzakcióhoz, és alkalmazza az affiliate-szabályzatot. A duplikációszűrésnek meg kell őriznie a lényeges frissítéseket, miközben megakadályozza, hogy az ismételt jelentések további jutalmakat eredményezzenek.

Minden jutalékköteles eseményhez válasszon azonosítót

A tranzakcióazonosító csak meghatározott hatókörön belül használható. Ugyanaz az azonosító különböző kereskedői fiókokban vagy eseménytípusoknál is előfordulhat. Előfizetések esetén használjon számlázási esemény- vagy számlaazonosítót, és ne szűrjön ki minden fizetést ugyanazon ügyfél- vagy előfizetésazonosító alapján.

Egy feltételezett, kétcsatornás fizetési folyamatban a pixel és a postback is az order-1042 rendelést jelenti. A követőrendszernek egyetlen értékesítési jutalékot kell létrehoznia. Egy későbbi, jogosult megújításnak saját azonosítóra van szüksége; a visszatérítésnek pedig az eredeti értékesítéshez kapcsolt korrekciós eseménynek kell lennie, nem újabb értékesítésnek.

Tartsa nyilván az elfogadott eseményeket, és tegye az újrapróbálkozásokat idempotenssé. A Stripe webhookokra vonatkozó útmutatója szemlélteti, miért fontosak az eseményazonosítók és az esemény kontextusa, ha az adatküldés ismétlődik. Tesztelje az egyidejű beérkezéseket és a késleltetett újrapróbálkozásokat is, ne csak az egyszerű oldalfrissítéseket.

A megfelelő Post Affiliate Pro-beállításokért tekintse meg a csalás elleni védelem dokumentációját . Ellenőrizze a konfigurációt és az integrációs követelményeket a program szabályai alapján.