Product analytics : définition, usages et plan de taggage

Le product analytics, ou analytics produit, est la discipline qui consiste à mesurer les actions réellement effectuées par les utilisateurs à l’intérieur d’un produit numérique — un clic, un écran affiché, une fonctionnalité déclenchée — afin de comprendre comment ce produit est utilisé. On parle aussi d’analyse produit ou d’analyse comportementale produit.

Son objectif n’est pas de produire des tableaux de bord, mais d’éclairer des décisions : quelle fonctionnalité mérite d’être approfondie, laquelle est ignorée, à quelle étape un parcours se casse. Il se distingue en cela du web analytics, centré sur la fréquentation d’un site, et il partage avec lui une limite absolue : il décrit des comportements, il n’en explique jamais les raisons.

C’est de cette limite que découle la principale erreur de mise en place. Voyons ce que le product analytics mesure exactement, ce qu’il ne mesurera jamais, et pourquoi le plan de taggage constitue le vrai livrable d’une installation réussie.

Qu’est-ce que le product analytics ? Définition

Le product analytics repose sur un mécanisme unique : chaque action jugée significative est enregistrée sous forme d’événement, c’est-à-dire une ligne de données horodatée indiquant qui a fait quoi, quand et dans quel contexte. Un compte créé, un fichier importé, un filtre appliqué, un export lancé, un abonnement résilié : autant d’événements, chacun accompagné de propriétés qui le qualifient — le type de compte, l’appareil utilisé, la valeur du panier.

Cette granularité change la nature de ce qu’on peut observer. Là où un rapport de fréquentation donne des volumes agrégés, le product analytics permet de suivre un même utilisateur d’une semaine sur l’autre, de reconstituer son parcours réel et de comparer des groupes entre eux. C’est ce qui en fait l’instrument de mesure privilégié des équipes produit, au même titre que la product discovery l’est pour la compréhension des besoins.

Une précision de vocabulaire s’impose ici, car la confusion est constante dans les contenus francophones : le product analytics n’est pas une version renommée du web analytics. Les deux collectent des événements, mais ils ne répondent pas aux mêmes questions et ne s’adressent pas aux mêmes équipes.

Product analytics et web analytics : quelle différence ?

Le web analytics mesure la fréquentation d’un site : sessions, pages vues, sources de trafic, taux de conversion. Son unité d’analyse est la page et la visite, son horizon est la campagne. Le product analytics mesure l’usage d’un produit : son unité d’analyse est l’utilisateur identifié et l’action qu’il déclenche, son horizon est le cycle de vie du compte. Le premier répond surtout aux questions d’acquisition, le second aux questions d’usage et de fidélisation.

	Web analytics	Product analytics
Objet mesuré	la fréquentation d’un site	l’usage d’un produit
Unité d’analyse	la session et la page	l’utilisateur identifié et l’action
Horizon de temps	la visite, la campagne	le cycle de vie du compte
Question type	d’où viennent les visiteurs ?	qui utilise cette fonctionnalité, et y revient-il ?
Utilisateurs internes	marketing, acquisition	équipe produit, design, support

Les deux disciplines sont complémentaires et cohabitent très bien : elles deviennent problématiques uniquement lorsqu’on demande à l’une de répondre aux questions de l’autre, par exemple lorsqu’on tente d’évaluer la rétention d’un logiciel avec un outil conçu pour compter des visites.

Le quoi, jamais le pourquoi

Voici la propriété la plus importante du product analytics, et celle qu’on oublie le plus vite une fois l’outil branché : la donnée comportementale décrit, elle n’explique pas. Elle établit qu’une part importante des utilisateurs abandonne un formulaire à la troisième étape. Elle ne dira jamais si c’est par méfiance, par incompréhension d’un libellé, parce que l’information demandée n’est pas disponible à ce moment-là, ou parce qu’un collègue est passé dans le bureau.

La distinction n’a rien de nouveau : en recherche utilisateur, le Nielsen Norman Group résume les méthodes quantitatives par la question « combien ? » et les méthodes qualitatives par la question « pourquoi ? ». Le product analytics appartient sans ambiguïté à la première famille. Il excelle à repérer où regarder ; il est structurellement incapable de dire quoi en conclure.

Les plateformes ajoutent souvent un replay de session, c’est-à-dire un rejeu vidéo du parcours d’un utilisateur, ainsi que des cartes de chaleur. Ces formats donnent l’illusion de l’explication, parce qu’on voit littéralement l’hésitation à l’écran. Ils restent pourtant de l’observation : on regarde une main hésiter sans entendre la pensée. Ils resserrent l’hypothèse, ils ne la valident pas.

Le pourquoi vient d’ailleurs — de l’entretien, du retour client, des verbatims collectés auprès du support, de ce qu’on regroupe sous le terme de voice of customer. Le bon réflexe consiste à traiter chaque anomalie observée comme une question à poser, pas comme un diagnostic. C’est l’erreur que je vois se répéter le plus souvent : une courbe qui décroche, et une réunion entière passée à en inventer collectivement la cause sans avoir parlé à un seul utilisateur.

