La gestion de produits fondée sur les données. C’est ce que font les personnes branchées de nos jours, n’est-ce pas ? Vous avez peut-être fait une recherche sur Google et découvert qu’être « guidé par les données » implique une utilisation intensive de l’analyse produit dans le travail quotidien de ces responsables produit.
Mais la question est la suivante : que font-ils des données analytiques ? Comment les utilisent-ils dans la vie réelle ?
Heureusement, j’ai compilé une liste de 6 cas d’utilisation de l’analyse produit pour vous inspirer.
Qu’est-ce que l’analyse produit et pourquoi devriez-vous vous en soucier ?
L’analyse produit est le processus qui consiste à recueillir des données sur votre produit numérique (notamment l’activité des utilisateurs, les données financières, etc.), à les analyser et à prendre des décisions quotidiennes ainsi que des décisions relatives à la stratégie produit en fonction de vos conclusions.
L’utilisation d’outils d’analyse produit améliore considérablement la qualité des décisions que vous prenez en tant que responsable produit, car elle vous permet d’étayer et de prouver vos idées ou solutions à l’aide de données.
En tant que données quantitatives, elles complètent également les données qualitatives que vous avez recueillies lors d’entretiens avec des clients, vous donnant ainsi une vision complète de l’état de votre produit ainsi que du comportement des clients ou des utilisateurs.
Vous pouvez activer l’analyse produit pour votre produit en configurant un outil spécialisé d’analyse produit qui surveille l’activité de vos utilisateurs et vous envoie des rapports sur les interactions des utilisateurs.
Ces outils regroupent ensuite les données relatives aux actions des utilisateurs qu’ils ont recueillies à partir de votre produit et vous permettent de créer des rapports personnalisés afin de trouver des réponses à certaines questions que vous pourriez vous poser sur l’utilisation de votre produit.
Maintenant que nous savons en quoi consiste l’analyse produit, commençons à explorer quelques cas pratiques de son application.

Exemple n° 1 : débarrasser votre interface des fonctionnalités que personne n’utilise
Les meilleurs produits ne sont pas ceux qui proposent plus de fonctionnalités que leurs concurrents. En réalité, la plupart du temps, les produits qui comportent trop de fonctionnalités deviennent difficiles à utiliser pour leurs utilisateurs et impossibles à maintenir pour leur équipe de développement produit.
Par conséquent, les excellentes équipes produit veillent à ce que leurs produits ne comportent que des fonctionnalités qui apportent de la valeur à leurs utilisateurs. Pour ce faire, vous ajouterez toujours de nouvelles fonctionnalités que vous pensez utiles pour les utilisateurs et supprimerez celles qui, vous le savez, n’ont plus de valeur.
Le dilemme évident qui se pose ensuite est de savoir comment choisir les fonctionnalités qui méritent d’être supprimées. C’est simple : vérifiez leur utilisation avec un outil d’analyse produit !
Utiliser un outil d’analyse produit fondé sur les événements, comme Mixpanel, pour faire le ménage
Pour pouvoir suivre l’utilisation d’une fonctionnalité, vous devrez configurer un événement correspondant et le déclencher chaque fois que l’utilisateur interagit avec cette fonctionnalité. En supposant que vous avez configuré ces événements pour les fonctionnalités du produit que vous souhaitez mesurer, il vous suffit de créer un rapport sur l’utilisation de cette fonctionnalité.
Illustrons cela par un exemple. Imaginez que vous dirigiez Spotify, le service de diffusion de musique que beaucoup d’entre nous utilisent, et que vous souhaitiez déterminer s’il vaut la peine de supprimer la fonctionnalité de lecture aléatoire.
Pour cela, nous allons créer un nouveau rapport Insights qui se présente ainsi.

