Configuration de l'analytique d'expérience

Cette skill répond à : Qui est inclus dans l'analyse ? et Comment mesurer l'impact ?

Critères d'exposition

Les critères d'exposition déterminent quels utilisateurs sont comptabilisés dans l'analyse de l'expérience.

Inclure des personnes quand

Deux options :

1. Feature flag appelé (par défaut) — les utilisateurs sont inclus quand l'événement $feature_flag_called se déclenche pour le flag de l'expérience. C'est l'approche standard — cela signifie qu'un utilisateur n'est inclus que s'il rencontre réellement le feature flag dans votre code.
2. Événement d'exposition personnalisé — les utilisateurs sont inclus quand un événement personnalisé spécifique se déclenche. Utilisez cette option quand vous voulez un contrôle plus strict sur qui entre dans l'analyse (par exemple, seulement les utilisateurs qui visitent réellement la page où l'expérience s'exécute).

Gestion de variantes multiples

Quand un utilisateur est exposé à plusieurs variantes (par exemple, en raison de changements de flag ou de conditions de course) :

• Exclure les utilisateurs multivariés — supprime entièrement ces utilisateurs de l'analyse. Données plus propres, échantillon plus petit.
• Première variante vue — assigne les utilisateurs à la première variante à laquelle ils ont été exposés. Garde tous les utilisateurs dans l'analyse. Notez que « première variante vue » peut introduire d'autres biais car le comportement ne peut pas être clairement attribué à une seule variante et n'est pas recommandé sauf si nécessaire.

Risque de biais sur des divisions inégales. « Exclure les utilisateurs multivariés » combiné avec une division inégale des variantes peut introduire un biais — les utilisateurs multi-variantes sont supprimés de façon asymétrique et la variante plus petite perd une plus grande fraction de ses attributions. Si ces utilisateurs se comportent différemment du reste, les métriques de la variante plus petite seront faussées.

La bonne atténuation dépend de l'état de l'expérience :

• Pas encore lancée, ou exposée à seulement quelques utilisateurs jusqu'à présent — basculez vers une division de variantes égale et utilisez le pourcentage de déploiement global pour limiter l'exposition de la variante de test. Cela supprime le biais et préserve la puissance statistique. Voir configuring-experiment-rollout.
• Expérience active avec des expositions importantes — changer la division en cours d'exécution réassigne les utilisateurs entre les variantes, ce qui est mauvais pour l'expérience utilisateur et la qualité des données. Basculez plutôt ce paramètre sur « Première variante vue » — cela garde les utilisateurs déjà assignés dans leur variante d'origine (pas de réassignation) et supprime l'exclusion asymétrique.

Filtrer les comptes de test

exposure_criteria.filterTestAccounts (par défaut : true) — exclut les utilisateurs internes/test de l'analyse.

Résolution d'expériences

Les modifications de métriques nécessitent un ID d'expérience. Si l'utilisateur se réfère à une expérience par nom ou description (par exemple « ajouter des métriques au test de checkout »), chargez la skill finding-experiments pour la résoudre en ID concret avant de procéder.

Métriques

Les métriques sont ajoutées via experiment-update après la création. Le tableau metrics remplace la liste entière, donc récupérez toujours l'expérience actuelle d'abord via experiment-get pour préserver les métriques existantes.

Étape 1 : Découvrir les événements disponibles (OBLIGATOIRE — toujours faire ceci en premier)

Avant de suggérer ou configurer UNE QUELCONQUE métrique, vous DEVEZ appeler read-data-schema pour découvrir quels événements existent réellement dans le projet. NE SAUTEZ PAS cette étape. NE suggérez PAS de noms d'événements selon ce que vous pensez que le projet pourrait tracker — utilisez uniquement les événements que vous avez confirmé exister.

Cela s'applique même quand :

• L'utilisateur fournit des noms d'événements — cherchez-les pour confirmer qu'ils existent et sont orthographiés correctement
• L'utilisateur demande « quelles métriques me suggérez-vous ? » — cherchez d'abord les événements, puis suggérez à partir de données réelles
• Le contexte rend certains événements évidents — ils pourraient ne pas exister ou être nommés différemment

Workflow :

1. Appelez read-data-schema pour obtenir les événements du projet
2. Présentez les événements pertinents à l'utilisateur selon l'hypothèse de l'expérience
3. L'utilisateur choisit quels événements utiliser pour les métriques
4. Configurez les métriques avec ces noms d'événements confirmés

Exception légitime — allow_unknown_events: true : Passez ceci sur experiment-create / experiment-update uniquement quand l'utilisateur instrumente intentionnellement un événement qui n'a pas encore été ingéré (par exemple, mettre en place l'expérience avant que le changement de code ne soit livré). Confirmez ceci avec l'utilisateur — ne l'utilisez jamais comme contournement pour « la recherche d'événement n'a pas retourné ce que j'attendais ».

Exemple :

Utilisateur : « Ajoutons quelques métriques pour l'expérience de checkout »

MAUVAIS : « Je suggérerais d'utiliser purchase_completed comme métrique primaire... »
  (nom d'événement halluciné — jamais vu les événements réels du projet)

BON : *appelle read-data-schema* → « Voici les événements de votre projet
  liés à checkout : `checkout_step_completed`, `payment_processed`,
  `order_confirmed`. Lequel représente un checkout réussi ? »

Étape 2 : Choisir le type de métrique

Il y a quatre types de métriques. Chacun a kind: "ExperimentMetric" :

Métriques funnel et l'étape d'exposition implicite

Les métriques funnel ajoutent automatiquement l'événement d'exposition de l'expérience comme step_0. Donc un funnel avec 1 étape dans series est un funnel valide à 2 étapes : exposition → action. C'est le bon choix pour mesurer « quel pourcentage d'utilisateurs exposés a fait X ? »

Exemples :

• « Quel % des utilisateurs exposés ont atteint /login ? » → funnel avec 1 étape ($pageview filtré sur /login)
• « Quel % des utilisateurs exposés ont complété le checkout ? » → funnel avec 1 étape (checkout_completed)
• « Quel % des utilisateurs exposés ont fait panier → checkout → achat ? » → funnel avec 3 étapes

Mean vs funnel pour le même événement

• Mean mesure le nombre/valeur moyen par utilisateur (par exemple « pages par utilisateur », « revenus par utilisateur »).
• Funnel mesure le taux de conversion (par exemple « % d'utilisateurs exposés qui ont acheté »).

Les deux peuvent référencer le même événement — la différence est si vous vous intéressez au nombre/magnitude (mean) ou à la conversion oui/non (funnel).

Voir references/metric-configuration.md pour des exemples JSON détaillés de chaque type.

Étape 3 : Primaire vs secondaire

• Métriques primaires — les critères de succès principaux de l'expérience. Elles pilotent la décision de déploiement/fin.
• Métriques secondaires — mesures supplémentaires pour le contexte. Utiles pour les métriques de garde-fou (par exemple, s'assurer qu'une amélioration de conversion n'augmente pas les taux d'erreur).

Interpréter les résultats

Voir references/interpreting-results.md pour des conseils sur la lecture des résultats d'expérience, la significativité statistique, et quand déployer ou terminer.