Attribution first-party : suivre tes visiteurs sans cookies tiers

Tu lances une campagne, tu vois 400 visiteurs dans Google Analytics, 12 inscriptions… et tu es incapable de dire lesquels viennent de quelle source. Bienvenue dans l'attribution post-cookies tiers, où 30 à 50 % de ton trafic est devenu invisible. La bonne nouvelle : tu n'as pas besoin de GA ni de pixels tiers. Un pixel servi par ton propre domaine suffit à reconstruire la chaîne visite → inscription → revenu, et il survit à tout ce qui casse les trackers classiques.

Pourquoi les solutions classiques s'effondrent

Les pixels tiers (Meta Pixel, le `gtag.js` de Google, Hotjar…) posent un cookie ou lisent un identifiant depuis un domaine différent du tien. C'est exactement ce que les navigateurs ont décidé de tuer. Trois forces convergent et tu les subis déjà :

• Safari / ITP : un cookie posé en JavaScript (`document.cookie`) est plafonné à 7 jours, et à 24 h si le visiteur arrive via un lien avec paramètres de tracking. Ton attribution à 30 jours est morte avant d'avoir commencé.
• Cookies tiers bloqués : Safari et Firefox les bloquent par défaut depuis des années. Chrome a fait machine arrière sur la suppression totale en 2024, mais a généralisé un opt-out qui vide quand même le réservoir.
• Consentement strict (RGPD) : sans bannière acceptée, GA et les pixels marketing ne doivent pas se charger. Résultat : un trou béant dans tes données, et un trou qui n'est pas aléatoire (les refus corrèlent avec certains profils).

Le point commun de ces trois cassures : elles visent le tiers. Si l'identifiant vient de ton domaine et ne sert qu'à toi, la plupart de ces règles ne s'appliquent pas de la même façon.

Le principe : un pixel first-party + un visitor_id anonyme

L'idée tient en trois pièces. Tu sers un endpoint de collecte sur ton propre domaine (idéalement un sous-domaine comme `t.tonapp.com`, pas un domaine de tracking externe). À la première visite, tu génères un `visitor_id` aléatoire et tu le stockes dans un cookie first-party, HttpOnly, Secure. À chaque page vue, le navigateur renvoie ce cookie à ton serveur, qui logge l'événement. Le détail qui change tout : le cookie est posé par une réponse HTTP `Set-Cookie` côté serveur, pas par `document.cookie` en JavaScript. C'est cette nuance qui contourne le plafond de 7 jours d'ITP — la limite vise les cookies posés en JS, pas ceux posés par le serveur en first-party. Et `HttpOnly` les rend illisibles par n'importe quel script, donc inexploitables pour du vol via XSS.

# Réponse de ton endpoint /t/collect servi sur t.tonapp.com
HTTP/1.1 204 No Content
Set-Cookie: vid=8f3c1a9e-...; Max-Age=63072000; Path=/;
  Domain=.tonapp.com; HttpOnly; Secure; SameSite=Lax

// pixel.js côté client (~10 lignes) :
// fetch("https://t.tonapp.com/t/collect", {
//   method: "POST", credentials: "include", keepalive: true,
//   headers: { "Content-Type": "application/json" },
//   body: JSON.stringify({ path: location.pathname,
//     ref: document.referrer, utm: location.search, ts: Date.now() }) });

La fusion : du visitor_id anonyme à l'identité prouvée

Tant que le visiteur est anonyme, tu accumules des événements rattachés à un `visitor_id` opaque. La magie opère au moment de l'inscription : l'utilisateur prouve son email (lien de confirmation ou OTP), et tu fais le stitching — tu relies le `visitor_id` du cookie au compte fraîchement créé. À cet instant, toute l'histoire anonyme d'avant (première visite, source, pages vues) se rattache rétroactivement à une identité réelle.

1. Au moment du signup, lis le cookie `vid` côté serveur dans la même requête.
2. Écris une ligne `identity(visitor_id, user_id, email_verified_at)` — l'email prouvé, pas juste saisi.
3. Recolle tous les événements anonymes portant ce `visitor_id` au `user_id`. Tu obtiens le chemin complet : Twitter → /pricing → /signup → email confirmé.
4. Bonus : si le même email se reconnecte depuis un autre appareil, fusionne deux `visitor_id` sous un seul `user_id`.

Ce que tu gagnes vs Google Analytics et pixels tiers

• Attribution longue durée : ton cookie serveur peut viser 2 ans au lieu de 24 h. Pour un funnel B2B où la décision prend 3 semaines, c'est la différence entre attribuer une vente et la perdre dans le bruit.
• Données complètes : tu logges côté serveur, donc les bloqueurs (uBlock, Brave) qui mangent `gtag.js` ne te touchent pas. Tu vois ton vrai trafic, pas la version trouée par les extensions.
• Jointure directe avec ton revenu : le `visitor_id` est dans ta base, à côté de tes tables `users` et `subscriptions`. Tu fais un `JOIN` SQL entre une source et du MRR réel — impossible avec l'agrégat anonymisé de GA4.
• Conformité plus simple à cadrer : un identifiant strictement first-party, à finalité de mesure interne, est plus facile à justifier que de balancer la donnée à Google et Meta. À valider avec ton avocat, mais le périmètre est radicalement plus net.
• Pas de sampling ni de seuil de cardinalité : GA4 échantillonne et masque les segments < ~50 users. Sur tes propres logs, chaque ligne existe.

Les pièges qui cassent le setup en prod

• Servir le pixel depuis un sous-domaine bien à toi : un CNAME vers un domaine de tracking connu (du genre `.analytics-vendor.com`) est requalifié en tiers par ITP, qui réimpose le plafond 7 jours. Le sous-domaine doit résoudre vers ton* infra.
• `SameSite=Lax` minimum : avec `None` sans raison, tu réintroduis du comportement tiers. `Lax` couvre le cas normal (clic vers ton site).
• Idempotence du stitching : un même `visitor_id` peut arriver deux fois (double-submit, retry). Clé unique sur `(visitor_id, user_id)`.
• Effacer la PII des logs bruts : ne logge pas l'IP en clair éternellement. Tronque ou hashe ; garde l'IP juste assez pour le géo/anti-fraude.
• Le cas "jamais inscrit" : 95 % des visiteurs ne se fusionneront jamais. C'est normal. Tu gardes l'agrégat anonyme pour le top-of-funnel, la fusion ne concerne que les convertis.

Commence petit : un endpoint, un cookie `Set-Cookie` HttpOnly servi sur ton sous-domaine, une table `events(visitor_id, path, ref, ts)` et une table `identity(visitor_id, user_id)` peuplée quand l'email est prouvé. Tu auras en une après-midi une attribution qui survit à Safari, aux bloqueurs et au consentement — et qui se branche directement sur ton MRR. Quand ça tourne, ajoute le multi-device et le décompte des sources. Le reste, c'est du SQL.