Ici, nous avons sélectionné la fonctionnalité qui nous intéresse — « Lecture aléatoire » — ainsi que la fonctionnalité de référence (généralement l’action principale de votre produit ou votre étoile polaire) avec laquelle nous souhaitons la comparer — dans ce cas, « Diffuser une chanson ». Pour chacune d’elles, nous avons sélectionné l’option « Compter les utilisateurs actifs quotidiens » afin d’afficher le nombre d’utilisateurs uniques qui utilisent la lecture aléatoire et diffusent de la musique chaque jour.
Nous avons ensuite ajouté une formule simple qui calcule le pourcentage d’utilisateurs diffusant des chansons ayant utilisé la fonctionnalité de lecture aléatoire.
En examinant ce graphique, nous pouvons tirer 2 conclusions importantes :
- À peine 0,5 % des utilisateurs qui diffusent de la musique utilisent la fonctionnalité de lecture aléatoire.
- L’utilisation de la lecture aléatoire a régulièrement diminué, passant de 1,3 % à 0,5 % au cours du dernier mois.
Sur la base de ces statistiques d’utilisation, nous pouvons considérer la fonctionnalité de lecture aléatoire comme une candidate pertinente à la suppression afin d’alléger notre interface.
Exemple n° 2 : trouver et corriger les problèmes d’expérience utilisateur qui perturbent vos parcours de configuration ou vos parcours vers le moment « Eurêka ! »
Les premières étapes que vos utilisateurs franchissent dans votre produit auront un impact important sur leur rétention et leur valeur vie client. Du moins, c’est ce que j’ai constaté à de nombreuses reprises sur les produits que j’ai dirigés.
Toute amélioration du processus permettant aux utilisateurs de configurer votre produit et d’atteindre leur moment AHA ! se traduira à terme par un niveau de rétention plus élevé.
Pour clarifier, les utilisateurs atteignent leur moment de configuration lorsqu’ils ont effectué toutes les configurations nécessaires lors de leur inscription (par exemple, fournir les informations de leur carte bancaire et les vérifier dans une application de paiement). Le moment AHA ! correspond au point du parcours utilisateur où ils découvrent pour la première fois les bénéfices et la valeur de votre produit (par exemple, effectuer un transfert instantané avec votre application de paiement).
Il est généralement assez courant de rencontrer des problèmes d’expérience produit au cours du parcours, ce qui entraîne une diminution du nombre de personnes atteignant leurs moments de configuration et d’habitude. Mais la bonne nouvelle, c’est que vous pouvez facilement les identifier à l’aide d’un outil d’analyse ou de cartes thermiques UX comme celles-ci. Grâce à ce type de données, les équipes peuvent déterminer à quel endroit les utilisateurs abandonnent, quelles étapes créent des frictions et comment améliorer la conversion.
À lire également : Les 10 meilleurs outils de conception UX pour les développeurs de produits
Comment utiliser les entonnoirs d’analyse produit dans Heap pour résoudre les problèmes de conversion
L’un des moyens les plus pratiques de suivre et de résoudre les problèmes liés aux parcours (y compris ceux qui mènent à vos moments de configuration et AHA !) consiste à utiliser les entonnoirs. Un entonnoir est une liste d’événements placés dans un ordre précis, qui vous permet d’observer la conversion des utilisateurs d’un événement à l’autre.
Voici à quoi ressemble une analyse d’entonnoir pour une page d’inscription basique comportant un seul champ d’adresse e-mail et un bouton d’envoi.