La symétrie de cette erreur porte un nom : les vanity metrics, ces indicateurs qui montent toujours et ne déclenchent jamais aucune décision. Un outil de product analytics mal cadré en produit industriellement, parce qu’il rend facile de compter des clics et difficile de définir ce qu’un usage réussi signifie.

Que mesure-t-on concrètement ?

Quel que soit l’outil, le répertoire d’analyses standard est étonnamment stable. Quatre familles couvrent l’essentiel des besoins d’une équipe produit, et il est rare d’avoir besoin d’autre chose pendant la première année.

• L’entonnoir de conversion — une suite d’étapes ordonnées dont on mesure le passage. Il montre où les utilisateurs se perdent, pas pourquoi. C’est l’analyse la plus rentable et la plus facile à mal interpréter, car un entonnoir mal découpé fabrique des chutes qui n’existent pas.
• La rétention — la part d’utilisateurs encore actifs après un délai donné. Le taux de rétention est l’indicateur qui dit si le produit possède un usage récurrent ; sa lecture par cohortes et son calcul méritent un traitement à part entière. C’est le miroir du taux de churn.
• L’adoption d’une fonctionnalité — combien d’utilisateurs éligibles l’ont découverte, essayée, puis réutilisée. Les trois chiffres racontent des histoires différentes : une découverte faible est un problème de visibilité, une réutilisation faible un problème de valeur.
• L’analyse de parcours — la reconstitution des chemins réellement empruntés, souvent très éloignés de ceux imaginés en conception. C’est l’analyse qui surprend le plus, et celle qui alimente le mieux les entretiens suivants.

Les métriques qui gravitent autour

Le product analytics alimente des indicateurs qui, eux, ne sont pas comportementaux mais économiques ou déclaratifs. La customer lifetime value se nourrit des durées de vie observées ; le Net Promoter Score se croise utilement avec l’usage réel, un promoteur qui n’ouvre jamais le produit étant un signal en soi. L’intérêt de l’outil tient largement à cette capacité de croisement.

Mesurer une fonctionnalité avant de la généraliser

Le cas le plus démonstratif reste la mise en service progressive. Imaginons une équipe qui déploie un nouveau tunnel de commande sur une fraction de ses utilisateurs à l’aide d’un feature flag : sans instrumentation posée avant l’activation, la comparaison entre le groupe exposé et les autres est impossible, et la décision de généraliser se prend au ressenti. L’instrumentation n’est pas une étape postérieure à la livraison, c’est une partie de la livraison.

Le plan de taggage, le vrai livrable

Le plan de taggage, ou plan de marquage, est le document — le plus souvent un simple tableur — qui recense les événements à collecter et la manière exacte de les collecter. C’est lui, et non l’outil, qui détermine la qualité de tout ce qui suivra. Un outil sans plan de taggage produit un flux de données ininterprétable ; un plan de taggage rigoureux reste exploitable même si l’on change d’outil.

Pour chaque événement, le document précise au minimum :

• le nom technique exact, celui qui apparaîtra dans l’outil pour toujours ;
• la question à laquelle il sert à répondre — s’il n’y en a pas, l’événement ne doit pas exister ;
• le déclencheur précis : au clic, à l’affichage, à la réponse du serveur — trois moments qui donnent trois chiffres différents ;
• les propriétés associées et leurs valeurs autorisées ;
• le responsable de l’événement, côté produit et côté technique.

La nomenclature n’est pas un détail cosmétique

Une convention de nommage tenue dès le premier jour évite la dérive qui rend la plupart des installations inexploitables au bout de deux ans. Les contraintes techniques sont d’ailleurs strictes : dans Google Analytics 4, un nom d’événement doit commencer par une lettre, ne contenir que des lettres, des chiffres et des tirets bas, et il reste sensible à la casse — panier_valide et Panier_Valide désignent donc deux événements distincts, ce qui suffit à couper une série de mesures en deux.

• Un format unique : objet puis action, au même temps grammatical, par exemple commande_validee et filtre_applique.
• Des propriétés plutôt que des événements multipliés : un seul export_lance avec une propriété format vaut mieux que trois événements distincts.
• Un vocabulaire aligné sur le produit, pas sur l’écran : les écrans changent, les objets métier restent.
• Aucune donnée personnelle dans les noms ni dans les valeurs.

Pourquoi l’historique ne se rattrape jamais

C’est le point qui justifie tout le soin apporté en amont. Une donnée non collectée n’existe nulle part : elle n’est pas stockée en attente d’être activée, elle n’a simplement jamais été produite. Le jour où l’on s’aperçoit qu’un événement manquait, on peut le poser, mais la mesure démarre à cette date. Il n’existe aucun moyen de reconstituer les mois écoulés.

Le cas d’un événement mal nommé ou mal déclenché est pire encore, car il produit un chiffre plausible et faux. Le renommer dans l’interface ne réécrit pas le passé : on se retrouve avec deux séries qu’il faut raccorder à la main, et une rupture dans la courbe que plus personne ne saura expliquer dix-huit mois plus tard.

