Suivi des conversions pour liens courts : identifiants de clic, fenêtres et événements serveur

Tout rapport de liens a un point d’arrêt naturel, et pour la plupart des équipes c’est le clic. Le tableau de bord annonce qu’un lien a été ouvert quatre mille fois le mois dernier, réparti par pays, appareil, navigateur et source, et l’analyse s’arrête là. Mais quatre mille clics décrivent ce que vous avez dépensé, pas ce que vous avez gagné. C’est la moitié bon marché du tunnel, et c’est celle qui rend le mieux sur une capture d’écran.

Le suivi des conversions comble l’écart : il transporte un identifiant depuis l’instant de la redirection jusqu’au système qui finit par enregistrer la commande, puis le fait revenir. L’idée est simple à décrire et facile à rater d’une manière qui ne se voit que des mois plus tard, sous la forme de rapports de chiffre d’affaires qui ne se rapprochent pas des factures. Cet article couvre l’identifiant, la fenêtre d’attribution et pourquoi c’est une décision commerciale, la différence entre un événement serveur et un événement navigateur, pourquoi l’argent est un entier, comment les doublons sont traités, et quoi faire quand la conversion se produit dans un système que vous ne contrôlez pas.

Un clic est un coût, pas un résultat

Le reporting limité aux clics persiste parce que le clic est la mesure facile. Une redirection se produit sur une infrastructure que vous contrôlez : la compter n’exige la coopération de personne, alors que tout ce qui vient ensuite se passe ailleurs. Notre guide sur la façon dont les clics sont réellement mesurés détaille ce que peut contenir un événement de clic isolé, et le résumé tient en une phrase : il sait que le clic a eu lieu, et rien de ce qui a suivi.

Cette limite a des conséquences bien réelles. Deux placements peuvent produire des volumes de clics identiques alors que l’un envoie des acheteurs et l’autre des visiteurs qui repartent en trois secondes. Une répartition par pays impressionnante sur les clics peut s’inverser sur le chiffre d’affaires. Les tests A/B tranchés au taux de clic retiennent régulièrement la variante au titre le plus agressif et au tunnel de commande le moins abouti. Tant que le chiffre d’affaires n’est pas attaché aux mêmes dimensions, chacun de ces jugements est une intuition déguisée en métrique.

L’y attacher ne demande qu’une chose : une valeur qui survive au trajet de la redirection jusqu’à la commande.

L’identifiant, c’est tout le dispositif

À chaque redirection, le worker émet un jeton et en fait deux choses. Il l’ajoute à l’adresse de destination sous un nom de paramètre que vous choisissez, lp_cid par défaut, et il écrit la même valeur dans un cookie propriétaire sur votre domaine de redirection, valable 90 jours.

Deux copies existent parce que chacune peut se perdre. Les destinations suppriment les paramètres de requête, parfois délibérément pour garder des URL propres, parfois comme effet de bord d’une redirection de leur côté. À l’inverse, un visiteur qui clique aujourd’hui et revient trois jours plus tard en tapant l’adresse n’a plus aucun paramètre, mais porte toujours le cookie. Aucune des deux copies n’est fiable seule ; ensemble, elles couvrent la plupart des trajets réalistes vers un achat.

Que le cookie soit propriétaire n’est pas un détail technique. Il est posé par votre propre domaine de redirection, celui vers lequel le visiteur a effectivement navigué, et c’est précisément la catégorie de cookie que les navigateurs n’ont pas retirée. C’est pour cela qu’un domaine personnalisé cesse d’être une préférence de marque pour devenir une infrastructure de mesure : sur un domaine partagé du fournisseur, le cookie appartient au fournisseur.

Ce que transporte le jeton

Le jeton est signé, et la signature couvre plus que le clic. Les identifiants d’espace de travail et de partenaire font partie de la charge signée : un jeton émis sur le lien d’un client est donc rejeté dans l’espace d’un autre client exactement comme un faux. Pour quiconque gère des liens pour plusieurs clients, le chiffre d’affaires de l’un reste hors du rapport de l’autre par construction, et non grâce à un filtre que quelqu’un a pensé à appliquer.

