Postbacks, pixels et tags image : un seul permet d'être payé
Trois mécanismes pour remonter une conversion, décrits pour qu'un non-ingénieur puisse les tenir, plus les six façons dont les intégrations cassent vraiment. Écrit pour les opérateurs et les affiliate managers techniques qui ont déjà débogué ça à onze heures du soir.
Une conversion peut être remontée de trois façons : un tag image, un pixel JavaScript, ou un postback serveur à serveur. Seul le postback tient assez bien pour qu'on paie une commission dessus, parce qu'il n'a pas besoin de la coopération du navigateur du joueur. La plupart des intégrations qui « ne trackent pas » ne sont pas des postbacks cassés : ce sont des identifiants de clic absents de la fiche joueur.
L'appel tombe toujours à une mauvaise heure. Un affiliate manager a un partenaire qui menace de couper son trafic, l'opérateur jure que l'intégration est en ligne, et le tableau de bord affiche zéro. Quelqu'un envoie la capture d'un tag dans le pied de page de la page de confirmation de dépôt et demande pourquoi ça ne marche pas.
Ça ne marche pas parce que c'est un tag dans le pied de page d'une page.
Remonter une conversion est un petit problème avec beaucoup de façons de se tromper, et ces façons n'ont pas beaucoup changé en dix ans. Ce qui a changé, c'est que deux des trois mécanismes ont discrètement cessé d'être fiables pendant que tout le monde continuait à les livrer. Ce texte est celui à donner à votre ingénieur avant l'intégration, pas après.
Trois façons de dire qu'un joueur a déposé
Le tag image. Le plus ancien. Votre page inclut une image d'un pixel dont la source est une URL appartenant à la plateforme de tracking. Le navigateur tente de charger l'image, cette requête atteint la plateforme, et la requête elle-même est le message. Aucune image n'est vraiment nécessaire, c'est la récupération qui compte. Il ne demande que du HTML, ce qui explique sa survie si longue dans des systèmes de templates où personne ne voulait toucher au JavaScript.
Le pixel JavaScript. La même idée avec un script au lieu d'une image. Un snippet s'exécute dans la page, collecte un peu de contexte et envoie l'appel. C'est plus souple : il peut lire une valeur que la page a mise dans une variable, il peut attendre l'affichage d'une confirmation, il peut transmettre un montant de dépôt connu seulement à l'exécution. C'est aussi plus fragile, parce que cela dépend du chargement du script, de l'existence de la variable, et du fait que la page n'ait pas planté plus haut.
Le postback serveur à serveur. Aucun navigateur. Quand votre backend enregistre l'événement qui compte, il émet une requête HTTP vers une URL, en portant l'identifiant qui lui a été remis à l'arrivée du joueur. Votre service de paiement confirme un dépôt, votre système écrit la transaction, et quelque part sur ce même chemin une requête part en disant : ce joueur, cet événement, ce montant, cette devise.
C'est toute l'idée. Cela paraît moins malin que les deux autres, et c'est précisément la raison pour laquelle ça tient.
Pourquoi deux des trois ont cessé d'être fiables
Il n'y a pas une cause unique. Il y en a une pile, et chacune prise seule serait supportable.
Safari et Firefox bloquent les cookies tiers par défaut, et Firefox bloque en plus les requêtes vers les domaines de sa liste de traqueurs. Chrome autorise encore les cookies tiers : sur Chrome, le blocage vient donc du bloqueur de publicité plutôt que du navigateur. Safari plafonne en outre la durée de survie du stockage écrit par script, parfois à quelques jours, ce qui veut dire que tout ce qui repose sur un état écrit au clic et lu au dépôt a une péremption mesurée en une fraction d'une fenêtre de réflexion normale. Les bloqueurs de publicité se posent par-dessus tout cela et sont courants précisément dans les audiences qui lisent du contenu comparatif avant de s'inscrire. Rien de tout cela ne s'annonce. Votre opérateur voit la page s'afficher correctement et en conclut que l'intégration fonctionne.
Et puis il y a la partie qu'aucun réglage de navigateur ne corrige. Un joueur clique depuis un ordinateur au bureau, y réfléchit, et dépose le soir depuis son téléphone. Ou il s'inscrit sur le web et dépose dans l'application native, où il n'y a ni navigateur, ni page, ni tag à déclencher. En paris sportifs surtout, le dépôt suit le calendrier des matchs plutôt que le clic, et il le suit jusque dans l'application. Si vous voulez voir à quel point ces deux parcours diffèrent, le trafic casino et le trafic paris sportifs divergent exactement sur ce point.
Un pixel ne peut pas se déclencher depuis un endroit où le navigateur n'est jamais allé. Rien là-dedans ne se répare avec un meilleur placement de tag.
| Ce qui vous importe | Tag image | Pixel JavaScript | Postback serveur à serveur |
|---|---|---|---|
| Se déclenche depuis | Le navigateur du joueur | Le navigateur du joueur | Votre propre backend |
| Résiste aux bloqueurs de publicité | Rarement | Rarement | Oui, il n'est pas concerné |
| Résiste au multi-appareil | Non | Non | Oui |
| Résiste à un dépôt dans l'application | Non | Non | Oui |
| Peut lire l'état de la page à l'exécution | Non | Oui | Sans objet |
| Remonte un montant réglé | Seulement ce que la page connaît | Seulement ce que la page connaît | Oui, depuis le système de référence |
| Quand l'utiliser | Systèmes hérités que vous ne pouvez pas changer | Un signal en session, en secondaire | Tout ce qui décide de l'argent |
Les pannes qui valent la peine d'être connues
Personne ne casse une intégration de façon intéressante. Les six mêmes erreurs expliquent presque tout.
Déclencher au chargement de la page plutôt que sur l'événement. Le tag vit sur la page de confirmation de dépôt, donc il se déclenche à chaque ouverture de cette page. Un joueur rafraîchit, revient par l'historique, ou y atterrit après une tentative ratée, et chacune de ces fois devient une conversion dans vos rapports. Cela gonfle les chiffres dans le sens qui fait plaisir, ce qui explique la longue survie de l'erreur avant que quiconque la questionne.
Est-ce vraiment côté serveur ? Un framework backend qui rend un template émet quand même un tag que le navigateur doit exécuter. Si la requête part de l'appareil du joueur, c'est côté navigateur, quel que soit le fichier où c'était écrit. Le test prend une minute : bloquez les scripts dans votre propre navigateur et voyez si l'événement arrive toujours.
Ensuite vient l'identifiant de clic, absent de la fiche joueur. C'est de très loin la panne la plus fréquente et elle a droit à sa propre section plus bas.
Le dépôt est remonté avant d'être réglé. Le paiement est autorisé, le postback part, puis le paiement échoue ou est annulé. Il y a maintenant une commission attachée à de l'argent qui n'est jamais arrivé. Déclenchez sur l'état que votre équipe finance reconnaîtrait, pas sur celui qu'affiche votre page de paiement.
L'idempotence, ou son absence. Les réseaux expirent. Un émetteur bien construit réessaie, et c'est correct. Si le côté récepteur ne peut pas savoir que la deuxième tentative est le même événement que la première, la reprise devient une deuxième conversion. Chaque événement a besoin d'une référence unique stable de votre côté, la même valeur à chaque tentative, pour qu'un doublon soit reconnu et écarté plutôt que payé deux fois.
Les événements arrivent aussi dans le désordre. Un dépôt atterrit avant l'inscription à laquelle il appartient, parce que deux services ont émis indépendamment et que l'un était plus rapide. Ordonnez les événements qui dépendent les uns des autres, ou faites porter à chacun assez de contexte pour tenir seul.
La seule chose qui décide de tout
Chaque panne ci-dessus se répare en un après-midi. Pas celle-ci.
Quand un joueur arrive par un lien de tracking, l'identifiant présent sur ce lien doit être enregistré sur la fiche joueur à l'inscription. Pas dans une session. Pas dans un cookie. Sur la ligne de votre base de données qui représente ce compte, à côté de l'adresse e-mail, dans la même transaction que celle qui la crée.
Si cela n'a pas lieu, rien en aval ne peut être attribué. Le joueur dépose trois semaines plus tard, votre backend émet un postback techniquement parfait, et il ne porte aucun identifiant, parce qu'il n'y a rien à porter. Aucun réglage de postback ne corrige cela. Vous ne déboguez pas un problème de reporting, vous déboguez un problème d'inscription, et le correctif est dans le parcours d'inscription.
Deux habitudes voisines évitent beaucoup de disputes. Conservez l'identifiant même quand la valeur paraît étrange, parce que vous stockez un jeton, vous ne le validez pas. Et conservez-le pour toute la durée de vie du compte plutôt que trente jours, parce qu'un CPA qui paie sur un dépôt qualifiant a besoin que le lien existe encore au moment où le dépôt qualifie, ce qui peut arriver des mois après le clic. Si le vocabulaire autour des dépôts qualifiants et des premiers dépôts est flou chez vous, le glossaire FTD, NGR, CPA, CPL et CPR mérite dix minutes avant d'écrire le schéma.
Le tester avant de faire tourner du trafic
Un test d'intégration correct est ennuyeux et prend environ une heure.
- Cliquez sur un vrai lien de tracking et complétez l'inscription comme le ferait un joueur normal. Puis regardez la fiche joueur dans votre propre base et confirmez que l'identifiant y est. S'il n'y est pas, arrêtez, parce que tout ce qui suit relève du théâtre.
- Déposez de l'argent réel. Un petit montant suffit, 20 EUR feront l'affaire. Les paiements en mode test contournent fréquemment le chemin de code exact qui déclenche l'événement, et c'est ainsi que des intégrations passent en préproduction et échouent au premier jour.
- Vérifiez que l'événement de dépôt est arrivé une fois, avec le bon montant et la bonne devise, après le règlement du paiement et non à sa soumission.
- Renvoyez le même événement volontairement. Il doit être reconnu comme doublon et ne pas être compté deux fois.
- Refaites tout depuis un téléphone, et une fois de plus avec le dépôt effectué dans l'application plutôt que dans le navigateur si vous en avez une.
Une heure d'ingénieur et un dépôt, contre un mois de rapprochement avec un affilié déjà convaincu que vous rognez son trafic. Le guide de recette d'un lien de tracking couvre le côté affilié du même test, et faire tourner les deux bouts ensemble est la façon de trouver le décalage en un après-midi plutôt qu'en un trimestre.
Ce qu'AFFILIFY attend d'un opérateur
La référence d'intégration se trouve sur affilify.partners/docs, avec l'endpoint, les noms de paramètres et les types d'événements acceptés. Lisez-la là plutôt que dans un article de blog, parce que c'est cette page que nous maintenons à jour.
La forme est simple. Un nom d'événement, l'identifiant qui vous a été remis au clic, un montant et une devise, plus votre clé. Inscription, premier dépôt, dépôts suivants et événements de revenu sont des messages distincts, parce que le modèle de commission attaché à un deal décide lesquels comptent, et qu'un programme ne peut pas payer du RevShare sur des données qu'il n'a jamais reçues. Si vous hésitez encore entre les modèles, CPA, RevShare et hybride expose ce que chacun exige de votre côté.
Deux choses à dire franchement. L'attribution de notre côté dispose de replis en couches. Ce sont des assurances, pas un plan. L'identifiant enregistré à l'inscription est la partie que vous contrôlez : envoyez-le. Et la qualité du trafic est évaluée en continu, ce qui veut dire que certaines conversions sont retenues le temps d'être vérifiées plutôt que créditées à l'arrivée. Ce n'est pas un refus, et l'affilié voit l'état plutôt qu'un trou silencieux.
Un opérateur qui renvoie l'identifiant, remonte les événements réglés une seule fois, et se laisse tester avec un vrai dépôt en une heure n'aura jamais la conversation de onze heures du soir. C'est toute l'ambition ici.
Questions fréquentes
Quelle est la différence entre un postback et un pixel ?
Un pixel est déclenché par le navigateur du joueur pendant qu'une page est ouverte. Un postback est déclenché par votre propre backend quand l'événement est enregistré, sans aucun navigateur. Cette seule différence décide de tout le reste : le postback n'est affecté ni par les bloqueurs de publicité ni par la politique de cookies du navigateur, il fonctionne encore quand le joueur s'inscrit sur un portable et dépose depuis un téléphone, et il fonctionne quand le dépôt a lieu dans une application native où aucune page ne se charge jamais. Il remonte aussi le montant que détient votre système de référence, pas celui qu'une page connaissait par hasard.
Peut-on garder un pixel en secours à côté du postback ?
Vous pouvez, mais soyez clair sur sa valeur. Un pixel ne confirmera jamais que les événements qu'il peut voir, c'est-à-dire un sous-ensemble de ceux qui ont réellement eu lieu, et la taille de ce sous-ensemble vous est invisible. Traitez-le comme une vérification de bon sens en session pendant le développement plutôt que comme une seconde source de vérité, et ne rapprochez jamais des paiements dessus. Si les deux se déclenchent pour le même événement, votre plateforme a besoin d'une référence unique stable de votre côté pour que la paire soit reconnue comme une conversion et non deux.
Nos postbacks partent mais rien n'est attribué. Pourquoi ?
Presque toujours parce que l'identifiant de clic n'a jamais été enregistré sur la fiche joueur à l'inscription. Le postback part correctement, à l'heure, avec une clé valide, et ne porte rien sur quoi faire correspondre. Regardez d'abord une vraie ligne joueur dans votre base. Si l'identifiant y manque, le bug est dans votre parcours d'inscription, pas dans le code du postback, et aucune logique de reprise ni aucun réglage d'endpoint n'y changera quoi que ce soit.
Comment tester une intégration postback avant de faire tourner du trafic ?
Cliquez sur un vrai lien de tracking, inscrivez-vous comme joueur, et confirmez que l'identifiant a bien atterri sur la ligne du compte. Déposez ensuite de l'argent réel, parce que les paiements en mode test contournent souvent le chemin de code exact qui déclenche l'événement. Vérifiez que le dépôt est arrivé une fois, avec le bon montant et la bonne devise, après le règlement du paiement. Renvoyez le même événement exprès et vérifiez qu'il est écarté comme doublon. Puis recommencez sur un téléphone, et dans l'application si vous en avez une. Une heure, et un petit dépôt.
