Comment mesurer l'adoption d'une feature

Le taux d’adoption d’une feature est la proportion d’utilisateurs éligibles qui l’utilisent réellement. La formule est simple — les adoptants divisés par la population susceptible de l’adopter — mais le chiffre n’a aucun sens tant que vous n’avez pas fixé trois choses : qui compte comme éligible (la largeur), à quelle profondeur ils l’utilisent (la profondeur) et sur quelle fenêtre de temps (le temps). Si vous vous trompez là-dessus, vous livrez un dashboard qui affiche 80% quand le chiffre honnête est 12%. Ceci est un how-to : instrumentez la feature, calculez les trois métriques et agissez dessus.

Prérequis

• Un outil d’analytics qui capture des événements custom rattachés à un ID stable d’utilisateur/compte — Amplitude, Mixpanel, Heap ou Pendo. Heap capture automatiquement les clics (moins d’instrumentation initiale, taxonomie d’événements plus brouillonne) ; Amplitude et Mixpanel nécessitent des appels explicites à track() (plus de travail, données plus propres).
• Une « population éligible » définie. Tous les utilisateurs ne peuvent pas utiliser toutes les features — une feature gardée derrière un plan Enterprise a pour dénominateur les seats Enterprise, pas tous les seats. Écrivez cette règle avant de calculer quoi que ce soit.
• Une définition de ce que signifie « utiliser la feature » sous forme d’un ou plusieurs événements concrets, pas une vue de page. Ouvrir la page n’est pas de l’adoption ; compléter l’action centrale en est.

Étape 1 — instrumentez l’action centrale, pas la page

Déclenchez un seul événement nommé sur l’action qui livre la valeur de la feature. Pour une feature d’export en masse, l’événement est bulk_export_completed, pas export_page_viewed. Dans Amplitude ou Mixpanel, ajoutez l’appel track('bulk_export_completed', { row_count, format, account_id }) dans le callback de succès de l’export, après la génération du fichier — jamais au clic sur le bouton, car les clics incluent les échecs et les rage-clics. Dans Pendo ou Heap, vous pouvez taguer l’élément du DOM en état de succès, mais un événement côté serveur est plus fiable car il survit aux ad-blockers et aux crashs du client.

Attachez account_id et plan_tier comme propriétés de l’événement pour pouvoir ensuite filtrer le dénominateur sur les comptes éligibles. Sans cela, vous pouvez calculer la largeur sur tous les utilisateurs mais jamais sur la population éligible — et c’est le chiffre de la population éligible qui compte.

Étape 2 — calculez les trois formules

