Diagnostic des résultats d'expérience

Cette compétence répond à : Mes résultats d'expérience PostHog semblent incorrects, biaisés ou vides — que se passe-t-il ?

Identifiez la plainte de l'utilisateur dans le tableau de dispatch, puis consultez le fichier de référence correspondant pour le diagnostic.

Chaque diagnostic dans les fichiers de référence est tagué [HIGH], [MEDIUM] ou [LOW] selon le niveau de vérification — [HIGH] est vérifié directement dans le code PostHog, [MEDIUM] est partiellement ou par source d'équipe, [LOW] décrit le comportement du SDK/externe qui n'a pas été vérifié ici. Traitez les éléments [LOW] comme des hypothèses à tester, non comme des faits à affirmer.

Étape 1 — Résoudre l'expérience

Si l'utilisateur fait référence à une expérience par nom ou description, chargez d'abord la compétence finding-experiments pour la résoudre en un ID concret.

Appelez experiment-get et extrayez ces champs. Ce sont des entrées pour presque tous les diagnostics :

• parameters.feature_flag_variants[].rollout_percentage — la répartition des variantes
• parameters.rollout_percentage — le déploiement global (% d'utilisateurs entrant dans l'expérience)
• exposure_criteria.multiple_variant_handling — par défaut "exclude" si absent
• exposure_criteria.exposure_event — null signifie $feature_flag_called par défaut
• exposure_criteria.filterTestAccounts — par défaut true
• feature_flag.active, statut (draft / running / paused / stopped), start_date, end_date
• feature_flag.filters.groups[].variant — toute valeur non-null est un remplacement de variante forcée sur la cohorte appariée (assignation de condition de release, pas aléatoire). Affiche A7 par défaut.
• stats_config — Bayésienne (par défaut) ou Fréquentiste

Étape 1.5 — Extraire un snapshot de diagnostic (vérifier avant de demander)

Avant de poser à l'utilisateur des questions de clarification, extrayez le snapshot de diagnostic dans references/diagnostic-snapshot.md. La plupart des diagnostics de cette compétence peuvent être confirmés ou écartés à partir de ces données sans entretien.

Étape 2 — Associer symptôme à diagnostic

Si le symptôme est flou, posez une seule question de clarification avant de choisir. La plupart des diagnostics ont des solutions différentes — ne devinez pas.

Étape 3 — Surfacer chaque diagnostic que les preuves soutiennent

Après avoir associé le symptôme à l'étape 2 et lu le(s) fichier(s) de référence correspondant(s), listez chaque diagnostic applicable avant de recommander une action.

Surfacez les mécanismes concomitants indépendamment — même quand l'un est plus saillant, ne les fusionnez pas en une seule recommandation « attendre » ou « corriger ». Les différents mécanismes ont des solutions différentes : un biais systématique (ex. répartition inégale + Exclude) ne se résout pas en attendant ; une régularité statistique (ex. variance sur petit échantillon) si. Les regrouper laisse le biais en place après que l'utilisateur suive le conseil regroupé.

Listez uniquement les mécanismes qui ont un chemin de vérification dans l'état du projet — configuration (depuis experiment-get), données snapshot, journal d'activité, ou source repo. Les mécanismes dérivés de la configuration comptent : une répartition 80/20 avec multiple_variant_handling="exclude" par défaut est visible dans experiment-get et est donc énumérable. Nommer un mécanisme sans source (ex. SRM quand le snapshot affiche un ratio de variante propre) ne l'est pas.

Groupes de diagnostic

A — Biais et asymétrie

Les variantes ne semblent pas équilibrées, une variante semble biaisée, le banneau d'avertissement en app a apparru, ou les utilisateurs apparaissent sous plusieurs variantes. Couvre l'interaction répartition-inégale + Exclude, SRM, fragmentation d'identité, bootstrap × /decide déphasage, et inconsistance d'état flag/expérience.

→ Voir references/bias-and-skew.md

B — Expérience vide / 0 expositions / « pas assez de données »

