product-analytics

Principes clés

1. Instrumenter avant d'avoir besoin de données - Le suivi est une condition préalable, non une pensée tardive. Ajoutez l'instrumentation lors du lancement d'une fonctionnalité, non quand un stakeholder demande « suivons-nous cela ? » Ajouter des événements rétroactivement signifie perdre la période de référence et la capacité à comparer avant/après.

2. Définir les métriques avant de construire les fonctionnalités - Avant d'écrire une ligne de code, mettez-vous d'accord sur ce qui constitue le succès et comment il sera mesuré. Une fonctionnalité sans métrique de succès ne peut pas être évaluée et ne peut pas être abandonnée. Inscrivez la définition de la métrique dans la spécification.

3. Segmenter tout - Les nombres agrégés cachent la vérité. Ventrez toujours les métriques par segment d'utilisateurs (nouveaux vs. récurrents, niveau de plan, canal d'acquisition, géographie) avant de tirer des conclusions. Un taux de rétention global qui semble sain peut masquer un effondrement de la cohorte de nouveaux utilisateurs.

4. La rétention est la métrique ultime - L'acquisition et l'activation sont des fondamentaux. La rétention - si les utilisateurs reviennent et obtiennent une valeur répétée - est le seul signal qui prouve l'adéquation produit-marché. Un produit avec une forte rétention peut corriger l'acquisition ; un produit avec une rétention cassée ne peut pas être sauvé par des dépenses de croissance.

5. La corrélation nécessite une investigation, pas une célébration - Deux métriques qui bougent ensemble forment une hypothèse, non une conclusion. Avant d'attribuer une causalité, vérifiez les facteurs confondants, testez la relation avec une expérience contrôlée, et documentez les preuves. Agir sur des corrélations fallacieuses gaspille la capacité d'ingénierie et peut nuire aux utilisateurs.

Concepts fondamentaux

Taxonomie des événements

Les événements sont les atomes de l'analytique produit. Un événement représente une action utilisateur discrète (ou une action système) à un moment donné. Une taxonomie bien conçue rend les requêtes intuitives et évite le « cimetière d'événements » où des centaines d'événements mal nommés s'accumulent sans documentation.

Convention de nommage : objet_action en snake_case. L'objet est la chose sur laquelle agir ; l'action est ce qui s'est passé.

user_signed_up
dashboard_viewed
report_exported
onboarding_step_completed
subscription_upgraded

Chaque événement doit porter un ensemble cohérent de propriétés :

• user_id - identifiant anonyme ou authentifié
• session_id - regroupe les événements dans une seule session
• timestamp - ISO 8601, toujours UTC
• platform - web, ios, android, api
• event_version - permet l'évolution du schéma sans casser les requêtes

Des propriétés spécifiques à l'entité sont ajoutées par événement :

report_exported:
  report_type: "weekly_summary"
  format: "csv"
  row_count: 1450

Analyse d'entonnoir

Un entonnoir est une séquence ordonnée d'étapes qu'un utilisateur doit accomplir pour atteindre un objectif. L'analyse d'entonnoir révèle où les utilisateurs abandonnent et quantifie la perte de conversion à chaque étape.

Mesures clés :

• Taux de conversion d'étape - utilisateurs qui ont complété l'étape N+1 / utilisateurs qui ont complété l'étape N
• Taux de conversion global - utilisateurs qui ont complété l'étape finale / utilisateurs qui ont saisi l'étape 1
• Temps de conversion - temps médian et 90e percentile entre la première et la dernière étape
• Point d'abandon - l'étape avec le déclin de conversion le plus abrupt

Les entonnoirs doivent être analysés avec une fenêtre définie (p. ex., dans les 7 jours, dans une seule session) pour éviter de compter les utilisateurs qui convertissent des mois plus tard par coïncidence.

Entonnoirs courants par type de produit :

Analyse de cohorte

Une cohorte est un groupe d'utilisateurs qui partagent une caractéristique définissante à un moment spécifique - le plus souvent la semaine ou le mois où ils se sont inscrits pour la première fois. L'analyse de cohorte suit comment le comportement de ce groupe évolue au fil du temps.