Ce que contient le jeton est délibérément restreint : le moment du clic, le lien, la variante du test, le pays, la classe d’appareil, la source de trafic et un indicateur de trafic suspect. Aucune donnée personnelle. Cette liste est aussi ce qui rend la colonne de chiffre d’affaires utile, parce que chacun de ces champs devient une dimension par laquelle répartir le chiffre d’affaires dans les statistiques, sans avoir à joindre quoi que ce soit d’autre.

Le nom du paramètre et l’interrupteur d’activation vivent dans les réglages de l’espace de travail, et modifier l’un ou l’autre réécrit immédiatement la configuration mise en cache de chaque lien. Une conséquence à anticiper : quand un forfait n’inclut pas les conversions, le redirecteur cesse purement et simplement d’émettre des identifiants, et l’activer plus tard ne crée pas rétroactivement d’identifiants pour les clics déjà survenus.

La fenêtre d’attribution est une décision commerciale

La fenêtre, c’est l’âge maximal d’un clic encore susceptible d’être crédité d’une conversion. C’est un réglage par espace de travail, et c’est le seul chiffre de cet article qui mérite d’être discuté plutôt qu’accepté tel quel.

Trop courte, elle jette du chiffre d’affaires que vous avez réellement produit. Beaucoup trop longue, elle crédite les liens d’achats qui auraient eu lieu de toute façon, ce qui est pire qu’inutile : c’est faux avec assurance. Choisissez en mesurant l’écart entre le premier contact et l’achat sur les commandes que vous savez déjà tracer : un achat d’impulsion se conclut en minutes, un achat grand public réfléchi prend des jours, un achat professionnel avec étape de validation prend des semaines.

Le mode de défaillance que cette conception évite, c’est le rejet silencieux. Une conversion qui arrive après la fenêtre est refusée avec attribution_expired, un code distinct de invalid_click_id. Ces deux situations appellent des corrections entièrement différentes, et une intégration qui reçoit la même erreur générique pour les deux passera une semaine à déboguer le mauvais problème. Journalisez le code, comptez les deux séparément, et traitez une hausse du taux d’attribution_expired comme le signe que votre fenêtre ne correspond plus à votre cycle de vente.

Les deux portes d’entrée n’ont pas non plus le même plafond. Le cookie vit 90 jours : un rapport côté navigateur qui en dépend ne peut pas aller au-delà. Un rapport côté serveur stocke l’identifiant lui-même et n’est borné que par la fenêtre de l’espace de travail.

Deux portes d’entrée, un seul jeu de règles

Les deux chemins passent par le même service : la fenêtre, la déduplication et la livraison sortante se comportent donc à l’identique. Ce qui diffère, c’est ce à quoi chaque chemin survit et ce qu’il exige de vous.

L’événement serveur

Votre backend envoie l’identifiant avec un objectif, un identifiant de commande, un montant et une devise.

curl -X POST https://api.linkprofit.com/v1/conversions \
  -H "Authorization: Bearer lp_live_..." \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: order-10241" \
  -d '{
    "click_id": "1.eyJ1aWQiOiJ...",
    "goal": "purchase",
    "order_id": "10241",
    "amount_cents": 4999,
    "currency": "usd"
  }'

La clé doit porter la portée conversions:write, ce qui veut dire que ce chemin vous coûte quelque chose que le chemin navigateur ne coûte pas : un secret à émettre, à stocker et à faire tourner. Voir l’authentification de l’API pour la gestion des clés à portées, et gardez cette clé sur un serveur — une clé disposant d’un accès en écriture à vos données de chiffre d’affaires n’a rien à faire dans une page.

Ce que vous obtenez en échange, c’est un rapport qu’aucun bloqueur de publicité, bloqueur de scripts, réglage de protection contre le suivi ou erreur JavaScript ne peut supprimer. Il part de votre propre infrastructure au moment où votre propre système reconnaît qu’une commande existe : il reflète donc la vérité après les contrôles antifraude, et non l’instant optimiste où un bouton a été pressé.

L’événement navigateur

Le worker sert un petit script depuis votre propre domaine de redirection, et la page de remerciement l’appelle.

<script src="https://go.example.com/cv.js" defer></script>
<script>
  window.lpConversion({ goal: 'purchase', orderId: '10241', amountCents: 4999, currency: 'usd' });
</script>

