Tracking par postback (S2S) pour les affiliés iGaming

Un postback est une requête HTTP que le serveur d'un opérateur ou d'un programme d'affiliation envoie à votre tracker quand un joueur que vous avez apporté convertit, par exemple par une inscription ou un premier dépôt. Comme ce postback server-to-server (S2S) transporte le click ID, le tracker peut attribuer la conversion au bon clic, à la bonne source de trafic et à la bonne campagne, sans passer par aucun navigateur.

Pour un media buyer, ces données transforment un rapport de dépenses en rapport de rentabilité : elles montrent quelles sources amènent des déposants, et pas seulement des clics.

Qu'est-ce qu'un postback ?

En affiliation, le postback est une méthode de tracking des conversions : une notification envoyée d'un serveur à un autre quand un événement suivi se produit. C'est le système qui enregistre la conversion, généralement le logiciel d'affiliation de l'opérateur ou un réseau d'affiliation, qui lance l'appel. Votre tracker d'affiliation le reçoit et inscrit la conversion sur le clic d'origine.

Vous le verrez aussi appelé tracking server-to-server, server postback ou callback ; quant à postback ou callback, les plateformes d'affiliation emploient indifféremment les deux termes. L'URL de postback est l'adresse de votre tracker que le programme appelle.

Une précision pour les développeurs : en ASP.NET Web Forms, un postback désigne une page qui renvoie son formulaire à son propre serveur, ce qui n'a rien à voir avec le tracking des conversions.

Comment fonctionne le tracking par postback, étape par étape

Le tracking par postback envoie un click ID avec chaque visiteur et le récupère dans une requête serveur quand ce visiteur convertit, ce qui permet au tracker de rattacher la conversion au clic. Voici un clic du début à la fin, avec des ID et des domaines fictifs.

1. Le clic. Un utilisateur touche votre annonce et arrive sur votre URL de tracking, un lien traçable qui pointe d'abord vers votre tracker, par exemple https://trk.example.com/c/41. Le tracker enregistre la source, la campagne, la créa, l'appareil et l'heure, et attribue au clic un ID unique, disons 7f3a9c21.

2. Le passage de relais. Le tracker redirige l'utilisateur vers le lien d'offre du programme et ajoute le click ID dans le paramètre que le programme réserve à cet usage, souvent appelé sub ID : https://go.example-casino.com/o/12?sub1=7f3a9c21.

3. L'inscription. Le programme enregistre le click ID sur le compte du nouveau joueur. Une fois l'inscription terminée, son serveur envoie une requête de postback à votre tracker avec cet ID et le nom de l'événement.

4. Le dépôt. Quelques jours plus tard, le joueur alimente son compte pour la première fois. Le programme envoie une deuxième requête pour le même click ID, cette fois avec un payout et un statut en attente.

5. La décision. Après la vérification du programme, une mise à jour de statut marque le dépôt comme approuvé ou rejeté.

6. La transmission. Votre tracker rattache chaque requête au clic 7f3a9c21, met à jour le revenu de cette campagne et peut transmettre le dépôt à la plateforme publicitaire pour que ses enchères s'optimisent sur les déposants.

Les délais varient selon l'événement. Une inscription arrive généralement en quelques minutes. Un premier dépôt peut arriver plusieurs jours après le clic, et l'approbation suit la période de rétention du programme, qui dure souvent quelques semaines. Considérez les derniers jours de tout rapport comme incomplets.

À quoi ressemble une URL de postback

Une URL de postback comporte deux parties : l'adresse de base sur votre tracker et une query string de paramètres. Les noms des paramètres sont propres à votre tracker. Chaque valeur est une macro, un espace réservé que le programme remplace par des données réelles au moment où la requête part.

Un modèle à titre d'exemple, tel qu'il est saisi dans le tableau de bord du programme :

https://trk.example.com/postback?clickid={clickid}&event={event}&payout={payout}&currency={currency}&txid={transaction_id}&status={status}

La même requête telle que votre tracker la reçoit après un premier dépôt :

https://trk.example.com/postback?clickid=7f3a9c21&event=ftd&payout=150.00&currency=USD&txid=88412&status=pending

Il s'agit généralement d'une simple requête HTTP GET, avec toutes les données du postback dans l'URL.

La syntaxe des macros n'est pas standardisée : une plateforme utilise des accolades, une autre des dièses, et les noms des paramètres varient selon le tracker. Copiez les deux depuis la documentation du programme et celle du tracker.

Quels événements sont envoyés en iGaming