Pour notre page d’inscription, nous suivons les événements suivants pour les utilisateurs :
- Affichage de la page d’inscription.
- Saisie de l’adresse e-mail de l’utilisateur dans le champ.
- Clic sur le bouton d’envoi.
Comme nous pouvons le constater, plus de 1 200 utilisateurs sont arrivés sur la page d’inscription. Cependant, seuls 17 % de ces 1 200 utilisateurs ont renseigné leur adresse e-mail, et 90 % de ceux qui l’ont renseignée ont cliqué sur le bouton d’envoi.
Cet entonnoir nous indique qu’il y a un problème avec le champ d’adresse e-mail et que nous devons rechercher précisément de quoi il s’agit.
Pour cela, nous pouvons soit effectuer des tests d’utilisabilité de notre écran d’inscription, soit consulter la rediffusion de session de Heap, qui est un enregistrement vidéo en temps réel des interactions de l’utilisateur avec votre produit.
Dans le cas du champ d’adresse e-mail, vous pourriez découvrir que la validation de l’adresse est frustrante et que vos utilisateurs abandonnent après avoir essayé de saisir leur adresse e-mail à plusieurs reprises.
Exemple n° 3 : mesurer l’impact d’une fonctionnalité lors de son déploiement progressif
Combien de fois avez-vous ajouté à votre produit une nouvelle fonctionnalité attrayante qui s’est révélée être un échec total (c’est-à-dire qu’elle n’a pas amélioré l’utilisation, voire qu’elle lui a nui) ? Cela est arrivé au moins quelques fois, même aux PM les plus talentueux.
Comme nous ne savons pas toujours si la fonctionnalité que nous avons créée réussira ou échouera, il est judicieux de la déployer auprès d’un petit nombre d’utilisateurs, de vérifier s’ils l’utilisent (et si elle améliore vos indicateurs clés, comme la rétention ou la valeur vie client), puis, en supposant qu’elle ait été un succès, de la déployer auprès de tous les autres utilisateurs.
Vous pouvez effectuer à la fois le déploiement progressif et la mesure de l’impact avec une solution spécialisée d’analyse produit qui comprend des fonctionnalités essentielles de logiciel d’analyse, comme Amplitude.
Configurer et mener des expérimentations avec un logiciel avancé d’analyse produit comme Amplitude
Amplitude propose une fonctionnalité avancée appelée Expérimentations. Vous pouvez l’utiliser pour réaliser des tests A/B ou effectuer des déploiements progressifs de fonctionnalités. Je n’entrerai pas dans les détails de la création d’une expérimentation, car ce sera le sujet d’un autre article, mais vous pouvez consulter la documentation proposée par Amplitude pour sa fonctionnalité, qui décrit tout, de la messagerie API aux intégrations, en passant par les notifications et la tarification.
Imaginons maintenant que vous ayez ajouté un guide vidéo dans le cadre de l’intégration à votre produit et que vous souhaitiez augmenter le nombre de personnes qui cliquent sur le bouton de lecture et regardent la vidéo. Pour cela, vous avez conçu deux solutions dans lesquelles la vidéo apparaît à deux endroits différents de l’intégration.
Pour comprendre si vos solutions fonctionnent (et laquelle fonctionne le mieux), nous pouvons mettre en place une expérimentation avec un déploiement partiel de 25 % pour la variante A et de 25 % pour la variante B.

Lorsque nous commençons cette expérimentation et que nous la laissons fonctionner pendant un certain temps afin d’obtenir des données statistiquement significatives sur les utilisateurs, voici ce que nous observons.