Le script lit l’identifiant depuis l’URL ou depuis le cookie propriétaire : rien ne doit lui être transmis à la main. Aucun hôte tiers n’intervient dans la chaîne, ce qui compte deux fois : c’est une propriété de confidentialité, et une propriété de marque blanche, parce que la page de votre client ne charge rien qui nomme la plateforme sous-jacente.

Le prix à payer est celui, habituel, de la mesure côté client. Les bloqueurs, les modes privés, les chargements de script échoués et un visiteur qui ferme l’onglet une demi-seconde trop tôt retirent tous des événements, et la perte n’est pas uniforme. Les audiences techniques et soucieuses de leur vie privée en suppriment bien plus que les audiences grand public : un montage uniquement navigateur ne sous-compte pas seulement, il sous-compte de façon inégale selon les segments.

Comment choisir entre les deux

Utilisez le chemin serveur partout où un serveur connaît la commande, c’est-à-dire presque partout où de l’argent change de mains. Utilisez le chemin navigateur pour les résultats qui n’existent que dans le navigateur, ou là où vous ne pouvez pas ajouter de code serveur : une page que vous ne modifiez qu’à travers un gestionnaire de balises, une inscription sur une plateforme hébergée, la page de destination d’un client qui ne vous appartient pas.

Faire tourner les deux pour un même résultat est sans danger grâce à la déduplication, mais seulement si les deux chemins envoient le même order_id. Sans cela, vous n’ajoutez pas de couverture, vous comptez le chiffre d’affaires deux fois.

Les objectifs, eux, sont légers. Un objectif est un résultat nommé, par exemple purchase, signup ou trial ; il peut porter une valeur et une devise par défaut pour les conversions qui arrivent sans montant, et un objectif référencé avant d’exister est créé à la première utilisation.

L’argent est un entier

Les montants sont des unités minimales entières. 4999 signifie 49,99 dans une devise à deux décimales, et un montant de 49.99 est rejeté avec le nom du champ plutôt qu’arrondi en silence.

Cela agace pendant environ une journée, puis sauve pendant des années. La virgule flottante binaire ne représente pas exactement la plupart des fractions décimales : la démonstration classique où l’addition de deux montants en produit un troisième avec un chiffre inattendu à la fin n’est pas une curiosité, c’est ce qui arrive à chaque somme d’une colonne de chiffre d’affaires à grande échelle. Les devises sans décimale font aussi tomber l’hypothèse selon laquelle diviser par cent serait universellement correct.

Refuser la décimale à la frontière ramène la seule transformation honnête — du prix lisible par un humain vers les unités minimales — à un endroit unique : votre code, une fois, là où vous pouvez la tester.

Les doublons sont l’affaire de la base de données

La déduplication se fait par une insertion atomique unique, et non par une lecture suivie d’une écriture. Des livraisons répétées du même order_id créent une seule conversion et la renvoient marquée comme doublon.

La distinction paraît théorique et ne l’est pas. Un « vérifier puis insérer » laisse un intervalle entre les deux opérations, et un webhook réessayé par un expéditeur impatient fait atterrir deux appels dans cet intervalle. Aucun des deux ne voit d’enregistrement existant, et tous deux en écrivent un. C’est ainsi qu’un rapport de chiffre d’affaires gagne dix pour cent fantômes que personne ne retrouve ensuite, parce que chaque enregistrement pris isolément paraît parfaitement légitime.

La règle pratique consiste à choisir un identifiant de commande stable et unique dans votre système, puis à ne plus jamais changer la façon de le dériver. Votre propre numéro de commande convient presque toujours ; un horodatage, ou quoi que ce soit qui soit régénéré au réessai, est exactement ce qu’il ne faut pas. Associez-le à un en-tête Idempotency-Key, comme dans la requête ci-dessus, et un appel échoué devient une chose que l’on répète au lieu d’enquêter dessus.

Le trafic suspect est étiqueté plutôt que caché. Le verdict du classificateur voyage à l’intérieur du jeton : une conversion attribuée à un centre de données ou à un proxy est donc marquée comme suspecte au moment de son enregistrement et apparaît dans les rapports comme un segment à part. Deux cents conversions, et deux cents conversions dont quarante venues d’une même plage d’hébergeur en une heure, sont deux faits différents, et un seul mérite d’être payé. C’est là que les données de conversion et le filtrage du trafic cessent d’être deux fonctions séparées.