Les modalités exactes dépendent de la configuration retenue et méritent d’être vérifiées auprès des recommandations de la CNIL sur les outils de mesure d’audience, en particulier lorsque le produit croise ses données d’usage avec d’autres traitements.

Choisir un outil de product analytics

L’ordre habituel est inversé. On choisit une plateforme, on l’installe, puis on cherche ce qu’on pourrait bien en tirer. La séquence utile commence par la décision à prendre : quelle question, posée par qui, entraînant quel arbitrage. Un outil de product analytics ne crée aucune information, il rend accessible celle qu’on a pris la peine de définir.

Trois questions se tranchent avant de comparer quoi que ce soit :

1. Quelle décision doit changer grâce à la mesure ? Une roadmap arbitrée autrement, une fonctionnalité retirée, un parcours refondu. Sans décision identifiée, la mise en place produira des tableaux de bord consultés trois semaines.
2. Les utilisateurs sont-ils identifiés ? Un produit connecté permet de suivre un compte dans la durée ; un site public ne le permet pas dans les mêmes termes, ce qui change radicalement les analyses envisageables.
3. Qui maintiendra le plan de taggage ? C’est le critère le plus déterminant et le moins regardé. Un plan sans propriétaire se dégrade en quelques mois, quelle que soit la plateforme.

Le marché se répartit en deux familles. D’un côté les outils de web analytics généralistes, orientés trafic et acquisition. De l’autre les plateformes dédiées à l’usage produit, qui savent nativement raisonner par utilisateur, par cohorte et par entonnoir : Pendo, Amplitude, Mixpanel, Heap, PostHog ou Contentsquare figurent parmi les plus répandues, citées ici par ordre alphabétique et sans intention de classement. Je n’en propose délibérément aucun, parce que le facteur limitant n’est presque jamais la richesse fonctionnelle de l’outil : c’est la capacité de l’équipe à tenir son plan de taggage dans la durée.

Reste à ancrer la mesure dans le pilotage. Des objectifs formulés en résultats, sous forme d’OKR par exemple, donnent au plan de taggage sa raison d’être : chaque événement collecté doit servir à savoir si un résultat attendu progresse. S’il ne sert qu’à alimenter une case de tableau de bord, il n’a probablement pas besoin d’exister.

S’il fallait retenir une seule règle, ce serait celle-ci : écrivez la question avant d’écrire l’événement. Une installation de product analytics réussie ne se reconnaît pas au nombre de données collectées, mais au nombre de décisions qu’elle a permis de trancher — et, plus rarement encore, au nombre de fonctionnalités qu’elle a permis d’abandonner.

FAQ — Tout savoir sur le product analytics

Quelle est la différence entre le product analytics et Google Analytics ?

Google Analytics relève historiquement du web analytics : il mesure la fréquentation d’un site, ses sources de trafic et ses conversions, à l’échelle de la session. Le product analytics mesure l’usage d’un produit à l’échelle de l’utilisateur identifié et dans la durée, ce qui permet les analyses de rétention, de cohortes et d’adoption de fonctionnalités.

Quels sont les outils de product analytics ?

Les plateformes les plus répandues sont Amplitude, Contentsquare, Heap, Mixpanel, Pendo et PostHog, citées par ordre alphabétique. Elles partagent le même socle d’analyses : entonnoirs, rétention, cohortes, parcours. Le choix se joue moins sur les fonctionnalités que sur la capacité de l’équipe à maintenir un plan de taggage propre.

Qu’est-ce qu’un plan de taggage ?

C’est le document qui recense les événements à collecter dans un produit et la manière de les collecter : nom technique exact, question à laquelle l’événement répond, déclencheur, propriétés associées et responsable. Il constitue le véritable livrable d’une mise en place de product analytics, davantage que l’outil lui-même.

Peut-on récupérer les données d’un événement oublié ?

Non. Une donnée non collectée n’a jamais été produite : elle n’attend nulle part d’être activée. Poser l’événement plus tard fait démarrer la mesure à cette date, sans reconstitution possible du passé. C’est ce qui rend la phase de cadrage aussi déterminante.

Le product analytics remplace-t-il les entretiens utilisateurs ?

Non, il les rend plus utiles. La mesure comportementale indique où regarder et sur quel segment ; l’entretien explique ce qui s’y passe. Employer l’un sans l’autre conduit soit à des chiffres sans interprétation, soit à des interprétations sans preuve d’ampleur.

Faut-il le consentement des utilisateurs pour mesurer l’usage ?

Cela dépend de l’usage fait des données. La CNIL prévoit une exemption de consentement pour les seuls outils de mesure d’audience produisant des statistiques anonymes pour le compte exclusif de l’éditeur, sans recoupement ni suivi entre plusieurs sites. Dès que ces conditions ne sont plus réunies, le consentement redevient nécessaire.

Par où commencer quand rien n’est encore mesuré ?

Par une seule question de décision, traduite en trois à cinq événements nommés selon une convention écrite. Un plan de taggage court et tenu vaut mieux qu’un plan exhaustif abandonné au bout d’un trimestre : les événements suivants s’ajoutent ensuite au rythme des questions réellement posées.