En iGaming, les programmes remontent généralement les inscriptions, les premiers dépôts et leurs changements de statut, et un même joueur peut générer plusieurs conversions par postback, selon le programme et votre deal.

• Inscription. Le joueur ouvre un compte. Un signal précoce, et l'événement rémunéré dans les deals CPL.

• FTD (premier dépôt). L'événement sur lequel paient la plupart des deals CPA. Le champ payout peut contenir le montant du CPA, ou zéro dans un deal RevShare.

• FTD qualifié. Certains programmes envoient un événement distinct lorsque le dépôt atteint le baseline du deal, comme un dépôt minimum ou un volume de mises minimum.

• Dépôts récurrents. Envoyés par certains programmes ; utiles pour évaluer la valeur du joueur.

• Changements de statut. Un FTD en attente devient approuvé, ou rejeté après des contrôles de comptes en double, d'abus de bonus ou de source de trafic. Un chargeback peut l'annuler plus tard.

Les gains en RevShare sont généralement réglés dans des rapports mensuels plutôt que par postback, même si certaines plateformes envoient des mises à jour de revenu. CPA vs RevShare vs hybride explique comment chaque modèle rémunère.

Tous les programmes ne proposent pas de postbacks, et certaines plateformes n'activent par défaut que l'événement d'inscription : renseignez-vous avant de construire. Enchérir et couper des sources sur la base des FTD approuvés, et non des inscriptions, aligne vos décisions sur l'événement pour lequel vous êtes payé.

Postback ou tracking par pixel : pourquoi le S2S s'impose par défaut

Le S2S s'impose par défaut parce que la requête part du serveur du programme : les limites sur les cookies, les bloqueurs de publicité et les événements tardifs ne coûtent donc pas de conversions comme avec un pixel dans le navigateur.

Un pixel est un extrait de code qui se charge dans le navigateur du joueur, généralement sur une page de confirmation, et appelle votre tracker depuis celui-ci. Il ne fonctionne que si ce navigateur conserve encore le cookie du clic et laisse partir la requête.

Les navigateurs compliquent les deux. Safari bloque par défaut les cookies tiers depuis mars 2020. Depuis 2019, sa protection contre le pistage limite aussi à sept jours les cookies déposés par des scripts. Les bloqueurs de publicité peuvent stopper complètement les appels du pixel. Une requête serveur évite tout cela.

Les pixels restent utilisés quand un programme n'offre pas d'option serveur, ou sur les landing pages que vous contrôlez. L'attribution par cookie est aussi plus facile à détourner, comme le montre le cookie stuffing.

Les plateformes publicitaires appliquent la même logique côté serveur. La Conversions API de Meta reçoit des événements depuis votre serveur. En octobre 2026, la méthode de déduplication recommandée par Meta rapproche un événement pixel et un événement serveur ayant le même ID et le même nom d'événement, et ne les fusionne que si les deux arrivent dans un délai de 48 heures.

Comment configurer et tester un postback

La configuration consiste à faire correspondre les réglages du programme et ceux de votre tracker : le click ID part sur le lien d'offre, l'URL de votre tracker va dans le tableau de bord du programme, et une conversion de test prouve que les deux fonctionnent.

1. Rassemblez les informations. Auprès de l'affiliate manager ou dans la documentation du programme, obtenez le paramètre du click ID, les macros prises en charge, les événements et statuts disponibles, et si l'URL se définit par offre ou globalement.

2. Créez l'URL dans le tracker. La plupart des trackers génèrent un modèle pour les programmes qu'ils connaissent. Pour tout autre programme, associez à la main chaque paramètre du tracker à sa macro.

3. Transmettez le click ID. Ajoutez-le au lien d'offre dans votre campagne du tracker, dans le paramètre sub ID du programme.

4. Installez l'URL. Collez-la dans le tableau de bord du programme, avec une entrée par événement si nécessaire.

5. Mappez les statuts. En attente, approuvé et rejeté doivent arriver comme des états distincts.

6. Testez la réception. Ouvrez le lien de votre campagne dans une session de navigateur vierge, vérifiez que le click ID est bien arrivé au programme, puis effectuez une inscription de test ou demandez à l'affiliate manager de déclencher un postback de test.

7. Lisez le journal. Certaines plateformes journalisent chaque requête de postback avec le code de réponse de votre serveur. Un 200 signifie que votre tracker l'a acceptée ; un 4xx ou un 5xx désigne votre endpoint.

Servez l'endpoint du tracker en HTTPS, et refaites un test chaque fois que l'une ou l'autre partie modifie le format de ses liens.

