Organiser les reprises après un échec postback

Classer l'incident avant de choisir une relance

Un refus explicite pour paramètres invalides appelle d'abord une correction de configuration. Une indisponibilité temporaire peut justifier une reprise selon le contrat du destinataire. Une expiration de délai laisse une autre question ouverte : la requête a-t-elle été traitée avant que l'émetteur cesse d'attendre ? Ces catégories n'ont pas la même réponse opérationnelle. Dans le journal, séparez le résultat observé de l'interprétation provisoire et conservez la référence de l'événement concerné avec l'heure exacte de la tentative.

Ne remplacez pas cette analyse par un bouton Réessayer utilisé jusqu'à obtenir du vert. Une authentification refusée ne sera pas réparée par vingt requêtes identiques ; un traitement déjà effectué peut au contraire être répété. Le responsable du postback doit pouvoir expliquer pourquoi une nouvelle tentative est appropriée, ce qui a changé depuis la précédente et quelle preuve sera recherchée après l'envoi. Cette décision est particulièrement importante lorsque le destinataire transforme immédiatement la notification en revenu dans son tracker.

Conserver l'identité de l'événement pendant les tentatives

Attribuez une référence stable à l'événement logique et une référence distincte à chaque tentative de livraison. Dans un exemple fictif, conversion-C8 peut produire l'événement validation-E3, livré avec tentative-1 puis tentative-2. La deuxième tentative ne doit pas devenir conversion-C9. Vérifiez quelles valeurs le destinataire utilise pour reconnaître un doublon et dans quel périmètre : compte, source, campagne et type d'événement peuvent compter. Une clé isolée choisie sans son contexte peut écraser une autre action légitime.

Si le statut commercial évolue, il ne s'agit plus nécessairement d'une simple répétition. Une validation et une correction ultérieure doivent suivre le contrat d'événements prévu, tout en restant reliées à la conversion d'origine. N'ajoutez pas un suffixe aléatoire à l'identifiant pour forcer l'acceptation d'une requête rejetée comme doublon. Cela contournerait la protection recherchée et rendrait le rapprochement plus difficile. Faites préciser comment le tracker distingue une mise à jour légitime d'un deuxième envoi du même événement.

Définir une politique de reprise bornée et observable

Une politique exploitable fixe les catégories d'erreurs concernées, le délai entre tentatives, leur nombre maximal et la durée totale pendant laquelle une reprise reste pertinente. Des attentes progressives évitent de solliciter continuellement un service déjà en difficulté. Pour les réponses de limitation, consultez les indications et le contrat du fournisseur plutôt que d'imposer une cadence arbitraire. Aucune durée donnée dans ce guide n'est une promesse de comportement universel des services externes ou de votre infrastructure.

Documentez aussi ce qui se passe après épuisement du budget : mise en attente d'une intervention, alerte à un responsable et conservation de la dernière erreur utile. Une boucle qui se termine sans état visible transforme l'incident en perte silencieuse. Inversement, une boucle infinie peut aggraver la panne et multiplier les coûts. Le suivi doit permettre de distinguer les événements livrés, ceux dont l'acceptation reste incertaine et ceux pour lesquels aucune nouvelle tentative automatique n'est prévue.

Vérifier la reprise après interruption du processus

Une attente en mémoire et une file persistante ne fournissent pas la même garantie. Si le processus s'arrête pendant le délai, la prochaine tentative peut ne jamais avoir lieu sans mécanisme de reprise durable. Demandez où sont stockés l'événement, son état, la prochaine échéance et le nombre d'essais. Vérifiez ensuite quel worker reprend les tâches et comment deux workers évitent de livrer simultanément la même tentative. La présence d'un compteur dans l'interface ne répond pas à ces questions.

Lors d'un audit, séparez donc deux tests : succès après plusieurs refus dans une exécution continue, puis récupération après interruption et redémarrage. Le premier ne prouve pas le second. Pour Cash Nutra comme pour tout autre système, ne considérez pas qu'un paramètre de retry signifie automatiquement une livraison durable de bout en bout. Faites confirmer la capacité effectivement déployée et les limites de la source de campagne avant de fonder vos opérations sur cette hypothèse.

Préparer un scénario de recette qui ne pollue pas les revenus

Utilisez un destinataire de test contrôlé avec des événements synthétiques. Prévoyez plusieurs réponses : refus temporaire puis succès, refus permanent, réception suivie d'une réponse perdue et réception répétée du même identifiant. Pour chaque scénario, notez les tentatives observées et le nombre d'événements logiques effectivement enregistrés. L'objectif n'est pas de créer des ventes dans le vrai compte de l'affilié. Tout test sur un circuit live doit être autorisé et disposer d'un moyen vérifié d'isoler ses effets commerciaux.

Ajoutez un contrôle de sécurité : une nouvelle destination ne doit pas permettre d'appeler un service interne ou de suivre une redirection non autorisée. Ne déplacez pas le postback vers un collecteur public avec des paramètres clients ou une clé privée pour simplifier le débogage. Un environnement local peut valider les règles de reprise et de déduplication ; il ne prouve pas que le véritable tracker acceptera la configuration. La dernière preuve doit venir du destinataire autorisé, dans un scénario convenu.

Rejouer un lot avec un périmètre et un compte rendu

Après correction, établissez la liste exacte des événements concernés, la raison de leur reprise et le destinataire attendu. Excluez ceux déjà rapprochés et vérifiez les résultats ambigus avant d'inclure une ligne. Procédez sur un petit sous-ensemble autorisé, contrôlez les effets puis étendez le traitement si les observations sont conformes. Un renvoi de tout l'historique pour rattraper quelques échecs augmente le risque de doublons et complique l'attribution des nouvelles anomalies à leur véritable cause.

Le compte rendu doit donner les quantités tentées, confirmées, encore incertaines et abandonnées, sans les confondre avec des ventes supplémentaires. Conservez le lien vers l'incident et l'opérateur responsable. Pour vos campagnes Cash Nutra, faites valider ce protocole avec votre manager et l'équipe qui contrôle le tracker avant une reprise manuelle. Le travail est clos quand les événements attendus sont retrouvés une seule fois avec le bon statut, ou quand les exceptions restantes sont explicitement suivies.

Avant de vous lancer

• Distinguer refus certain, indisponibilité et acceptation inconnue.
• Préserver la référence logique pendant toutes les tentatives.
• Fixer un budget de reprise et un responsable après épuisement.
• Tester séparément les essais continus et le redémarrage après interruption.
• Rapprocher les résultats avant tout renvoi manuel d'un lot.

Questions fréquentes