Le graphique ci-dessus représente un entonnoir de conversion, de la visite de la page d’accueil au démarrage de la vidéo. Comme nous pouvons le voir, la variante A est la gagnante et elle permet d’optimiser la conversion jusqu’au démarrage de la vidéo de 3,4 %.
Selon la situation, vous pourriez considérer cela comme une réussite ou un échec. Pour un taux de conversion lié à l’ouverture de la vidéo, je dirais qu’il s’agit d’un échec et que cela ne vaut pas la peine de déployer cette variante auprès de tout le monde. En revanche, si le résultat d’une expérimentation était une augmentation de 3,4 % de la rétention, ce serait une réussite importante.
Exemple n° 4 : surveiller la santé du produit
Les produits sont des organismes vivants qui peuvent être en bonne santé ou tomber « malades ». Pour vous assurer d’être toujours au fait de la santé de votre produit et de pouvoir identifier et résoudre tout problème qui l’affecte, vous devrez surveiller le « battement de cœur » de votre produit sous la forme d’un tableau de bord de santé du produit.
Grâce à votre suivi, vous pourriez remarquer des baisses ou des pics dans les principales métriques du produit et les KPI, comme les WAU ou l’adhérence, qui nécessitent une analyse, ou constater que l’engagement de vos utilisateurs diminue progressivement, ce qui indique que votre produit a besoin d’un renouvellement.
Heureusement, un tableau de bord de santé du produit est quelque chose que vous pouvez créer facilement à l’aide de n’importe quel outil de veille stratégique (par exemple, Mixpanel ou Amplitude).
Suivre les principales métriques du produit avec Mixpanel
Les tableaux de bord de Mixpanel se composent de plusieurs rapports associés que vous placez côte à côte. Pour un tableau de bord de santé du produit, vous pouvez envisager de créer les rapports suivants :
- DAU, WAU ou MAU pour votre action principale (par exemple, écouter une chanson en continu sur Spotify). Votre choix entre ces trois indicateurs dépend de la fréquence naturelle de l’action principale. Pour l’écoute de chansons en continu, elle sera quotidienne ; votre choix se portera donc sur les DAU.
- Adhérence (DAU/WAU, WAU/MAU, etc.). Elle indiquera le pourcentage d’utilisateurs engagés qui reviennent sur votre produit.
- Inscriptions au fil du temps et conversions du gratuit vers le payant au fil du temps. Vous devez surveiller ces deux indicateurs et vous assurer qu’ils progressent progressivement.
- Attrition. Il s’agit du nombre d’utilisateurs que vous avez perdus sur une période donnée. Une augmentation de cet indicateur devrait vous inquiéter.
- Rétention. Elle représente le nombre d’utilisateurs qui sont restés avec vous après une durée déterminée (par exemple, 90 jours).
Voici à quoi ressemble généralement un tableau de bord de santé du produit dans Mixpanel.

Vous pouvez ajouter à votre tableau de bord tous les autres rapports qui représentent la santé de votre produit.
Exemple n° 5 : décider de mettre en production ou non une version lorsque votre équipe d’assurance qualité a découvert un problème grave dans la version
L’une des décisions les plus difficiles que nous devons prendre consiste à donner le feu vert à la mise en production d’une version. C’est difficile, car les versions sont presque jamais exemptes de bugs. Les choses se compliquent encore lorsque nous découvrons un bug susceptible de nuire à l’expérience de vos clients.
Mais pourquoi est-ce compliqué ? Si vous avez un bug grave, vous devez d’abord le corriger avant de publier la version, n’est-ce pas ? Imaginez que vous découvriez qu’il faudra encore une semaine à votre équipe pour le corriger, alors que votre équipe marketing a déjà pris des engagements et effectué des préparatifs qu’il serait difficile d’annuler.
Dans cette situation, vous avez deux choix :
- Donner le feu vert à la mise en production et faire face aux conséquences du bug grave.
- Fournir à votre équipe marketing un argument solide pour expliquer pourquoi elle devrait reporter le lancement.
Les deux options semblent mauvaises. Mais ne vous inquiétez pas : il est possible que le bug en question ait un impact bien plus faible que vous ne l’imaginiez et que vous puissiez mettre la version en production sans conséquences majeures.
Pour mesurer l’impact d’un bug, nous pouvons utiliser les données de notre plateforme d’analyse du produit.
Utiliser Google Analytics pour calculer l’impact d’un bug
Imaginez que vous ayez un bug qui provoque des plantages occasionnels de votre application mobile sur Android 6.0.1 et qui perturbe complètement le parcours de vos clients. Pour comprendre l'impact de ce bug, nous devons connaître le nombre d'utilisateurs disposant de cette version d'Android.
Heureusement, en plus des données d'utilisation, Google Analytics est également capable de collecter et de stocker des données sur les aspects techniques de nos utilisateurs, comme le type de leur appareil, la version de leur système d'exploitation, la taille de leur écran, etc.
Si nous ouvrons donc son rapport « Détails techniques » et sélectionnons l'option « Système d'exploitation avec version », nous constaterons que seulement 1,2 % de l'ensemble des utilisateurs utilisent Android 6.0.1.

Bien que ces données constituent déjà un indicateur nous permettant de donner le feu vert à la mise en production, nous pouvons aller plus loin et également calculer l'impact financier potentiel en vérifiant les revenus générés par les utilisateurs d'Android 6.0.1.
Si nous comparons le revenu total entre « tous les utilisateurs » et les « utilisateurs d'Android 6.0.1 », nous observerons ce qui suit.

