Postback

La mécanique est simple. Quand un affilié envoie un clic, sa plateforme génère un click ID unique et le transmet dans le lien de tracking. L'opérateur stocke cet ID en face du joueur qui s'inscrit. Quand le joueur convertit, le serveur de l'opérateur appelle une URL configurée à l'avance par l'affilié, l'URL de postback, en y ajoutant en paramètres le click ID stocké et les détails de l'événement : type d'événement, parfois montant du dépôt, parfois devise. La plateforme de l'affilié reçoit l'appel, retrouve le click ID, et crédite la conversion à la bonne campagne, la bonne page et la bonne source.

Les postbacks se déclenchent en général sur une chaîne d'événements, pas un seul. Une configuration courante remonte l'inscription, le FTD et les dépôts suivants comme des postbacks distincts. Un affilié en deal CPA s'intéresse surtout au postback de FTD, puisque c'est l'événement payant. Un affilié en RevShare veut le flux complet des dépôts, parce que c'est la seule façon de rapprocher le NGR déclaré de l'activité joueur observable au lieu de prendre un relevé mensuel sur parole.

Parce que l'appel voyage de serveur à serveur, il ne dépend pas du navigateur du joueur. Aucun cookie n'a besoin de survivre, aucun pixel n'a besoin de se charger, aucun bloqueur de pub ne peut l'intercepter. C'est pourquoi les postbacks sont le standard en iGaming, où l'écart entre clic et dépôt peut s'étaler sur plusieurs jours et plusieurs appareils. Les modes de défaillance sont opérationnels : une URL mal configurée, un mapping de paramètre manquant, ou un opérateur qui cesse silencieusement de déclencher sur certains événements. Tester les postbacks avant de monter le trafic sur un nouveau deal n'est pas optionnel.