Problèmes de postback courants et comment les résoudre

La plupart des problèmes de tracking viennent d'un click ID perdu à l'aller, d'une macro ou d'un paramètre erroné, ou de requêtes qui n'atteignent jamais le tracker. La résolution commence généralement par suivre un clic de bout en bout et comparer les journaux des deux côtés.

• Click ID perdu à l'aller. Un prelander ou une redirection supplémentaire supprime la query string. Suivez la chaîne étape par étape et cherchez l'ID dans le rapport de clics du programme.

• Macro ou nom de paramètre erroné. Certaines plateformes sont sensibles à la casse des noms de paramètres et ignorent toute autre graphie : le click ID revient alors vide. Copiez les noms et les macros à l'identique.

• URL cassée. Des valeurs non encodées, des espaces parasites ou un second ? à la place d'un & corrompent la requête.

• Mapping des statuts. Si les dépôts en attente comptent comme approuvés, le ROI paraît meilleur qu'il ne l'est jusqu'à l'arrivée des rejets.

• Doublons. Les nouvelles tentatives peuvent envoyer deux fois le même événement : basez donc la déduplication sur l'ID de transaction. Au moins un tracker très répandu ne compte qu'une fois chaque paire click ID et ID de transaction et, par défaut, écarte un click ID répété sans nouvel ID de transaction.

• Requêtes qui n'arrivent jamais. Une panne, un certificat expiré ou une règle de pare-feu peuvent bloquer les appels entrants. Comparez le journal des requêtes du programme avec celui de votre tracker.

• Totaux qui ne concordent pas avec le rapport de l'opérateur. Les approbations tardives, les FTD rejetés, la conversion de devises et les heures de clôture des rapports créent des écarts. Les rejets sont aussi le moyen par lequel les opérateurs filtrent la fraude ; voir la fraude à l'affiliation en iGaming.

Questions fréquentes

Qu'est-ce qu'une URL de postback ?

Une URL de postback est l'adresse de votre tracker qu'un programme d'affiliation appelle lorsqu'une conversion a lieu. Les macros du programme remplissent ses paramètres, comme le click ID, l'événement, le payout et le statut.

Que signifie « postback » en affiliation ?

En affiliation, un postback est une notification server-to-server indiquant qu'un joueur apporté a converti. L'opérateur ou le réseau indique à votre tracker quel clic a produit l'inscription ou le dépôt, et ce qu'il vous rapporte.

Qu'est-ce qu'une URL de tracking et en quoi diffère-t-elle d'une URL de postback ?

Une URL de tracking est le lien sur lequel clique votre trafic ; elle enregistre le clic et crée le click ID. Le programme appelle l'URL de postback plus tard, pour indiquer ce que ce clic a donné.

Postback ou pixel : lequel est le plus fiable ?

En règle générale, le tracking S2S est plus fiable qu'un pixel pour les programmes d'opérateurs. Il n'a besoin d'aucun cookie navigateur, les bloqueurs de publicité ne le voient pas et les approbations tardives arrivent quand même. Un pixel s'installe plus vite mais peut manquer des conversions dans les navigateurs qui limitent les cookies.

Comment vérifier qu'un postback fonctionne ?

Pour tester un postback, cliquez sur votre propre lien de campagne, vérifiez que le programme a reçu le click ID, puis déclenchez un postback de test. Le tracker doit enregistrer le bon événement et le bon payout, et tout journal de requêtes côté programme doit afficher une réponse 200.

Pourquoi mon tracker affiche-t-il moins de conversions que l'opérateur ?

Un tracker affiche généralement moins de conversions que l'opérateur à cause d'un click ID perdu dans une redirection, d'une macro erronée ou d'un événement que le programme n'envoie pas. Plus de conversions dans le tracker que dans le rapport de l'opérateur signifie généralement des FTD en attente rejetés par la suite.

Sources

• Everflow Helpdesk, "Understanding tracking with server-to-server postbacks"

• Everflow Helpdesk, "How to test partner postbacks"

• Voluum Documentation, "Parameters in Postback URLs"

• Voluum Documentation, "Upselling: Tracking subsequent conversions"

• Voluum, "How to Track First-Time Deposits (FTDs) with Voluum Using Postbacks", April 2025

• Offer18 Knowledge Base, "iGaming - Postback"

• Referly Help Center, "Postback URL"

• WebKit, "Full Third-Party Cookie Blocking and More", March 24, 2020

• Meta for Developers, "Handling Duplicate Pixel and Conversions API Events"

• Microsoft Learn, "Page.IsPostBack Property"