Comment suivre les conversions d'affiliation : 3 méthodes

Suivre les conversions d'affiliation, c'est répondre à une question précise : quel affilié a amené le client qui vient de payer ? Une erreur sur ce point, et vous payez une commission au mauvais affilié — ou vous ne payez rien du tout, et l'affilié qui vous a envoyé un client ne peut pas le prouver.

Les lacunes de tracking sont silencieuses : pas d'erreur, pas d'alerte, juste une attribution qui ne s'est jamais formée. Auditez-les séparément de la fraude afin d'associer chaque risque à un signal observable.

Ce guide couvre les trois méthodes pour suivre les conversions d'affiliation, comment choisir entre elles, et comment implémenter chacune avec du code concret. Si vous voulez comprendre pourquoi le tracking se casse, lisez d'abord l'article de diagnostic sur les pannes de suivi d'affiliation. Cet article reprend là où celui-ci s'arrête : à l'implémentation.

Si votre question immédiate concerne Stripe, combinez cet article avec le guide de suivi d'affiliation Stripe et la page logiciel d'affiliation Stripe. Ces pages détaillent les metadata Checkout et les chemins webhook dans un contexte SaaS plus précis.

---

Les trois méthodes pour suivre les conversions d'affiliation

Méthode 1 : le cookie first-party

Un prospect clique sur un lien d'affilié. Votre serveur lit le code d'affilié dans le paramètre de l'URL et écrit un cookie first-party — émis par votre propre domaine, pas par le domaine d'une plateforme tierce — dans le navigateur. Ce cookie persiste jusqu'à son expiration ou jusqu'à ce que l'utilisateur nettoie ses données.

Au moment de la conversion, votre gestionnaire d'inscription ou de paiement lit le cookie, récupère l'identifiant de l'affilié, et le stocke dans l'enregistrement utilisateur.

C'est la méthode de base. Elle fonctionne de manière fiable quand l'acheteur utilise le même navigateur sur le même appareil du clic jusqu'à l'achat. Elle se casse sous Safari ITP, avec les bloqueurs de publicités, et lors des parcours multi-appareils.

Méthode 2 : le postback serveur-à-serveur (S2S)

Au lieu de s'appuyer sur le navigateur, le serveur du marchand envoie un POST HTTP directement vers l'endpoint de la plateforme d'affiliation quand un événement de conversion se déclenche. Aucun navigateur n'est impliqué. Le signal de conversion circule de serveur à serveur.

Le postback S2S est le standard dans les réseaux de performance marketing. Il exige que le lien de tracking de l'affilié insère un identifiant de clic unique — clickid ou équivalent — dans l'URL de destination, que votre serveur capture et stocke cet identifiant à l'atterrissage, et que votre logique de confirmation puisse retrouver l'identifiant de clic au moment de la conversion pour construire l'URL de postback.

Le S2S évite les bloqueurs côté navigateur pour le signal de conversion parce qu'aucun JavaScript ne s'exécute côté navigateur au moment de convertir. Sa faiblesse est la complexité de configuration et l'obligation que les identifiants de clic persistent côté serveur tout au long du tunnel.

Méthode 3 : les métadonnées du processeur de paiement (natif Stripe)

La méthode la plus robuste pour les SaaS sur Stripe consiste à porter l'identifiant de session de l'affilié directement dans l'objet de paiement Stripe en tant que métadonnées, puis à traiter les conversions depuis les événements webhook.

Quand un prospect atterrit sur votre site via un lien d'affilié, un cookie stocke l'identifiant de session. Quand cette session atteint le paiement, votre backend lit l'identifiant depuis le cookie et l'attache à l'objet Stripe — PaymentIntent, Checkout Session ou Subscription — en métadonnées. Stripe déclenche un webhook à la confirmation du paiement. Votre backend lit les métadonnées dans le payload du webhook et crée la commission. L'état du navigateur au moment du paiement n'a plus d'importance.

C'est le tracking server-side : l'attribution vit dans l'infrastructure Stripe, pas dans un cookie.

---

Tableau comparatif

Méthode	Fiabilité	Résistance à Safari ITP et aux bloqueurs	Complexité d'implémentation
Cookie first-party	Moyenne — tombe sur Safari, bloqueurs, cross-device	Non	Faible
Postback serveur-à-serveur	Élevée — pas de dépendance navigateur à la conversion	Oui	Moyenne
Métadonnées Stripe (server-side)	Élevée — l'attribution vit dans Stripe	Oui	Faible à moyenne (avec un SDK)

En pratique, la configuration la plus résiliente associe une session navigateur consentie à un signal de conversion côté serveur : après consentement, le SDK capture la recommandation dans un cookie first-party, puis le checkout écrit cet identifiant de session dans les métadonnées Stripe. Sans session navigateur, une information connue indépendamment, comme un coupon ou un code affilié côté serveur, peut fournir un autre chemin.

---

Attribution : fenêtre, modèle et secours cross-device

La fenêtre d'attribution