Largeur     = adoptants / utilisateurs éligibles      (l'ont-ils seulement touchée ?)
Profondeur  = actions centrales / adoptant            (à quel point s'appuient-ils dessus ?)
Temps       = adoptants dans les N jours d'éligibilité / utilisateurs éligibles de ce cohort

• La largeur est le taux d’adoption principal. Un adoptant est tout utilisateur éligible ayant déclenché l’événement central au moins une fois dans la fenêtre. La largeur répond à « cette feature a-t-elle pris, tout court ? »
• La profondeur sépare une feature que les gens essaient une fois d’une feature dont les gens dépendent. Calculez-la uniquement sur les adoptants (pas toute la base), sinon une largeur faible masquera une profondeur élevée. Une feature à 15% de largeur et 40 actions par adoptant par mois est une feature de power-user, pas un échec — traitez-la différemment d’une à 15% de largeur et 1.2 action.
• Le temps d’adoption est la largeur mesurée sur une horloge de cohort. « Quelle proportion des comptes devenus éligibles en mars ont utilisé la feature dans les 30 jours ? » C’est la métrique qui vous dit si votre onboarding met la feature en avant, et c’est celle que la plupart des équipes sautent.

Exemple chiffré : une feature est gardée pour 500 comptes Enterprise. Sur une fenêtre de 30 jours, 145 ont déclenché l’événement central, générant 1 160 actions centrales au total. Largeur = 145 / 500 = 29%. Profondeur = 1 160 / 145 = 8 actions par adoptant. Si seulement 60 des 145 ont adopté dans les 30 jours suivant leur éligibilité, temps d’adoption(30j) = 60 / 500 = 12%.

Étape 3 — choisissez la fenêtre délibérément

La fenêtre n’est pas cosmétique. Une feature d’usage quotidien (un dashboard) doit être mesurée sur une fenêtre active glissante de 7 ou 28 jours — quelqu’un qui l’a utilisée le trimestre dernier n’est pas un adoptant aujourd’hui. Une feature d’usage trimestriel (un export de compliance) nécessite une fenêtre de 90 jours, sinon vous rapporterez du churn qui n’est que de la saisonnalité. Alignez la fenêtre sur la cadence naturelle de la feature, écrivez-la dans la définition de la métrique et ne comparez jamais deux features mesurées sur des fenêtres différentes.

Étape 4 — fixez le plancher du dénominateur

Pour une feature âgée de moins d’un cycle de release, la population éligible est encore en croissance, donc la largeur est artificiellement déprimée par les comptes devenus éligibles hier. Excluez les comptes éligibles depuis moins que la cadence naturelle de la feature (p. ex. écartez les comptes éligibles depuis moins de 28 jours pour une feature d’usage hebdomadaire). Rapportez la largeur sur la population mûre et le temps d’adoption sur le cohort complet — elles répondent à des questions différentes.

À quoi ressemble le bon

Il n’existe pas de benchmark universel ; le taux d’adoption est spécifique à chaque feature. Une feature de workflow centrale dans la plage de 40-60% de largeur est saine ; une feature de power-user ou d’admin vivant à 5-15% de largeur peut être pleinement réussie si la profondeur est élevée parmi les rares qui l’adoptent. Le chiffre qui devrait vous alarmer est une feature à la fois à largeur faible et à profondeur faible après une fenêtre de cadence complète — c’est une feature dont personne n’avait besoin, et l’action est de la retirer ou de la reconstruire, pas de pousser plus fort sur l’enablement.

Agir sur les données

• Largeur faible, profondeur élevée — problème de découverte. Ceux qui la trouvent l’adorent. Mettez-la en avant dans l’onboarding et in-app (guides Pendo, prompts d’empty-state), puis re-mesurez le temps d’adoption.
• Largeur élevée, profondeur faible — valeur superficielle ou feature à usage unique. Si elle devait être récurrente, le moment d’activation ne prend pas ; investiguez le décrochage du deuxième usage.
• Largeur faible, profondeur faible, fenêtre complète écoulée — candidate à la suppression. Confirmez avec un cross-tab churn/expansion avant de la retirer, mais ne continuez pas à investir de l’enablement dans une feature que la population éligible a rejetée.

Pièges courants

• Les vues de page comme adoption. Compter page_viewed gonfle la largeur avec tous ceux qui ont cliqué par accident. Garde : l’événement central se déclenche dans le callback de succès de l’action qui livre la valeur, jamais sur la navigation ou le clic.
• Dénominateur = tous les utilisateurs. Diviser par le total des comptes quand la feature est gardée par plan sous-estime l’adoption parmi ceux qui peuvent réellement l’utiliser. Garde : filtrez le dénominateur par plan_tier/entitlement, défini à l’Étape 1.
• Aucune fenêtre, ou fenêtres désaccordées. Un chiffre cumulé à vie « l’a déjà utilisée » ne fait que monter et ne dit rien sur la santé actuelle. Garde : définissez une fenêtre glissante alignée sur la cadence de la feature (Étape 3) et ne comparez jamais des features mesurées sur des fenêtres différentes.
• Largeur et profondeur moyennées ensemble. Rapporter « actions moyennes par utilisateur » sur toute la base mélange adoptants et non-adoptants dans un milieu sans signification. Garde : calculez la profondeur uniquement sur les adoptants.

Liés

• NRR vs GRR — l’adoption est un indicateur avancé de la rétention
• Pendo — guides in-app pour stimuler l’adoption des features à faible largeur
• Amplitude — analyse de cohort et de funnel pour le temps d’adoption