Apprenez à concevoir et construire une application web qui suit les clics, conversions et revenus des partenaires. Couvre le modèle de données, le tracking, le reporting, les paiements et la confidentialité.
L'attribution des revenus partenaires est le système qui répond à une question simple : quel partenaire doit recevoir le crédit (et combien) pour un événement générateur de revenus ? Dans une application web, cela signifie que vous ne comptez pas seulement les clics : vous reliez le parrainage d'un partenaire à une conversion ultérieure, vous le transformez en un chiffre de revenu clair et vous rendez le tout auditable.
Commencez par écrire une définition en une phrase qui inclut (1) ce qui est attribué, (2) à qui, et (3) selon quelles règles. Par exemple :
Cette définition devient l'ancre de vos exigences, de votre modèle de données et des litiges que vous aurez à résoudre plus tard.
“Partenaire” regroupe souvent plusieurs groupes avec des attentes et des flux différents :
Évitez d'imposer dès le départ un seul flux pour tous. Vous pouvez utiliser un système unifié (partenaires, programmes, contrats) tout en supportant plusieurs méthodes de parrainage (liens, codes, accords manuels).
Une application pratique d'attribution des revenus partenaires doit fournir de manière fiable quatre résultats :
Si l'un de ces éléments est faible, les partenaires ne feront pas confiance aux chiffres — même si les calculs sont corrects.
Pour un guide de construction exploitable, l'objectif n'est pas de débattre de la philosophie d'attribution — c'est de vous aider à livrer un système fonctionnel. Une première version réaliste devrait :
click_id et les conserver jusqu'à l'inscription/au checkoutVous pourrez ajouter des fonctionnalités avancées (attribution multi-touch, stitching cross-device, scoring anti-fraude complexe) une fois que les bases seront fiables et testables.
Avant de choisir un modèle d'attribution ou de concevoir une base de données, clarifiez ce que l'application doit prouver à l'entreprise. L'attribution des revenus partenaires est finalement un ensemble de réponses auxquelles les gens font assez confiance pour payer.
La plupart des équipes construisent d'abord pour les “partenaires” et découvrent ensuite que les finances ou le support ne peuvent rien vérifier. Listez vos utilisateurs principaux et les décisions qu'ils prennent :
Formulez-les comme des requêtes en langage simple que votre UI et vos rapports doivent supporter :
Au minimum, prévoyez : click, lead, début d'essai, achat, renouvellement, et remboursement/chargeback. Décidez lesquels sont « commissionnables » et lesquels servent de preuves de support.
Commencez avec un jeu de règles clair — fréquemment last-touch dans une fenêtre configurable — puis ajoutez le multi-touch seulement si vous avez de forts besoins de reporting et des données propres. Gardez la première version simple à expliquer et à auditer.
Avant d'écrire le moindre code, décidez ce qui « obtient le crédit » et quand ce crédit expire. Si vous ne définissez pas les règles en amont, vous vous retrouverez à débattre des cas limites (et des plaintes partenaires) à chaque cycle de paiement.
Dernier clic attribue 100 % du crédit au clic partenaire le plus récent avant la conversion. C'est simple et largement compris, mais peut sur-récompenser le trafic coupon en fin de parcours.
Premier clic attribue 100 % du crédit au premier partenaire qui a introduit le client. Il privilégie les partenaires de découverte, mais peut sous-récompenser ceux qui ferment la vente.
Linéaire répartit le crédit de manière égale entre tous les points de contact partenaires qualifiants dans la fenêtre. Cela peut sembler “équitable”, mais est plus difficile à expliquer et dilue les incitations.
Décroissance temporelle assigne plus de crédit aux touches proches de la conversion tout en reconnaissant l'influence antérieure. C'est un compromis, mais nécessite plus de calculs et un reporting plus clair.
Choisissez un modèle par défaut pour la plupart des conversions (beaucoup d'apps démarrent avec dernier clic parce qu'il est plus facile à expliquer et à rapprocher). Documentez ensuite explicitement les exceptions afin que le support et la finance puissent les appliquer de manière cohérente :
Fixez une ou plusieurs fenêtres comme 7 / 30 / 90 jours. Une approche pratique est une fenêtre standard (par ex. 30 jours) plus des fenêtres plus courtes pour les partenaires coupons si nécessaire.
Définissez aussi des règles de réengagement : si un client clique un autre lien partenaire dans la fenêtre, changez-vous immédiatement le crédit (dernier clic), le partagez-vous, ou conservez-vous le partenaire initial sauf si le nouveau clic est dans une « fenêtre proche » (par ex. 24 heures) ?
Décidez ce que vous attribuez : l'achat initial seulement, ou le revenu net dans le temps.
Rédigez ces règles dans un court document « Politique d'attribution » et liez-le dans votre portail partenaire pour que le comportement système corresponde aux attentes des partenaires.
Un modèle de données propre fait la différence entre « nous pensons que ce partenaire a généré la vente » et « nous pouvons le prouver, le rapprocher et payer correctement ». Commencez par un petit ensemble d'entités cœur et rendez explicites les relations via des IDs immuables.
partner_id, statut, conditions de paiement, devise par défaut.campaign_id, dates de début/fin.link_id, appartient à partner_id et optionnellement à campaign_id.click_id, référence link_id et partner_id.visitor_id (souvent dérivée d'un ID de cookie first-party).conversion_id, référence click_id (quand disponible) et visitor_id.order_id, référence customer_id et liée à conversion_id.payout_id, référence partner_id et agrége les commandes éligibles.Votre parcours idéal est :
partner_id → link_id → click_id → visitor_id → conversion_id → order_id → payout_id
Conservez customer_id aux côtés de order_id afin que les achats répétés puissent suivre vos règles (par ex. « première commande seulement » vs « à vie »). Stockez à la fois vos IDs internes et externes (par ex. shopify_order_id) pour la réconciliation.
Les commandes évoluent. Modélisez cela explicitement :
gross_amount, tax_amount, shipping_amount, fee_amount, discount_amount.currency_code ainsi qu'un fx_rate_to_payout_currency (et l'horodatage/source de ce taux).order_id (ex. order_adjustment_id, type = partial_refund). Cela préserve un historique auditable et évite de réécrire les totaux.Ajoutez des champs d'audit partout : created_at, updated_at, ingested_at, source (web, server-to-server, import), et des identifiants immuables.
Pour l'analyse anti-fraude sans stocker de données personnelles brutes, conservez des champs hachés comme ip_hash et user_agent_hash. Enfin, gardez un journal de changements léger (entité, entity_id, valeurs old/new, acteur) afin que les décisions de paiement puissent être expliquées ultérieurement.
Le suivi des clics est la base de l'attribution des revenus partenaires : chaque lien partenaire devrait créer un enregistrement de “click” durable que vous pourrez ensuite relier à une conversion.
Utilisez un format de lien canonique unique que les partenaires peuvent copier/coller partout. Dans la plupart des systèmes, le lien côté partenaire ne devrait pas inclure un click_id — votre serveur le génère.
Un schéma propre est :
/r/{partner_id}?campaign_id=...&utm_source=...&utm_medium=partner&utm_campaign=...
Conseils pratiques pour les paramètres :
Routez tout le trafic partenaire via un endpoint de redirection (ex. /r/{partner_id}) :
click_id unique (UUID/ULID) et stocker une ligne click côté serveur (partner_id, campaign_id, user agent, ip_hash, timestamp, landing URL).click_id.Cela rend la création du clic cohérente, empêche les partenaires de falsifier les click_id, et centralise l'application des règles.
La plupart des équipes utilisent cookie comme primaire, localStorage en fallback, et les sessions côté serveur uniquement pour les flux de courte durée.
Pour le web mobile, les cookies peuvent être moins fiables, utilisez donc l'endpoint de redirection et stockez le click_id à la fois en cookie et en localStorage.
Pour app-to-web, supportez :
click_id original.Documentez précisément les règles de lien dans votre portail partenaire (voir /blog/partner-links) pour que les partenaires n'« inventent » pas des paramètres.
Le suivi des conversions est l'endroit où les systèmes d'attribution gagnent ou perdent la confiance. Votre objectif est d'enregistrer un événement de “conversion” canonique par achat réel (ou par inscription), avec suffisamment de contexte pour le connecter à un clic partenaire.
La plupart des produits peuvent observer les conversions depuis plusieurs endroits :
Recommandation : traitez votre service de commande backend comme l'enregistreur canonique des conversions, et utilisez éventuellement les webhooks de paiement comme signal de confirmation/mise à jour (ex. passer une commande de pending à paid). Les événements côté client peuvent servir au debugging ou à l'analytics de funnel, pas pour l'attribution de niveau paiement.
Pour attribuer le revenu plus tard, l'événement de conversion a besoin d'un identifiant stable et d'un moyen de lier à un clic.
Approche commune :
click_id.click_id à la commande (par ex. depuis l'état de session, le record client, ou un token signé envoyé par le client).Votre jointure primaire doit être conversion.click_id → click.id. Si click_id manque, définissez des règles de secours explicites, telles que :
Rendez ces règles visibles dans les outils d'administration afin que le support puisse expliquer les résultats sans deviner.
Les webhooks et appels client vont retry. Vous devez pouvoir recevoir la même conversion plusieurs fois sans double-comptabiliser.
Implémentez des clés d'idempotence en utilisant une valeur unique stable, telle que :
order_id (meilleur si globalement unique)payment_provider_charge_idStockez la clé sur le record de conversion avec une contrainte d'unicité. En cas de retry, retournez un succès et ne créez pas une seconde conversion. Ce seul choix évite les bugs les plus courants de revenus fantômes lors des paiements.
L'attribution des revenus partenaires est l'ensemble des règles et des données qui déterminent quel partenaire obtient le crédit pour un événement de revenu (et combien), sur la base d'éléments de preuve tels que des click_id, des codes promo et des fenêtres temporelles.
Une définition utile inclut :
Commencez par rédiger une politique d'une phrase, puis listez les exceptions.
Une bonne politique V1 est souvent :
click_id capturé via redirect et attaché côté serveur à la commandeDocumentez ensuite les exceptions comme la priorité des coupons, les renouvellements et si le trafic direct rompt l'attribution.
Au minimum, suivez :
Même si vous ajoutez plus tard les leads ou les essais, ces trois éléments vous permettent de relier trafic → revenu → reversals de manière sûre pour les paiements.
Utilisez un endpoint de redirection (par ex. /r/{partner_id}) qui :
click_id émis par le serveurCela empêche les partenaires de falsifier les et rend le tracking cohérent selon les emplacements.
Privilégiez la création de commande côté serveur (votre backend) comme source canonique de conversions.
Concrètement :
click_id (ou token d'attribution) à la commande au moment de sa créationCela réduit les envois en double et facilite beaucoup la réconciliation financière.
Utilisez des clés d'idempotence pour que les tentatives répétées n'entraînent pas de duplications de conversions.
Clés courantes :
order_id (meilleur si globalement unique)payment_provider_charge_idAppliquez une contrainte d'unicité dans la base. Si une requête est répétée, retournez un succès sans créer une seconde conversion ni une seconde ligne de commission.
Visez une chaîne que vous pouvez prouver de bout en bout :
partner_id → link_id → click_id → visitor_id → conversion_id → order_id → payout_idStockez à la fois les IDs internes et externes (par ex. shopify_order_id) et conservez des horodatages (created_at, ingested_at) pour tracer les litiges et réconcilier avec votre système de facturation.
Modélisez l'argent en pensant à l'auditabilité et aux reversals :
currency_codeCommencez par un petit ensemble d'écrans qui réduisent les tickets de support :
Faites en sorte que chaque conversion soit explicable avec des champs de preuve comme l'heure du clic, l'ID de commande (masqué) et la règle appliquée.
Utilisez des protections légères et cohérentes :
Pour la confidentialité, stockez le minimum nécessaire (IDs pseudonymes), hachez les signaux sensibles (comme l'IP) quand c'est possible et évitez de logger des données personnelles ou de paiement.
click_idCela préserve l'historique et vous permet de créer des lignes négatives dans des cycles de paiement ultérieurs si nécessaire.