Tableau de rétention de cohorte :

         Sem 0  Sem 1  Sem 2  Sem 3  Sem 4
Jan S1:  100%    42%    31%    27%    25%
Jan S2:  100%    38%    29%    26%    24%
Jan S3:  100%    45%    34%    30%    28%

Lire une ligne horizontale montre comment une cohorte spécifique se retient au fil du temps. Lire une colonne verticale montre si une période donnée depuis l'inscription s'améliore ou se détériore selon les cohortes. Une amélioration vers le bas d'une colonne - les cohortes plus récentes se retenant mieux que les anciennes - est le signal précoce le plus fort que les améliorations produit fonctionnent.

Les cohortes comportementales regroupent les utilisateurs selon une action plutôt que selon la date d'inscription (p. ex., les utilisateurs qui ont complété l'onboarding vs. ceux qui l'ont ignoré). Comparer les cohortes comportementales quantifie l'impact d'un comportement spécifique sur la rétention en aval.

Courbes de rétention

Une courbe de rétention trace le pourcentage d'une cohorte qui reste active au cours de périodes successives. La forme de la courbe importe autant que le nombre final.

Formes de courbe :

• Décroissance plate vers zéro - tous les utilisateurs finissent par abandonner ; le produit n'a pas de boucle formant une habitude. Problème fondamental du produit.
• Décroissance vers un palier stable - certains utilisateurs abandonnent, mais un groupe central reste. Le pourcentage du palier est la « vraie rétention » du produit. L'objectif est de relever le palier.
• Courbe en sourire (récupération) - les utilisateurs abandonnent, puis certains reviennent. Courant dans les produits saisonniers ou basés sur le cycle de vie. Vaut la peine de comprendre le déclencheur de réactivation.

Repères D1 / D7 / D30 par catégorie (applications mobiles) :

Hiérarchie des métriques

Un cadre de métriques sain comporte trois niveaux. Les confondre crée de la confusion sur ce que l'équipe optimise.

Métrique North Star - Le nombre unique qui capture le mieux la valeur livrée aux utilisateurs et prédit le succès commercial à long terme. C'est un indicateur décalé qui change lentement. Exemples : utilisateurs actifs hebdomadaires effectuant une action centrale, nombre de projets avec 3+ collaborateurs, transactions mensuelles traitées.

Règles pour une bonne North Star :

1. Elle mesure la valeur livrée, pas l'activité (les DAU seuls ne sont pas une North Star)
2. Une équipe ne peut pas la « gamer » sans genuinely aider les utilisateurs
3. Elle est compréhensible par chaque personne dans l'entreprise
4. Elle bouge sur une échelle de temps pertinente (pas trop rapide pour être bruyante, pas trop lente pour fournir un signal)

Métriques d'entrée (indicateurs avancés) - Les comportements qui causalement pilotent la North Star. Elles sont actionnables par les équipes produit et ingénierie dans un trimestre. Exemples : taux d'activation des nouveaux utilisateurs, taux de complétion des actions centrales, profondeur d'engagement des fonctionnalités.

Métriques de santé (garde-fous) - Des métriques qui ne doivent pas régresser lors de l'optimisation des métriques d'entrée. Exemples : latence API p99, taux d'erreur, volume de tickets de support client, taux d'abandon pour les utilisateurs payants existants. Les métriques de santé empêchent d'optimiser une chose en en cassant une autre.

Tâches courantes

Définir un cadre de métriques - North Star + métriques d'entrée

1. Commencez par le modèle commercial : quel comportement utilisateur crée des revenus durables ?
2. Identifiez le « moment aha » - l'action qui corrèle le plus fortement avec la rétention à long terme
3. Exprimez la North Star comme : [fréquence] + [utilisateurs] + [action centrale] - p. ex., « utilisateurs actifs hebdomadaires qui créent au moins un rapport »
4. Remontez la chaîne pour lister 3-5 comportements qui conduisent les utilisateurs à la North Star
5. Mappez chaque comportement à un événement mesurable dans la taxonomie
6. Définissez des garde-fous de métriques de santé pour la latence, les erreurs et l'abandon
7. Documentez le cadre dans un seul doc partagé ; chaque équipe doit s'y référer