Apparemment, les utilisateurs qui subiront des plantages après la mise en production ne génèrent aucun revenu pour nous. Nous n'aurons donc aucune conséquence financière à mettre en production la version comportant ce bug. Bonus !
Exemple n° 6 : identifier les cohortes d'utilisateurs qui méritent vos efforts marketing
Tous vos utilisateurs ne se valent pas. Certains seront des utilisateurs intensifs qui représentent la majeure partie de l'utilisation de votre produit (ainsi que la majorité de vos revenus), tandis que d'autres resteront inactifs, avec peu d'espoir de les impliquer et de les monétiser.
Naturellement, vous aimeriez tous identifier les utilisateurs susceptibles de vous rapporter le plus de revenus et concentrer vos efforts marketing sur eux. Mais comment faire ?
Vous pouvez exploiter les données analytiques de votre produit en identifiant différentes cohortes d'utilisateurs et en comparant leurs principaux indicateurs d'utilisation et de monétisation.
Analyse des cohortes avec Amplitude
Les cohortes sont des groupes d'utilisateurs qui partagent une caractéristique commune. Vous pouvez créer des cohortes en fonction des éléments suivants :
- Plateforme (par exemple, les utilisateurs de Mac et de Windows). J'ai eu un produit pour lequel la LTV des utilisateurs de Mac était supérieure de 30 % à celle des utilisateurs de Windows.
- Zone géographique (par exemple, les utilisateurs de France et de Grèce). Selon le produit, celui-ci peut être bien monétisé dans certains pays et sous-performer dans d'autres.
- Date d'inscription (par exemple, les utilisateurs inscrits en novembre et en janvier). Imaginez que votre campagne du Black Friday ait connu un immense succès. Vous avez ciblé les bonnes personnes et votre cohorte de novembre affiche une LTV bien plus élevée que celle des autres mois.
- Comportement des utilisateurs ou utilisation de certaines fonctionnalités (par exemple, les utilisateurs qui mélangent les chansons et ceux qui ne le font pas). Lors de la création d'une fonctionnalité, vous souhaitez vraiment que ses utilisateurs affichent un meilleur engagement et une meilleure LTV. Dans le cas contraire, la fonctionnalité n'a pas été un succès et il peut être préférable de la supprimer.
Créons maintenant quelques cohortes dans Amplitude et comparons-les.
Imaginez que vous souhaitiez déterminer s'il vaut la peine d'investir dans le marketing au Japon. Nous pouvons créer une cohorte d'utilisateurs japonais dans Amplitude comme ceci.

Nous pouvons ensuite comparer la fréquence des achats des utilisateurs japonais à celle de tous les autres utilisateurs.

Comme nous pouvons le constater, les utilisateurs japonais effectuent davantage d'achats que le taux moyen. Il vaut donc la peine de demander à votre équipe marketing de cibler le Japon.
Pour résumer
Les analyses de produit vous facilitent la vie en tant que responsable produit en vous permettant de prendre des décisions de conception fondées sur les données plutôt que de vous fier uniquement à votre intuition et à votre instinct.
Prendre des décisions éclairées fondées sur les données analytiques est une excellente chose, mais vous ne devriez pas vous arrêter là. Parmi les autres outils précieux que vous pouvez utiliser pour devenir un meilleur responsable produit, citons :
- Boucles de rétroaction des clients pour s'assurer que tout le monde entende la voix de vos clients.
- Maquettes de produit pour faire évoluer rapidement votre conception, sans tracas.
- PRDs pour aligner tout le monde sur les détails de mise en œuvre de la fonctionnalité, et bien plus encore.
- Formations en analytique produit qui sont des ressources précieuses et à fort retour sur investissement pour vous rendre plus efficace dans votre rôle.
En plus de lire ces guides, vous pouvez également vous abonner à notre newsletter et nous laisser vous envoyer directement dans votre boîte de réception toutes sortes de ressources utiles sur la gestion de produit !
