Pourquoi un postback HTTP 200 ne prouve pas l’attribution

Séparer les quatre preuves d'un retour de conversion

La première preuve est l'émission : le réseau a préparé une notification pour un événement précis. La deuxième est le transport : un serveur a répondu à la requête. La troisième est le traitement : l'application destinataire a accepté ou classé l'événement. La quatrième est le rapprochement métier : la conversion figure sur le bon clic et dans le bon programme, avec le statut attendu. Ces preuves peuvent arriver à des moments différents et être conservées dans des outils distincts.

Un journal qui ne montre que l'heure et le code HTTP couvre principalement le transport. Il ne permet pas de savoir si le tracker a retrouvé le clic ou ignoré un doublon. Demandez donc quel enregistrement doit apparaître après réception, où le consulter et quel délai de traitement est prévu. Cette définition préalable évite que le réseau et l'affilié utilisent le mot reçu pour désigner deux étapes différentes.

Comprendre comment un résultat vert peut rester incomplet

Un serveur peut accepter une requête avant qu'un traitement différé ne produise le résultat final. Un destinataire peut aussi reconnaître une notification déjà traitée et ne rien ajouter. Ces comportements doivent être interprétés avec son contrat d'API, pas avec la couleur de l'interface. Vérifiez également l'adresse appelée : une réponse issue d'une page générique ou d'un intermédiaire n'est pas nécessairement un accusé applicatif du point d'entrée de conversion attendu.

Prenons un cas fictif : le réseau transmet l'événement test-008 avec un identifiant externe absent du tracker. La requête peut être correctement reçue, mais le destinataire ne peut pas l'associer au clic visé. Ajouter manuellement une ligne de revenu ne réparerait pas l'identifiant manquant. Il faut retrouver pourquoi la valeur n'a pas été enregistrée à l'aller ou pourquoi un autre champ est utilisé au retour, puis rejouer le scénario dans un cadre de test convenu.

Préparer une fiche de rapprochement événement par événement

Pour une vérification ciblée, réunissez l'identifiant d'événement, l'identifiant du clic réseau, l'identifiant externe attendu, la campagne, le partenaire, les heures d'émission et de réception, le statut et le résultat côté tracker. Ajoutez le montant et la devise seulement lorsque le contrat prévoit leur transmission. Un horodatage doit comporter son fuseau. Une clé de signature ou un secret de postback ne doit jamais figurer dans cette fiche partagée.

Comparez les identifiants comme des valeurs exactes plutôt que comme des nombres à reformater. Des zéros initiaux, une casse différente ou un caractère décodé peuvent suffire à rompre la correspondance. Si un champ a été renommé entre deux outils, notez le mapping explicitement. Le but n'est pas de rendre tous les écrans identiques, mais de démontrer quelle valeur représente le même événement dans chaque système et quelle transformation a été appliquée.

Vérifier le statut avant d'interpréter le montant

Une conversion en attente, une conversion acceptée et une conversion rejetée ne portent pas la même signification commerciale. Le destinataire peut recevoir une étape provisoire puis une mise à jour. Déterminez si le réseau notifie chaque transition ou seulement certains événements. Un montant observé à l'étape initiale ne doit pas devenir automatiquement un revenu définitivement acquis dans votre analyse. Le CPA applicable relève des conditions du programme et de son événement de validation.

Utilisez un exemple fictif pour vérifier les calculs : une campagne annoncée à 80 USD doit être rapprochée d'un retour dont la devise est connue et dont la définition du montant est précisée. Ne comparez pas directement une valeur en EUR, un prix client ou un revenu brut annonceur au CPA affilié. La fiche doit indiquer ce que chaque nombre mesure. Cette précaution évite de diagnostiquer un incident de transport alors que le désaccord porte en réalité sur la donnée commerciale attendue.

Tester la réception sans transformer un essai en vente

Convenez d'un environnement, d'un destinataire et d'un identifiant synthétique pour le test. Définissez à l'avance comment cet événement sera exclu des résultats commerciaux et qui vérifiera la réception. Une requête reçue dans un collecteur technique peut valider le format et le transport, mais elle ne prouve pas le traitement dans le véritable tracker. N'envoyez pas de données clients vers un outil de collecte tiers pour obtenir une capture plus commode.

Le compte rendu doit préciser le périmètre : format accepté, réponse HTTP obtenue, événement retrouvé, clic rapproché et statut conforme. Cochez uniquement les étapes réellement observées. Si le destinataire externe reste inaccessible, le résultat est un test partiel, pas un échec automatiquement imputable au réseau ni une intégration terminée. La preuve manquante devient alors une action assignée à l'opérateur qui contrôle ce destinataire.

Clore l'incident avec un résultat vérifiable des deux côtés

Quand le réseau voit un 200 et que l'affilié ne voit aucune conversion, commencez par demander la recherche d'un événement précis dans le tracker. Vérifiez ensuite filtre de dates, fuseau, campagne, statut et éventuel classement en doublon ou en événement non rapproché. Une recherche ciblée est plus utile qu'une nouvelle série d'envois identiques. Les reprises non coordonnées peuvent compliquer l'enquête et augmenter le risque de comptabilisation multiple.

Pour préparer votre activité Cash Nutra, indiquez votre tracker et le type de retour attendu lors de la configuration du postback. Faites confirmer les événements disponibles pour vos campagnes et gardez une preuve de réception autorisée avant de vous appuyer sur les données pour piloter un budget. Le bon résultat n'est pas seulement « envoyé avec succès » : c'est un événement identifié, retrouvé au bon endroit et interprété selon les mêmes règles par les deux équipes.

Avant de vous lancer

• Séparer émission, transport, traitement et rapprochement métier.
• Rechercher un événement précis dans les deux systèmes.
• Comparer identifiants, statut, montant, devise et fuseaux horaires.
• Vérifier si le destinataire a classé la notification comme doublon.
• Décrire les limites du test et exclure les événements synthétiques des revenus.

Questions fréquentes