La fenêtre d'attribution est la période durant laquelle un clic peut générer une commission. Un clic au jour 1 dans une fenêtre de 90 jours peut créditer une conversion au jour 88. Un clic au jour 1 dans une fenêtre de 30 jours ne peut pas créditer une conversion au jour 35.

La fenêtre doit correspondre à votre cycle de vente, pas à une valeur par défaut de plateforme. Construisez la distribution réelle du délai entre premier clic et paiement, puis choisissez la fenêtre qui couvre les parcours que votre politique veut créditer.

RefCampaign utilise une fenêtre d'attribution de 90 jours. Lorsque le visiteur accepte l'attribution sur une page contenant ?ref=..., le SDK navigateur crée le cookie first-party _rc_sid avec une expiration de 90 jours. Un refus ne crée aucune session.

Le modèle d'attribution

Le modèle par défaut est le dernier clic : le dernier lien d'affilié cliqué avant la conversion reçoit 100 % de la commission. Le dernier clic est simple à implémenter, facile à auditer, et aligne la commission sur l'événement de conversion. C'est le bon défaut pour la plupart des programmes SaaS.

Le dernier clic a une faiblesse connue : il récompense les affiliés qui interceptent en bas du tunnel — sites de coupons, plateformes de cashback — au détriment de ceux qui ont introduit le produit. Si votre mix d'affiliés inclut une part significative de créateurs de contenu travaillant en haut du tunnel, évaluez si les incitations du dernier clic correspondent au trafic que vous voulez attirer.

Le secours cross-device via email haché

L'attribution cross-device adresse le scénario où un utilisateur clique sur un lien d'affilié depuis un appareil et complète son inscription ou son achat depuis un autre. Le cookie écrit sur l'appareil A n'existe pas sur l'appareil B.

La solution consiste à relier l'enregistrement du clic à un signal d'identité indépendant de l'appareil. L'email est l'option la plus pratique. Après la connexion ou l'inscription, quand l'email de l'utilisateur est connu, votre couche de tracking hache l'email côté client et l'attache à l'enregistrement de clic d'origine. Si une conversion arrive sur un second appareil sans cookie _rc_sid, le système peut retrouver les enregistrements de clics précédents associés à ce hash d'email.

Ce mécanisme de secours couvre le pattern B2B où les prospects recherchent sur des appareils personnels et achètent sur des postes professionnels. Mesurez son apport en comparant l'attribution liée au compte avec les clics visibles uniquement dans le navigateur.

---

Les signaux anti-fraude

La lutte anti-fraude dans le tracking d'affiliation est un problème de détection, pas de blocage. Le blocage automatique crée des faux positifs — des affiliés légitimes qui génèrent du vrai trafic depuis des patterns inhabituels se retrouvent exclus, et vous ne savez jamais que vous avez perdu la conversion.

La bonne posture est de signaler les comportements suspects et de les soumettre à une revue humaine. Le marchand décide.

Signal	Ce qu'il indique
Clics répétés depuis la même IP à quelques secondes d'intervalle	Bot ou inflation de clics
Une IP générant des dizaines de clics sur une courte fenêtre	Trafic automatisé
Intervalle clic-conversion inférieur à 5 minutes	Bot complétant le tunnel d'inscription
Taux de conversion très au-dessus de la moyenne du programme pour un seul affilié	Auto-parrainage probable ou trafic acheté
Intervalles de clics réguliers et quasi identiques	Génération de clics scriptée

Signalement, pas blocage. Chaque conversion signalée reste dans la file. Le marchand revoit et approuve ou rejette.

---

Implémenter le suivi de conversions avec RefCampaign

Cette section détaille les quatre étapes d'implémentation. Le code cible le flux navigateur avec consentement du SDK RefCampaign v4.

Étape 1 : charger le script de tracking

Placez le script v4 passif dans le <head> de votre site marketing et de votre application, avec le jeton public affiché dans le tableau de bord RefCampaign. Son chargement ne crée aucune session et n'envoie aucune requête de capture.

<script src="https://sdk.refcampaign.com/v4.js?s=rcst_JETON_PUBLIC_DU_SITE" async></script>

Reliez votre plateforme de gestion du consentement au SDK et rejouez le choix conservé après chaque chargement de page :

function appliquerConsentementAttribution(accepte) {
  return window.RefCampaignBrowser.setConsent({ attribution: accepte })
}

Le lien affilié redirige vers le site marchand avec un alias public comme ?ref=fabrice ; la redirection ne pose aucun cookie et n'enregistre aucun clic. Après un accord, le SDK échange cet alias contre une session et écrit _rc_sid sur l'hôte marchand. Un refus initial ne crée aucune session et un retrait ultérieur appelle la branche false pour supprimer l'état d'attribution courant.

Étape 2 : transmettre la session à Stripe au paiement

Lisez le cookie _rc_sid côté serveur au moment de la création du paiement et attachez-le à l'objet Stripe en métadonnées sous la clé refcampaign_session.

Pour les paiements uniques via PaymentIntent :

