Attribution web : du clic publicitaire à l’inscription

Sur un site web, la conversion qui compte — une inscription, un abonnement, un achat — a lieu sur votre backend, là où l’id utilisateur est connu, souvent des minutes ou des jours après le clic publicitaire et plusieurs pages plus loin. Traqio relie les deux grâce au trackID, l’id du clic lui-même : il voyage dans l’URL d’arrivée, attend en stockage first-party sur votre propre domaine, et atteint votre backend avec la requête d’inscription, qui le signale avec l’id de l’utilisateur. La conversion est rattachée au clic qu’il désigne — de façon déterministe, jamais en rapprochant des appareils qui se ressemblent.

La chaîne, étape par étape#

Le trackID dans l’URL d’arrivée#

Un lien de tracking avec une destination site web envoie tous les appareils vers cette page — téléphone ou ordinateur — et ajoute les paramètres de Traqio à sa query string : traq_click (le trackID) et, quand le lien les a, traq_source, traq_campaign, traq_adset et traq_ad. Vos propres paramètres — utm_* compris — et le #fragment de la page sont conservés tels que vous les avez écrits ; le préfixe traq_ n’entre jamais en conflit avec eux. Un lien sans destination site web continue d’envoyer vers l’App Store et Google Play, comme avant.

Le stockage first-party#

@traqio/web lit traq_click dès son démarrage, avant toute autre chose : un visiteur qui repart aussitôt le garde quand même. Il le stocke deux fois, les deux fois sur votre domaine :

• dans le localStorage, avec sa date d’expiration — il survit à la navigation et revient sur la même origine ;
• dans un cookie traq_click sur votre domaine enregistrable (example.com), pour que www., app. et votre backend sur le même domaine le voient tous — le backend le reçoit avec la requête d’inscription, sans JavaScript.

Il est gardé 30 jours par défaut (trackIdDays). Pas de cookie tiers, pas de fingerprint, pas d’identifiant publicitaire. Avec waitForConsent, rien n’est écrit sur l’appareil avant que le visiteur ait donné son consentement.

Lier la conversion à un utilisateur, sur votre serveur#

Votre backend signale l’inscription avec un SDK serveur — Node.js, PHP / Laravel ou Python — avec deux éléments : votre id utilisateur et le trackID. Il s’authentifie avec une clé serveur, un secret qui ne quitte jamais votre backend. C’est ce secret qui permet d’accepter sans risque un click id fourni par l’appelant : la clé web de votre page pourrait être utilisée par n’importe qui, elle ne peut donc jamais rien attribuer.

Les règles appliquées par Traqio#

• Un clic, une identité. Un clic lié à un utilisateur ne peut être revendiqué ni par un autre utilisateur, ni par une installation d’app — la réponse est claimed. Signaler de nouveau le même clic pour le même utilisateur ne change rien.
• La fenêtre. Un clic plus ancien que la fenêtre d’attribution du produit est expired.
• Anti-fraude. Un clic passé par un réseau d’anonymisation est refused et compté, comme pour une installation d’app.
• L’acquisition, c’est l’inscription. La première inscription signalée est conservée ; le dernier clic qui la précède, dans la fenêtre, reçoit le crédit. Un clic postérieur ne crédite rien.
• Les conversions suivent l’utilisateur. Un achat signalé plus tard avec le même id utilisateur est un revenu de la campagne qui a acquis cet utilisateur — dédoublonné sur son id d’événement et son id de paiement.

Chaque appel répond avec ce qu’il a décidé : le statut du trackID et la campagne désormais créditée pour l’utilisateur.

Dans la console, le rapport ROAS compte les conversions web d’une campagne comme un chiffre à part, à côté de ses installations et jamais dedans, et un achat fait sur votre site est un revenu de la campagne de son utilisateur. Le générateur de rapports propose les conversions web, les conversions web attribuées et le coût par conversion web ; un produit uniquement web a un KPI de conversions web sur sa Vue d’ensemble et un modèle de tableau de bord Acquisition du site.

Un produit avec une app et un site#

L’id utilisateur est l’identité. Quand votre app et votre backend signalent le même id utilisateur, Traqio voit une seule personne : le dernier clic éligible avant l’acquisition l’emporte, quelle que soit la surface d’où il vient. Une installation d’app garde l’attribution qu’elle a reçue, et une conversion envoyée depuis votre serveur n’est jamais rattachée à une installation d’app : les installations, revenus et ROAS des apps restent exactement ce que les apps remontent.

Limites#

• Un autre navigateur, sans connexion. Un clic dans le navigateur intégré d’une app suivi d’une inscription dans Safari ne porte aucun trackID : l’inscription est organique, jamais devinée.
• Safari garde 7 jours le stockage écrit en JavaScript sur les sites qu’il classe comme traqueurs : un trackID peut y expirer plus tôt.
• Un backend sur un autre domaine ne reçoit pas le cookie : le formulaire doit envoyer Traqio.getTrackId() lui-même.

Questions fréquentes#

Qu’est-ce que le trackID ?

L’id d’un clic publicitaire. Quand quelqu’un clique sur un lien de tracking Traqio dont la destination est une page de votre site, Traqio enregistre le clic et ajoute son id à l’URL d’arrivée dans le paramètre traq_click. Cet id est le trackID : il désigne ce clic précis, si bien que la conversion jusqu’à laquelle il voyage y est rattachée sans aucune estimation.

L’attribution web est-elle probabiliste ?

Non. Le trackID voyage du clic à la conversion en stockage first-party sur votre propre domaine, puis votre backend le transmet à Traqio avec l’id de l’utilisateur. La conversion est rattachée au clic qu’il désigne. Une conversion qui arrive sans trackID est organique — jamais affectée à une campagne par ressemblance.

Pourquoi le SDK navigateur ne peut-il pas envoyer le trackID lui-même ?

Parce que sa clé est publique : elle est dans votre page, où n’importe qui peut la lire et s’en servir pour envoyer des requêtes. Une clé utilisable par tous ne doit pas pouvoir créditer une campagne : rattacher une conversion à un clic demande donc la clé serveur secrète, que seul votre backend détient.

Que se passe-t-il quand la même personne utilise l’app et le site ?

Si votre backend et votre app utilisent le même id utilisateur, c’est la même identité dans Traqio : le dernier clic éligible avant l’acquisition de l’utilisateur — sur le web ou dans l’app — reçoit le crédit. Une installation d’app garde sa propre attribution, et une conversion web n’est jamais rattachée à une installation d’app.