Un point douloureux fréquent. Couvre l'appel SDK (mauvaise méthode d'évaluation, timing de identify(), dédup), capture d'exposition (événement personnalisé manquant la propriété de variante, propriétés requises, ad-blockers), et correspondance de critères d'exposition (filtre de compte test, ordre d'éligibilité, événements se déclenchant avant l'exposition).

→ Voir references/empty-experiment.md

C — Pièges de significativité / interprétation

Retournement de significativité, test A/A affichant significativité, confusion Bayésienne vs Fréquentiste, comparaisons multiples, variance en faible volume, peeking / early stopping. Inclut le problème de stats legacy (les tests A/A se sont historiquement sur-déclenchés avant le nouveau module Bayésien) et comment la méthodologie de probabilité de victoire a changé en janvier 2025 (test unique vs contrôle, non contrôle vs toutes variantes).

→ Voir references/interpretation.md

D — Les nombres ne correspondent pas (PostHog vs SQL / décompte brut de l'utilisateur)

La page d'expérience applique une portée d'exposition, exclusion $multiple, filtre de compte test, et plage de dates qu'un SQL ad-hoc ne réplique presque jamais. Couvre l'attribution d'entonnoir (seul premier→dernière étape compte pour les stats), breakdowns (lus depuis l'événement d'exposition, non l'événement de métrique), la confusion « somme de revenus » mean-of-per-user, et la divergence panneau-recordings vs stats.

→ Voir references/numbers-vs-sql.md

E — Surprises après changements en cours d'exécution (incl. lifecycle et quirks de rétention)

Augmenter le déploiement est sûr ; diminuer demande de la prudence ; modifier la répartition de variante est un anti-pattern ; ajouter des métriques en cours est p-hacking ; ship-variant peut récrire le flag de façons surprenantes ; reset efface les résultats, non le flag. Couvre aussi les quirks de métrique de rétention (conception first-event-must-be-after-exposure), filtrage « matured users », et divergence métrique long-terme vs court-terme.

→ Voir references/mid-run-changes.md

Étape 4 — Calibrer les recommandations à l'état de l'expérience

Surfacez les diagnostics d'abord (étape 3). Puis recommandez — mais limitez ce que vous recommandez à ce que l'état courant de l'expérience permet.

• Draft — les changements de configuration sont gratuits ; recommandez et appliquez.
• Running — chaque changement a un compromis. Expliquez l'impact en cours d'exécution (anti-pattern ? sûr ? visible pour l'utilisateur ?) avant de recommander. Voir configuring-experiment-rollout et son fichier de référence references/changing-distribution-after-launch.md pour les règles en cours d'exécution.
• Stopped / archived — l'expérience ET son feature flag représentent le résultat documenté de l'exécution. Les recommandations sont limitées à (a) l'interprétation des données existantes, (b) quoi faire pour la prochaine expérience, ou (c) expliquer ce qui s'est passé.

Sur une expérience arrêtée ou archivée, ne proposez pas préventivement un renversement de mutation d'état (réécriture du flag ship-variant, édition manuelle du flag, reset, archive). Si l'utilisateur demande « pourquoi X s'est produit ? », expliquez X — n'ajoutez pas une coda « voilà comment l'annuler ». Ce pattern suppose une intention que l'utilisateur n'a pas signalée. Les offres conditionnelles comme « si ce n'était pas intentionnel, tu pourrais… » ou « veux-tu que je le rétablisse ? » comptent comme préventives aussi — seul l'utilisateur nommant explicitement l'action d'annulation (« comment annuler ceci ? », « puis-je revenir sur ship-variant ? », « comment récupérer la répartition 50/50 ? ») est une demande de surfacer les mécaniques d'annulation.

Utilisez une terminologie cohérente : la répartition de variante (entre variantes) est distincte du déploiement (% global entrant) ; l'événement d'exposition $feature_flag_called est distinct d'un événement d'exposition personnalisé ; les options Exclude / First seen contrôlent la gestion multivariée, non l'exposition.