Comment l'analyse produit suit les utilisateurs, pas les pages vues

Qu'est-ce que l'analyse produit ?

Un système d'analyse produit mesure ce que les gens font à l'intérieur d'un produit, événement par événement et utilisateur par utilisateur, pour que le comportement se suive d'une session à l'autre au lieu d'être compté par visite. L'unité d'analyse est la personne et l'ordre de ses actions, pas la page qu'elle a chargée. Décidez quelles actions dans votre produit ont un sens business, puis enregistrez chacune d'elles avec un identifiant utilisateur stable.

Ce changement d'unité, c'est toute la catégorie. Un rapport de pages vues peut vous dire que 12 000 personnes ont vu la page d'inscription. Seul un flux d'événements peut vous dire que 3 400 d'entre elles ont créé un compte, que 900 ont terminé la configuration lors d'une deuxième visite quatre jours plus tard, et que 210 sont revenues en semaine trois. La deuxième réponse exige une identité qui survit à la frontière de session. La première non.

À quoi ressemble un événement d'analyse produit ?

Chaque événement porte quatre parties : un nom, un ensemble de propriétés, un id utilisateur et un horodatage. Le nom dit ce qui s'est passé, les propriétés disent dans quelles conditions, l'id utilisateur relie l'événement à tout ce que cette personne a fait par ailleurs, et l'horodatage place l'action dans la séquence. Écrivez les noms comme un objet suivi d'un verbe au passé, figez-les à la release et versionnez le schéma au lieu de renommer.

{
  "event": "project_created",
  "user_id": "u_8f2c11",
  "timestamp": "2026-09-08T14:22:05Z",
  "properties": {
    "plan": "team",
    "template_used": true,
    "seats": 4,
    "source": "onboarding_checklist"
  }
}

Les propriétés, c'est là que la plupart des équipes perdent un an. Une propriété plan ajoutée six mois après le lancement n'a aucun historique derrière elle, donc toute cohorte plus ancienne que six mois devient inutilisable pour ce découpage. Ajoutez les propriétés selon lesquelles vous comptez segmenter le jour où vous livrez l'événement.

Faut-il utiliser l'autocapture ou l'instrumentation manuelle ?

Utilisez les deux, avec des rôles différents : l'autocapture pour la couverture, l'instrumentation manuelle pour les événements sur lesquels vous reportez. L'autocapture enregistre les clics, les pages vues, les envois de formulaire et les interactions avec les éléments depuis un seul script, ce qui permet de poser des questions rétroactives sur des actions que personne n'avait pensé à définir. L'instrumentation manuelle déclenche un événement nommé depuis votre propre code au moment où la logique métier réussit vraiment.

La distinction compte au point de vérité. Un clic autocapturé sur un bouton libellé "Créer un projet" signifie que quelqu'un a appuyé sur un bouton. Un événement manuel project_created déclenché après confirmation de l'écriture par le serveur signifie qu'un projet existe. Quand la requête échoue, ces deux nombres divergent, et c'est le manuel qui est juste.

Définissez dix à vingt événements manuels couvrant l'inscription, l'activation, les actions de valeur centrales, l'upgrade et la résiliation. Laissez l'autocapture couvrir tout le reste.

À quelles questions l'analyse produit répond-elle quand l'analyse web ne le peut pas ?

L'analyse produit répond à cinq familles de questions qui exigent identité et séquence : activation, rétention, entonnoirs, cohortes et parcours. L'analyse web compte ce qui est arrivé ; l'analyse comportementale compte ce que les gens ont fait ensuite, puis encore ensuite.

L'activation demande si un nouvel utilisateur a atteint le moment où le produit commence à fonctionner pour lui. La rétention demande s'il est revenu, et comment cela décroît semaine après semaine, ce qui est la forme qu'expose une courbe de taux de rétention. Les entonnoirs demandent quelle étape ordonnée perd les gens. L'analyse de cohortes demande si les utilisateurs inscrits en mars se comportent autrement que ceux inscrits en août, et c'est ainsi que vous distinguez un changement produit d'un effet saisonnier. Les parcours demandent ce que les gens ont réellement fait au lieu de la route que vous aviez dessinée.

Chacune de ces questions exige de relier des événements entre plusieurs visites. Aucune ne se répond depuis un rapport limité à la session.

Comment l'analyse produit se compare-t-elle à l'analyse web ?

Les deux disciplines diffèrent par l'unité qu'elles comptent, et tout le reste en découle. L'analyse web mesure le trafic qui atteint un site ; l'analyse produit mesure le comportement à l'intérieur d'une application.

Aucune ne remplace l'autre. L'analyse web vous dit qu'une campagne payante a livré 4 000 visites ; l'analyse produit vous dit que ces 4 000 visites ont produit 90 comptes activés et que la campagne perd de l'argent.

Comment calcule-t-on le taux d'activation ?

Le taux d'activation est la part des nouveaux inscrits qui atteignent l'événement que vous avez défini comme "le produit fonctionne". Choisissez un événement, gardez-le fixe et donnez-lui une fenêtre de temps pour que les activations lentes ne faussent pas le nombre.

Activation rate = (users who fired the activation event within N days / new signups in the period) x 100

Prenez 4 000 inscriptions en août avec une fenêtre de 7 jours et project_created comme événement d'activation. Si 1 120 de ces inscriptions ont déclenché cet événement dans les sept jours suivant l'inscription, le taux d'activation vaut 1 120 / 4 000 x 100 = 28 pour cent.

