Entonnoir de conversion et rétention sans cookies

Un entonnoir de conversion et un tableau de rétention posent la même question à vos données : est-ce la même personne qu’avant ? Un hash quotidien ne peut répondre oui que pendant quelques heures. Une fois qu’on a compris cela, on voit quelles questions un outil sans cookies peut traiter seul, et lesquelles exigent une connexion.

Combien de temps le « qui » doit tenir

Question	Durée nécessaire de l’identité	Hash anonyme	Personne identifiée
De la page tarifs à l’inscription, d’une traite	Quelques minutes	Oui	Oui
Page d’arrivée le matin, inscription le soir	Quelques heures	Sans doute, sur le même réseau et du même côté de minuit UTC	À partir de la demi-heure qui précède la connexion
Publicité lundi, inscription jeudi	Quelques jours	Non	Non, la visite du lundi reste anonyme
De l’essai au paiement en 14 jours	Quelques semaines	Non	Oui
Toujours actif après quatre semaines	Quelques semaines	Non	Oui

Un outil avec un identifiant durable répond aussi à la troisième ligne. C’est la vraie différence, et si cette ligne fait votre activité, il vous faut un cookie et un bandeau. PostHog, dans son mode normal, est fait pour ça : il garde un cookie pour suivre les utilisateurs d’une session à l’autre (vérifié en novembre 2026).

Pourquoi la conversion anonyme s’arrête à la journée

Dans Trailic, un entonnoir considère quelqu’un comme son identifiant utilisateur s’il en a un, et comme le hash du jour sinon. Ce hash change à minuit UTC, et aussi quand l’adresse ou le navigateur changent. La fenêtre de l’entonnoir, une semaine par défaut et jusqu’à 90 jours, n’a donc de sens que pour les personnes identifiées. Pour les anonymes, la chaîne casse avec le hash, et ils s’arrêtent à l’étape atteinte.

En France, minuit UTC tombe à 1 h du matin en hiver et 2 h en été : peu de monde est concerné. Mais c’est 19 h à New York et 16 h à San Francisco en hiver. Si vos visiteurs sont surtout américains, des entonnoirs seront coupés en pleine soirée. Attendez-vous alors à une conversion anonyme un peu sous-estimée.

Pourquoi la rétention exige des personnes identifiées

La rétention demande si quelqu’un de la semaine 1 est revenu en semaine 4. Un hash anonyme ne peut pas le savoir, par construction. La rétention de Trailic ne compte donc que les personnes qu’un site a identifiées. Les cohortes sont regroupées par le lundi de la semaine où quelqu’un a été identifié pour la première fois, et chaque semaine suivante montre la part de ceux qui sont revenus, sur n’importe quelle activité ou sur un événement de votre choix.

Le tableau décrit donc les utilisateurs de votre produit. Les visiteurs de votre site vitrine n’y figurent pas. La documentation de PostHog sur le mode sans cookies présente le même compromis vu de l’autre côté : elle déconseille d’y appeler identify(), car un identifiant persistant est une donnée personnelle.

L’écran de rétention de Trailic : des cohortes hebdomadaires dans un tableau teinté, sur des données inventées pour une société nommée Acme.

Instrumenter

La bibliothèque se trouve dans le dépôt, sous packages/trailic, et n’est pas encore sur npm. Voici comment elle s’utilise une fois dans votre projet.

Les pages vues se comptent toutes seules :

// app/layout.tsx, dans <body>, une seule fois
import { Trailic } from "trailic";

<Trailic siteKey="site_…" endpoint="https://your-instance.example/api/e" />

Ajoutez des événements là où quelque chose se passe, et dites qui c’est après la connexion :

import { identify, reset, track } from "trailic";

track("signup_started", { plan: "pro" }); // chaînes, nombres, booléens, 16 au plus
identify("user_123", { plan: "pro" });    // après la connexion. Rien n'est gardé dans le navigateur avant
track("signup_completed");
reset();                                  // à la déconnexion

Envoyez depuis un gestionnaire de route ce que seul votre serveur sait :

import { trackServer } from "trailic/server";

await trackServer("payment", { amount: 49 }, { userId: "user_123" });

