La réponse en bref
Pour contrôler les doublons, séparez l'identité de la conversion, celle de l'événement qui la décrit et celle de chaque tentative de livraison. Une reprise réseau ne doit pas créer une deuxième vente ; une mise à jour légitime de statut ne doit pas disparaître comme doublon. Définissez une clé stable avec le fournisseur, vérifiez son périmètre et rapprochez les enregistrements des deux côtés. Le nombre de requêtes reçues ne constitue jamais, à lui seul, un décompte fiable des conversions rémunérables.
Nommer ce qui se répète avant de supprimer une ligne
Une commande, une conversion, un événement et une requête ne sont pas toujours le même objet. Une commande peut produire plusieurs changements de statut. Le même événement peut ensuite être envoyé plusieurs fois parce que la première réponse s'est perdue. Dans un journal, ces tentatives peuvent apparaître comme plusieurs lignes sans représenter plusieurs achats. Avant de parler de doublon, identifiez l'objet dont vous voulez mesurer l'unicité et la règle commerciale qui transforme cet objet en rémunération.
Utilisez un exemple fictif dans votre dossier : la conversion conv-42 reçoit d'abord un événement de validation evt-7, puis deux tentatives de livraison de cet événement. Le tableau de transport contient deux tentatives, mais le tracker doit interpréter l'événement selon une seule identité métier. Si une annulation survient plus tard, elle mérite son propre traitement ; elle ne doit pas être ignorée uniquement parce qu'elle concerne la même conversion conv-42.
Choisir une clé stable et un périmètre explicite
La clé de déduplication doit provenir d'une identité documentée par le circuit émetteur. Un horodatage construit à la réception ou un numéro aléatoire généré pour chaque tentative ne convient pas pour reconnaître une reprise. Une comparaison fondée seulement sur le montant et la minute peut aussi fusionner deux ventes réelles. Demandez quel identifiant demeure identique lors d'un renvoi et quels champs changent lorsqu'un véritable nouvel événement est produit.
Précisez le périmètre dans lequel cet identifiant est unique : fournisseur, compte, campagne ou autre espace documenté. Deux partenaires peuvent employer des numéros courts identiques sans désigner la même conversion. Une contrainte trop large risque alors d'effacer un événement valide ; une contrainte trop étroite peut laisser passer plusieurs copies de la même notification. Cette définition appartient au contrat de données et doit être confirmée avant la mise en place d'un filtre automatique.
Distinguer reprise technique et transition de statut
Pour une reprise technique, le destinataire doit reconnaître l'événement déjà traité et éviter un nouvel effet commercial. Pour une transition de statut, il doit appliquer le changement prévu par le contrat. La documentation Stripe illustre cette distinction générale en signalant que des notifications peuvent être dupliquées et que leur ordre d'arrivée n'est pas garanti. Ce comportement fournisseur est un exemple de conception à considérer, pas une description universelle de tous les réseaux.
Imaginez un événement de validation arrivé avant une notification plus ancienne de mise en attente. Une mise à jour naïve fondée uniquement sur l'ordre de réception pourrait faire revenir la conversion à un état dépassé. Définissez donc comment le circuit compare les événements et quels changements sont autorisés. L'affilié n'a pas à inventer cette logique dans un tableur : il doit connaître la politique appliquée par le réseau et son tracker pour interpréter les écarts.
Tester la déduplication avec des scénarios qui se distinguent
Dans un environnement autorisé, préparez quatre cas : le même événement reçu deux fois, deux événements distincts portant le même montant, une mise à jour de statut et deux espaces fournisseurs utilisant le même identifiant court. Écrivez le résultat attendu avant l'essai. Le premier cas vérifie l'absence de double effet ; les autres vérifient qu'une protection contre les doublons ne bloque pas des données légitimes. Utilisez des identifiants synthétiques et excluez ces essais des revenus commerciaux.
Ajoutez un scénario de réponse perdue si l'équipe technique peut le reproduire hors production : le destinataire a traité l'événement, mais l'émetteur n'a pas reçu sa confirmation. La reprise doit rester reconnaissable. Conservez les identifiants, les résultats applicatifs et les compteurs avant et après le test. Un simple code HTTP ne démontre pas que le second traitement a été neutralisé ; il faut constater l'état final attendu dans le système destinataire.
Enquêter sur un écart sans réécrire le registre financier
Si le tracker affiche plus de conversions que le réseau, comparez d'abord le périmètre temporel, les statuts inclus et les identifiants. Recherchez ensuite les événements ayant plusieurs tentatives et vérifiez leurs effets dans le tracker. Une différence de total peut aussi provenir d'une validation tardive, d'un rejet ou d'un filtre différent. Supprimer toutes les lignes portant le même montant risquerait de masquer la vraie cause et de retirer des conversions légitimes.
Constituez une liste d'écarts, pas un export massif de données clients : identifiant de conversion, événement, nombre de tentatives, statut réseau, statut destinataire et décision à prendre. Faites valider toute correction de revenu ou de rapprochement financier par le responsable habilité. Gardez la trace originale et l'explication de la correction. L'objectif est de rétablir une lecture exacte, non de forcer les totaux à devenir identiques sans comprendre leur définition.
Préparer les reprises et changements de destinataire
Une relance manuelle, une panne ou un changement de tracker peut réintroduire des événements déjà reçus. Avant une reprise, demandez l'intervalle concerné, les identifiants inclus, les tentatives précédentes et la politique de déduplication du nouveau destinataire. N'attribuez pas une nouvelle identité à un événement historique uniquement pour qu'il soit accepté. Cela transformerait une opération de récupération en nouvelle activité apparente et compliquerait le rapprochement des commissions.
Pour préparer votre configuration Cash Nutra, présentez votre tracker au manager et demandez comment ses retours distinguent événements, statuts et tentatives. Un lien personnel et un postback bien configurés constituent le départ ; une preuve contrôlée de traitement unique complète le dossier. Conservez cette preuve avec les paramètres de campagne afin que la personne qui reprendra le compte sache pourquoi une notification répétée n'appelle ni nouvelle vente ni nouvelle rémunération.
Avant de vous lancer
- Définir séparément conversion, événement et tentative de livraison.
- Confirmer la stabilité et le périmètre de la clé de déduplication.
- Préserver les transitions légitimes de statut et les événements distincts.
- Tester répétition, mise à jour, espaces distincts et réponse perdue hors production.
- Rapprocher les effets applicatifs avant toute correction des revenus.
Questions fréquentes
Deux requêtes identiques représentent-elles deux conversions ?
Pas nécessairement : elles peuvent être deux tentatives de livraison du même événement. Comparez leurs identifiants et leur effet dans le destinataire plutôt que de compter uniquement les requêtes.
Peut-on dédupliquer uniquement avec le click ID ?
Ce n'est pas une règle universelle. Le circuit peut autoriser plusieurs événements ou actions pour un même clic. Confirmez la clé de conversion et la politique de mises à jour avant de choisir une contrainte.
Une réponse positive au deuxième envoi signifie-t-elle un doublon payé ?
Non. Le destinataire peut accuser réception sans produire de nouvel effet. Vérifiez le registre des conversions et les règles de rémunération ; le code HTTP seul ne tranche pas cette question.
Sources et références
- Stripe : doublons et ordre des événements webhook
Exemple documenté de notifications répétées et d'ordre non garanti. Les clés et transitions propres à une campagne Cash Nutra doivent être confirmées dans son contrat de mesure.