Le nombre seul est inerte. Découpez le chemin en étapes ordonnées avec l'analyse d'entonnoir et les 72 pour cent qui n'ont pas activé se résolvent en abandons nommés : 900 n'ont jamais vérifié leur e-mail, 1 400 ont vérifié mais n'ont jamais ouvert l'éditeur, 580 ont ouvert l'éditeur et se sont arrêtés au sélecteur de modèles.

Où s'arrête l'analyse produit et où commence le session replay ?

L'analyse produit vous dit quelle étape a perdu des utilisateurs et combien ; le session replay, la relecture de vraies sessions utilisateurs, montre pourquoi cette étape a échoué pour une personne précise. Le flux d'événements est agrégé et quantitatif, il peut donc classer les problèmes par taille mais ne peut pas montrer le bouton mal libellé, l'erreur de validation que personne ne lit, ou le contrôle qui semble désactivé.

Ce passage de relais est tout l'intérêt. Une fois qu'un entonnoir nomme l'étape où 1 400 utilisateurs se sont arrêtés, regarder les sessions à partir de cette étape exacte transforme un nombre en cause. Flowsery enregistre chaque session utilisateur et détecte automatiquement les rage clicks, les dead clicks, les erreurs JavaScript, les abandons et les parcours cassés, puis regroupe les sessions similaires en un seul problème et classe les problèmes selon le nombre d'utilisateurs touchés. Chaque problème arrive dans Slack, Linear ou Jira avec la relecture et les étapes de reproduction jointes.

Lancez l'analyse produit pour trouver l'étape. Lancez le session replay pour trouver la cause. Livrez le correctif, puis surveillez la même étape d'entonnoir pour confirmer que le nombre a bougé.

Questions fréquentes

L'analyse produit est-elle la même chose que l'analyse web ?

Non. L'analyse web compte les sessions et les pages vues de visiteurs anonymes, et le compteur se remet à zéro à la fin de la visite. L'analyse produit attache un id utilisateur persistant à chaque événement, si bien que les actions d'une même personne se relient entre sessions et appareils en un seul parcours.

Combien d'événements un produit doit-il suivre ?

Dix à vingt événements instrumentés à la main couvrent la plupart des produits : inscription, activation, les deux ou trois actions de valeur centrales, invitation, upgrade et résiliation. L'autocapture prend en charge la longue traîne des clics et des pages vues sans code supplémentaire. Un plan de tracking avec 200 événements écrits à la main devient impossible à maintenir et plus personne ne fait confiance aux noms.

Quelle est la différence entre un événement et une propriété ?

Un événement est l'action elle-même, comme project_created. Une propriété est un champ attaché à cette action qui décrit les conditions, comme plan: team ou template_used: true. Les événements sont ce que vous comptez ; les propriétés sont la façon dont vous découpez ce compte.

L'analyse produit peut-elle fonctionner sans comptes utilisateurs ?

En partie. Les ids anonymes stockés dans le navigateur permettent de relier les événements au sein d'un même navigateur, ce qui suffit pour les entonnoirs et les parcours sur un seul appareil. Les parcours multi-appareils et les vraies courbes de rétention exigent une identité que vous fixez à la connexion, pour que les ids anonymes soient fusionnés dans le compte quand la personne se connecte.

L'analyse produit demande-t-elle une modification du code ?

L'autocapture fonctionne avec une seule balise de script, sans code par événement. Les événements sur lesquels vous reportez, comme l'activation et l'upgrade, demandent une ligne de code à l'endroit où la logique métier réussit, parce que seul votre serveur sait si l'action s'est vraiment terminée.

Quand une équipe doit-elle ajouter l'analyse produit ?

Ajoutez-la dès que le produit a un moment d'activation défini et assez d'inscriptions pour que les schémas d'abandon soient visibles plutôt qu'anecdotiques. Avant cela, instrumentez quand même les événements d'inscription et d'activation, car les questions de rétention et de cohortes ne se répondent qu'avec l'historique que vous avez déjà collecté.

Comment faut-il nommer les événements en analyse produit ?

Nommez chaque événement comme un objet suivi d'un verbe au passé, par exemple project_created. Figez le nom dès la mise en production de l'événement, puis versionnez le schéma pour tout changement plutôt que de renommer l'événement. Seul un nom stable permet de compter et de comparer dans le temps.

Pourquoi ajouter une propriété tardivement pose-t-il problème ?

Une propriété ajoutée des mois après le lancement d'un événement n'a aucun historique derrière elle, donc tout ce qui a été enregistré avant cette date ne peut pas être segmenté avec elle. Une propriété plan ajoutée six mois après le lancement, par exemple, rend inutilisable pour ce découpage toute cohorte de plus de six mois. Ajoutez les propriétés que vous prévoyez d'utiliser pour segmenter le jour même où l'événement est lancé, pas plus tard.

Pourquoi un clic capturé par autocapture peut-il surcompter les actions réelles ?

L'autocapture enregistre uniquement le clic lui-même, donc un bouton intitulé "Create project" pressé est tout ce qu'elle peut confirmer. Un événement manuel project_created ne se déclenche qu'après que le serveur confirme l'écriture, donc quand une requête échoue, les deux chiffres divergent. Le chiffre manuel est le bon pour tout ce que vous reportez.

Que peut montrer le session replay que l'analyse produit ne peut pas montrer ?

L'analyse produit est agrégée et quantitative, elle peut donc classer quelle étape d'un funnel perd le plus d'utilisateurs, mais pas expliquer pourquoi. Le session replay montre la cause précise : un bouton mal étiqueté, une erreur de validation que personne ne lit, ou un contrôle qui semble désactivé. Le déroulé habituel utilise l'analyse produit pour trouver l'étape, puis le session replay pour trouver la cause à cette étape exacte.