Quand la conversion se produit ailleurs

L’essentiel de la difficulté, en pratique, ne vient pas de l’API. Il vient de ce que le moment qui mérite d’être mesuré se produit à l’intérieur d’une boutique hébergée, d’un CRM ou d’un prestataire de facturation, et que votre travail consiste à faire entrer dans ce système une chaîne de caractères issue du clic, puis à l’en faire ressortir.

Boutiques hébergées. Si la plateforme accepte des attributs de commande personnalisés ou des métadonnées, c’est la voie propre : lisez l’identifiant à l’arrivée du visiteur, portez-le à travers le tunnel de commande dans un champ masqué, stockez-le sur la commande, et envoyez la conversion depuis votre serveur quand la commande est confirmée plutôt qu’au moment où le bouton est pressé. Si la plateforme n’accepte aucun champ personnalisé mais autorise un script sur la page de confirmation, prenez plutôt le chemin navigateur. Notre page solutions e-commerce détaille ces choix.

CRM et ventes assistées. Capturez l’identifiant dans un champ masqué du formulaire de prospect et stockez-le sur la fiche, puis envoyez la conversion quand l’affaire est marquée gagnée. Le piège, ici, c’est le temps : une affaire qui se conclut en sept semaines réclame une fenêtre qui accepte sept semaines, et si votre CRM est le seul endroit à connaître l’identifiant, sa politique de conservation et d’export devient une pièce de votre architecture d’attribution. Envisagez d’envoyer un objectif signup à la capture du prospect et un objectif purchase à la signature, pour que le haut du tunnel soit mesuré même quand le bas prend un trimestre.

Facturation et abonnements. Laissez le webhook du prestataire de facturation servir de déclencheur. Quand une facture est payée, votre serveur retrouve l’identifiant stocké sur ce client et envoie une conversion en prenant l’identifiant de facture comme identifiant de commande. Les prélèvements récurrents arrivent alors naturellement comme des conversions distinctes, et les premiers paiements restent discernables des renouvellements grâce à l’objectif.

Dans les trois cas, le schéma est le même : le système externe n’a rien à savoir des liens. Il conserve une chaîne opaque et vous la rend.

Le trajet des chiffres ensuite est délibérément conventionnel. Un événement conversion.created signé est émis par la mécanique de webhooks habituelle, et les intégrations publicitaires configurées reçoivent la conversion via une file de livraison, avec un délai de retrait documenté et une marque d’abandon au lieu de réessais infinis. Les forfaits peuvent aussi plafonner le nombre de conversions acceptées par mois calendaire, compté en UTC, et dépasser ce plafond répond quota_exceeded plutôt qu’une restriction de forfait : « pas dans votre forfait » et « épuisé ce mois-ci » restent ainsi distinguables sans passer par le support.

Bien le faire du premier coup

1. Activez les conversions avant la campagne, pas après. Les identifiants sont émis au moment de la redirection et ne peuvent pas être créés rétroactivement.
2. Faites tourner vos liens sur votre propre domaine, pour que le cookie propriétaire vous appartienne.
3. Réglez la fenêtre sur votre cycle d’achat mesuré, puis revoyez-la quand le taux d’attribution_expired bouge.
4. Préférez le chemin serveur partout où un serveur connaît la commande.
5. Convertissez les prix en unités minimales entières à un seul endroit de votre code.
6. Utilisez votre vrai numéro de commande comme identifiant de commande, et envoyez-le à l’identique depuis chaque chemin.
7. Journalisez les codes de rejet séparément, puis rapprochez les chiffres de votre facturation une fois par période et enquêtez sur l’écart au lieu de le noyer dans une moyenne.

La référence complète des champs se trouve dans la documentation des conversions, et la page de la fonction suivi des conversions explique comment la colonne de chiffre d’affaires se comporte dans les rapports que vous lisez déjà. Rien de tout cela ne remplace la comptabilité. Cela répond à une question plus étroite, à laquelle la comptabilité ne sait pas répondre : quel lien, quel pays, quelle destination et quelle source de trafic ont produit l’argent.