Construire une analyse d'entonnoir - optimisation de conversion

1. Définissez l'événement objectif (achat, activation, souscription) et remontez pour identifier chaque étape préalable
2. Instrumentez chaque étape avec un événement cohérent si pas déjà suivi
3. Définissez une fenêtre de conversion appropriée au produit (1 session, 7 jours, 30 jours)
4. Calculez les taux de conversion étape par étape et globaux segmentés par canal d'acquisition, type d'appareil, et plan utilisateur
5. Identifiez l'étape avec l'abandon absolu le plus élevé (pas seulement le taux le plus bas)
6. Générez des hypothèses pour l'abandon (friction UX, valeur non communiquée, erreur technique)
7. Concevez des expériences ou de la recherche qualitative ciblée pour tester les hypothèses avant de construire

Exécuter une analyse de cohorte - courbes de rétention

1. Définissez le groupement de cohorte : la semaine/mois d'inscription est le défaut ; les cohortes comportementales sont plus diagnostiques
2. Définissez « actif » précisément : l'utilisateur a-t-il complété l'action de valeur centrale, pas juste une connexion
3. Tirez le tableau de rétention pour les 6-12 dernières cohortes
4. Tracez les courbes de rétention et identifiez le palier stable (s'il en existe un)
5. Comparez les cohortes au fil du temps : les cohortes plus récentes se retiennent-elles mieux que les anciennes ?
6. Segmentez les utilisateurs qui se retiennent le mieux : qu'ont-ils fait différemment lors de leur première semaine ?
7. Traduisez la différence comportementale en hypothèse produit à tester

Mesurer l'adoption de fonctionnalité - cycle de vie d'adoption

Suivez quatre étapes et leurs métriques associées :

Signalez l'adoption comme un entonnoir : parmi tous les utilisateurs éligibles, quel % a atteint chaque étape ? Suivez séparément l'adoption parmi les nouveaux utilisateurs vs. les utilisateurs existants - les modèles d'adoption diffèrent souvent fortement.

Configurer la taxonomie d'événements - conventions de nommage

1. Auditez les événements existants pour identifier les doublons, les incohérences et les événements orphelins
2. Établissez la norme de nommage objet_action ; documentez les exceptions
3. Définissez l'ensemble de propriétés universelles requis sur chaque événement
4. Créez un registre d'événements vivant (feuille de calcul ou catalogue de données) avec : nom de l'événement, condition de déclenchement, propriétaire, date d'ajout, propriétés, et exemple de payload
5. Ajoutez l'instrumentation à la liste de contrôle PR : les nouvelles fonctionnalités doivent inclure une spécification d'événement
6. Configurez un examen trimestriel pour dépublier les événements sans requêtes actives

Analyser les résultats des tests A/B - signification statistique

1. Confirmez que l'expérience a été conçue correctement avant de lire les résultats : assignation aléatoire, pas de contamination par effet de nouveauté, taille d'échantillon suffisante via calcul de puissance pré-test
2. Identifiez la métrique primaire et les métriques de garde-fou à l'avance ; ne les ajoutez pas post-hoc
3. Vérifiez les discordances de ratio d'échantillon (SRM) : si la répartition de l'assignation diverge de plus de 1-2% du ratio prévu, l'expérience est probablement biaisée et les résultats sont invalides
4. Calculez la signification statistique en utilisant le test approprié (test z pour proportions, test t pour les moyennes) ; utilisez un test bilatéral sauf s'il existe une hypothèse directionnelle pré-enregistrée
5. Rapportez les intervalles de confiance, pas seulement les p-valeurs - un effet statistiquement significatif mais minuscule peut ne pas justifier le coût de maintenance
6. Vérifiez les métriques de garde-fou pour les régressions avant de déclarer un gagnant
7. Segmentez les résultats par cohorte d'utilisateur : un traitement qui aide les nouveaux utilisateurs mais nuit aux utilisateurs avancés n'est pas une victoire

Créer des tableaux de bord produit - par audience

Créez des vues séparées pour différentes audiences ; les combiner crée du bruit pour tout le monde.

Règles d'hygiène du tableau de bord :

• Chaque métrique sur un tableau de bord doit avoir un propriétaire qui peut expliquer une déviation
• Supprimez les métriques qui n'ont pas entraîné une décision au cours du dernier trimestre
• Annotez la chronologie avec les lancements de produits et les événements externes qui affectent les lignes de base

Anti-motifs

Pièges

1. Les résultats des tests A/B sont invalides si vous regardez avant d'atteindre la taille d'échantillon requise - Vérifier les résultats quotidiennement et arrêter quand p < 0,05 est atteint gonfle le taux de faux positifs à 30%+ (comparé au 5% nominal). Ceci est du p-hacking. Pré-calculez la taille d'échantillon requise en utilisant une analyse de puissance avant que l'expérience ne commence et n'évaluez pas les résultats avant que cette taille soit atteinte.

2. Les fenêtres de conversion d'entonnoir trop longues gonflent les taux de conversion - Une fenêtre de conversion de 90 jours pour un essai-vers-payant affichera un taux de conversion plus élevé qu'une fenêtre de 14 jours, mais elle mélange les cohortes et obscurcit la latence d'achat réelle. Choisissez des fenêtres de conversion qui correspondent au cycle produit réel ; validez-les en vérifiant la distribution du temps-à-conversion avant de verrouiller une fenêtre.

3. Les changements de nommage d'événement rétroactivement cassent les requêtes historiques - Renommer user_signup en account_created divise le flux d'événements à la date de migration. Toute requête de rétention ou d'entonnoir qui s'étend sur le renommage retourne silencieusement des données incomplètes. Avant de renommer un événement, assurez-vous que les anciens et nouveaux noms sont capturés en parallèle pendant une période de transition, et mettez à jour tous les tableaux de bord et les requêtes avant de dépublier l'ancien nom.

4. La réutilisation d'ID de session entre les redémarrages d'application peut fusionner des parcours utilisateur séparés - Si votre ID de session est un identifiant d'appareil persistant plutôt qu'un jeton de session limité dans le temps, toute activité du même appareil sur des semaines peut apparaître comme une seule énorme session. Cela corrompt l'analyse d'entonnoir au niveau de la session. Définissez les sessions avec un délai d'inactivité (30 minutes est standard) et générez des nouveaux ID de session après chaque délai.

5. Les métriques North Star qui incluent les utilisateurs internes surestiment la valeur livrée - Si la North Star de votre produit inclut des comptes d'employés, des comptes de test ou une activité de bot, la métrique est gonflée par une utilisation non-client. Filtrez les utilisateurs internes de toutes les métriques produit dès le départ. Les exclure rétroactivement à mi-mesure crée des discontinuités qui ressemblent à des régressions.

Références

Pour un contenu détaillé sur des sous-domaines spécifiques, consultez le fichier pertinent dans references/ :

• references/metrics-catalog.md - Métriques produit complètes par catégorie avec définitions, formules et guide de repères. Charger lors du calcul de métriques spécifiques à partir de données brutes.
• references/funnel-methodology.md - Analyse approfondie de la construction d'entonnoirs, entonnoirs multi-étapes vs. embranchés, sélection de fenêtre temporelle, signification statistique pour les comparaisons d'entonnoirs, et techniques de segmentation avancées. Charger lors de la création ou du débogage d'entonnoirs complexes.
• references/feature-adoption.md - Mesure du cycle de vie d'adoption de fonctionnalité, fiches d'adoption, critères de suppression pour les fonctionnalités sous-performantes, et repères d'adoption par catégorie de produit. Charger lors de la mesure ou de la planification de lancements de fonctionnalités.

Chargez un fichier de références seulement si la tâche actuelle nécessite un détail approfondi sur ce sujet.