Passez bien ce userId. Un serveur n’a pas de visiteur : un événement envoyé sans lui n’appartient à personne, et ne peut figurer ni dans un entonnoir ni dans la rétention. Préférez un identifiant opaque à une adresse e-mail.

Décrivez ensuite l’entonnoir, à l’écran ou par le serveur MCP, en deux à huit étapes. Une ligne qui commence par une barre oblique est une page, et un * final couvre tout ce qui se trouve dessous. Le reste est un événement :

/pricing
signup_started
signup_completed
payment

La demi-heure qui fait le lien

Un entonnoir commence le plus souvent de façon anonyme et se termine connecté. Quand identify arrive, ce que le même hash a fait dans les 30 minutes précédentes devient le fait de cette personne. Suivons une visite :

Heure	Ce qui se passe	Compté comme
9 h 50	Voit `/pricing`	`user_123`, après le rattachement
9 h 58	`signup_started`	`user_123`, après le rattachement
10 h 05	`identify("user_123")`	`user_123`
10 h 06	`signup_completed`	`user_123`

Si cette personne avait lu /pricing à 9 h, cette vue resterait anonyme, et l’entonnoir commencerait pour elle à signup_started. Rapprochez donc si possible la première étape de la connexion, et ne surinterprétez pas les longues séquences anonymes.

Cette demi-heure est une limite que j’ai choisie. Un hash est partagé par tous ceux qui ont l’adresse d’un bureau et le même navigateur : deux collègues peuvent être confondus dans cette fenêtre. L’allonger en confondrait davantage.

Lire les chiffres

Un entonnoir montre combien de personnes ont atteint chaque étape, dans l’ordre. Voici le calcul, avec des chiffres inventés :

Étape	Personnes	Part de ceux qui ont commencé	Perdus depuis l’étape précédente
`/pricing`	1 000	100 %
`signup_started`	180	18 %	82 %
`signup_completed`	90	9 %	50 %
`payment`	27	2,7 %	70 %

Le 82 % a l’air le pire, mais une page tarifs sert aussi à trier. Je regarderais d’abord le 50 % : ces gens avaient déjà décidé de s’inscrire, donc quelque chose dans le formulaire les a arrêtés.

Pour la rétention, toujours avec des chiffres inventés :

Première identification, semaine du	Personnes	Semaine 0	Semaine 1	Semaine 2	Semaine 3
2 nov.	200	100 %	32 %	22 %	19 %
9 nov.	150	100 %	30 %	20 %

Lisez une ligne pour voir la courbe, une colonne pour voir si les nouvelles cohortes font mieux. Une courbe qui s’aplatit veut dire que certains restent. Choisissez un événement de retour qui traduit un vrai usage, car « n’importe quelle activité » compte aussi celui qui ouvre la page pour résilier.

Les deux lisent les événements bruts, et ne remontent donc qu’aussi loin que le site les garde : 90 jours par défaut, entre 14 et 730 par site. Le tableau va jusqu’à 26 semaines, et il faut pour cela une conservation d’au moins 182 jours.

Le côté consentement

Le mode anonyme, actif par défaut, refuse identify : coupez-le d’abord sur la page du site. L’appeler écrit alors l’identifiant dans le localStorage et rattache des événements à une personne. Partez du principe que c’est une donnée personnelle, et que cela vous fait sortir de toute exemption de consentement réservée aux statistiques anonymes : voyez la question du bandeau cookies. Une personne peut être effacée depuis sa page dans l’application, et la prop consent retient tout tant que vous ne donnez pas le feu vert. Tout cela figure sur la page fonctionnalités.

Où en est Trailic

Les entonnoirs, la rétention et les parcours fonctionnent aujourd’hui sur une instance de test, avec de vrais navigateurs, un vrai assistant et cinq millions d’événements synthétiques. Trailic n’a encore collecté aucun trafic réel, son tampon Vercel Queues n’a tourné que contre une doublure de ce service, son modèle de données peut changer et il n’existe pas de chemin de mise à jour entre versions. Il n’y a pas de version hébergée. La capture automatique des clics, le rejeu de session, les cartes de chaleur et les tests A/B ne sont pas construits : vous nommez donc chaque événement vous-même. N’en faites pas encore votre seule mesure d’audience. Le code et la spécification sont sur GitHub, et les issues sont ouvertes.