const paymentIntent = await stripe.paymentIntents.create({
  amount: 2400,
  currency: 'eur',
  metadata: sessionId ? { refcampaign_session: sessionId } : {},
})

Pour les abonnements via Checkout Session, attachez les métadonnées à la fois à la session et à subscription_data — les métadonnées de session couvrent l'événement de paiement initial, et subscription_data.metadata transporte la valeur jusqu'à chaque webhook de renouvellement :

const sessionId = req.cookies.get('_rc_sid')?.value
const metadata = sessionId ? { refcampaign_session: sessionId } : {}

const checkout = await stripe.checkout.sessions.create({
  line_items: [{ price: priceId, quantity: 1 }],
  metadata,
  subscription_data: { metadata },
  mode: 'subscription',
  success_url: `${appUrl}/success`,
  cancel_url: `${appUrl}/pricing`,
})

Placez refcampaign_session sur la Subscription, pas sur l'objet Customer, pour les paiements récurrents. Chaque abonnement est lié à un parrainage d'affilié spécifique. Un client qui résilie et se réabonne via un lien d'affilié différent crée un nouvel abonnement — c'est le nouveau lien qui est crédité, pas l'original.

RefCampaign traite les webhooks Stripe de manière asynchrone. Les conversions apparaissent dans le tableau de bord dans un délai d'environ 10 minutes après le déclenchement du webhook, pas en temps réel. La file de traitement relance les livraisons échouées jusqu'à 5 fois avant de marquer une conversion comme non résolvable.

Étape 3 : suivre les conversions manuellement pour les paiements non-Stripe

Si vous traitez des paiements en dehors de Stripe — via PayPal, virement bancaire, ou un système de facturation personnalisé — utilisez le SDK serveur pour soumettre les conversions directement :

import { RefCampaignServer } from '@refcampaign/sdk'
const rc = new RefCampaignServer(process.env.REFCAMPAIGN_SECRET_KEY!)

await rc.trackConversion({
  orderId: order.id,   // requis — clé d'idempotence, évite les commissions dupliquées
  sessionId,
  amount: 4999,        // en centimes
  currency: 'EUR',
})

Le champ orderId est requis et sert de clé d'idempotence : si votre backend soumet deux fois la même conversion, RefCampaign ne crée qu'un seul enregistrement de commission. Fournissez sessionId, customerEmailHash ou un affiliateCode connu indépendamment par votre serveur. Sans signal d'attribution, RefCampaign ne peut pas identifier quel affilié créditer.

Étape 4 : activer l'attribution cross-device avec identify()

Après la connexion ou l'inscription, une fois que vous connaissez l'email de l'utilisateur, appelez identify() une fois côté client. Le SDK navigateur hache l'email en SHA-256 via Web Crypto avant toute transmission — l'email brut ne quitte jamais le navigateur. Le hash est attaché uniquement lorsqu'une session _rc_sid consentie existe ; sans elle, identify() ne fait rien.

import { RefCampaignBrowser } from '@refcampaign/sdk'
// À appeler une fois après la connexion ou l'inscription, quand currentUser.email est disponible
RefCampaignBrowser.identify(currentUser.email)

identify() est fire-and-forget et first-write-wins : le hash d'email attaché à l'enregistrement de clic ne change pas lors des appels suivants pour la même session.

---

Choisir la bonne configuration pour votre intégration Stripe

Si vous hésitez entre intégrer RefCampaign nativement via les métadonnées Stripe ou passer par une couche d'intégration tierce, commencez par le guide de suivi d'affiliation Stripe, puis comparez les architectures dans l'article logiciel d'affiliation natif Stripe vs intégration. Pour la vue produit, la page logiciel d'affiliation Stripe montre comment ce modèle metadata et webhook se relie aux campagnes, commissions et revues de payout.

En résumé : l'attribution native Stripe via les métadonnées est plus fiable que toute approche qui dépend d'un pipeline webhook séparé ou d'un signal de conversion côté navigateur, parce que l'attribution voyage à l'intérieur de l'objet de paiement Stripe plutôt qu'à côté.

Pour une comparaison plus large des plateformes de tracking d'affiliation — notamment leur gestion d'ITP, du postback et de l'intégration Stripe — consultez le comparatif des logiciels d'affiliation 2026.

---

Une implémentation complète en une demi-journée

L'implémentation décrite ici — script CDN passif, callbacks CMP, transmission des métadonnées Stripe et appel identify() optionnel — peut être réalisée en une demi-journée pour un backend Next.js ou Node.js standard. L'étape des métadonnées Stripe est critique : elle transporte l'attribution consentie dans le flux de paiement côté serveur.

Si votre programme génère du chiffre d'affaires mais que vous n'êtes pas certain que votre tracking l'attribue correctement, l'article de diagnostic sur les pannes de suivi d'affiliation vous aidera à identifier quelle défaillance vous coûte des attributions.

Pour mettre en place le suivi des conversions d'affiliation sur RefCampaign, démarrez un essai gratuit ou consultez les tarifs. L'infrastructure de tracking décrite dans ce guide est active sur tous les plans.