Audit d'expérience

Vérifier qu'une expérience d'un client collecte réellement les données de variante, que l'attribution en aval survive à l'entonnoir, et que les métriques mesurent ce que le client croit mesurer. La sortie est un compte-rendu prêt pour Slack regroupé par les quatre questions que les clients posent presque toujours.

Étape 0 — confirmer la portée avant de lancer

La skill suppose que le MCP PostHog actif est limité au projet du client, pas au vôtre. Commencez toujours par :

"What project am I in? List the most recent 5 experiments."

Si le nom du projet ressemble à votre propre projet interne (par ex. "PostHog App + Website", id 2), ARRÊTEZ — l'usurpation d'identité ne routage pas correctement. Relancez l'assistant ou vérifiez l'authentification /mcp avant de continuer.

Étape 1 — récupérer la config de l'expérience

Utilisez experiment-list avec search pour trouver l'expérience par nom. Puis extrayez l'enregistrement complet. Capturez :

Statut (en cours / brouillon / arrêté / en pause) et date de début.
Clé de feature flag liée et ID.
Variantes et répartition du trafic. Les noms de variante doivent correspondre à ce que le code du client lit — les bugs de bucketing sont généralement des décalages de casse/typos.
Holdout, clé de bucketing (device_id vs user_id), et ensure_experience_continuity.
Événement d'exposition — par défaut $feature_flag_called ou un événement personnalisé.
Métriques primaires et secondaires. Notez les IDs d'action, noms d'événements, ventilations, fenêtres de conversion, modes d'attribution.
Paramètre de filtre des comptes de test.

Étape 2 — récupérer la config de feature flag

Pour le flag lié :

Conditions de libération — lisez chacune attentivement.
Attention à deux pièges spécifiques :
1. Ciblage par URL via propriété de personne ($current_url = ...) — utilise la dernière URL sur laquelle la personne a été vue, pas la page actuelle. Obsolète par définition. Signalez toujours comme un problème.
2. Correspondance exacte sur un fragment de chemin — $current_url est capturé comme l'URL complet (https://host/path). Une correspondance exacte /path ne correspondra jamais.
Filtres d'audience (desktop uniquement, géolocalisation, cohorte). Vérifiez qu'ils utilisent des propriétés de personne ou des propriétés de groupe — pas l'URL.
Pourcentage de lancement et éventuelles super-conditions.
Paramètre ensure_experience_continuity sur le flag (cela remplace le paramètre au niveau de l'expérience).

Étape 3 — vérifier que l'exposition se produit

Extrayez les événements $feature_flag_called pour la clé du flag depuis la date de début de l'expérience.

Nombre total. Si suspecte pour le temps écoulé, creusez.
Ventilation par $feature_flag_response. Devrait se diviser près de 50/50 entre les noms de variante (par ex. control / test). Signalez une inadéquation du ratio d'échantillon si le déséquilibre dépasse environ 5% avec un volume non négligeable.
Si $feature_flag_response retourne false pour la plupart des événements, l'utilisateur n'est pas bucketing dans l'expérience du tout — la condition de libération les rejette. C'est la cause la plus courante d'« expérience affichant 0 expositions ».
Inspectez 5 lignes d'événements bruts. Notez $current_url, $device_type, $feature_flag, $feature_flag_response, et distinct_id.

Étape 4 — vérifier l'attribution en aval

Pour chaque événement de métrique (clic CTA, visite de page d'inscription, inscription complète, conversion) :

Extrayez des lignes d'exemple et confirmez qu'elles portent la propriété $feature/<flag-key> avec une vraie valeur de variante (control ou test), pas false ou manquante.
Métriques basées sur des actions : vérifiez les filtres d'action. Si la variante rend différents IDs DOM, l'action doit tous les correspondre ou une variante affichera artificiellement 0 événement. Les filtres d'URL d'action doivent correspondre à la page de production, pas à un aperçu de dev.
Portée de la métrique : si la métrique est trop large (par ex. « tout $pageview contenant /signup »), elle crédite les deux variantes pour le trafic mondial quel que soit la source. Suggérez de limiter par la propriété $feature/<flag-key> ou le pathname d'entrée de session.

Étape 5 — vérifier la continuité d'identité

Le handoff inter-domaines (Webflow → app, marketing → produit, etc.) est où l'attribution meurt généralement.

Choisissez 5-10 utilisateurs qui ont atteint l'étape finale de l'entonnoir (par ex. inscription complète). Extrayez leur timeline d'événements.
Confirmez qu'ils ont un événement $feature_flag_called antérieur avec une vraie valeur de variante.
Confirmez que $identify se déclenche sur le handoff. Si les utilisateurs n'ont jamais d'événement $identify, le profil d'appareil anonyme ne s'aplatit jamais à l'utilisateur authentifié — l'attribution de variante est morte même avec un flag parfaitement déclenché.
Confirmez que la clé de bucketing + les paramètres ensure_experience_continuity ensemble ne causent pas de re-bucketing. device_id bucketing sans continuité = le même utilisateur sur un nouvel appareil semble neuf.

Étape 6 — métrique de conversion en aval (activation d'essai / achat / etc.)

Les clients ont souvent un événement de conversion primaire qui vit en aval (dans leur app ou entrepôt).

Recherchez le schéma d'événement pour le nom d'événement attendu. Essayez plusieurs variantes (plus_trial_activated, trial_started, subscription_created).
Si absent, recherchez des sources d'entrepôt via external-data-sources-list. Modèle courant : table Snowflake/Postgres comme accounts.trial_started_at.
Recommandez la voie plus propre : émettez un événement côté serveur depuis l'app lors de l'activation. Plus facile que les jointures d'entrepôt, signal plus rapide, aucune fragilité de schéma.
Alternative : utilisez la table d'entrepôt comme métrique d'expérience directement (supportée pour les métriques d'entonnoir + trend).

Étape 7 — pièges courants à signaler (indépendamment de ce que vous avez trouvé)

La configuration réelle du client a presque toujours l'un de ceux-ci :

Ciblage d'URL par propriété de personne (toujours faux pour ce cas d'usage)
Opérateurs de correspondance exacte sur les propriétés de personne URL complet (ne correspondent jamais)
Métriques d'action liées à des URLs/sélecteurs de dev qui ne se déclencheront pas en prod
Métriques globales (« tout inscription complète ») qui crédite les deux variantes également
$identify manquant sur le handoff domaine marketing → produit
device_id bucketing sans ensure_experience_continuity → re-bucketing entre les sessions
Fenêtre de conversion par défaut de 14 jours trop courte pour les événements de conversion en aval
Filtre utilisateur interne/test non configuré → le trafic QA fausse les premiers jours
Vérification de santé de l'exposition dans les 24h du lancement — un 50/50 qui montre <10 événements en une semaine est un bug de câblage, pas un problème de puissance

Format de sortie

Regroupez le rapport par les quatre questions standard des clients. Commencez par la pire constatation :

:warning: [Nom de l'expérience] — conclusions de l'audit

[Un paragraphe TL;DR de la constatation principale. Soyez direct.]

---
(a) La config a-t-elle l'air correcte ?
[Verdict + problèmes spécifiques avec preuves — nombre d'événements, valeurs d'exemple, etc.]

---
(b) Comment vérifier l'attribution (une fois les problèmes corrigés)
[Étapes concrètes que le client peut exécuter lui-même.]

---
(c) Ce qu'il faut changer à propos de l'attribution
[Liste d'action numérotée, ordre de priorité. Chaque élément doit être assez spécifique
pour que l'ingénieur du client puisse agir directement.]

---
(d) Pièges courants à surveiller
[Sous-ensemble de la liste de contrôle de l'étape 7 pertinent pour la configuration de ce client.
Présentez comme des conseils généraux, pas comme des accusations.]

---
Conclusion : [une ou deux phrases. Quel est le correctif unique le plus important
qui débloque l'expérience ?]

Règles

Lecture seule. Ne créez pas d'insights, de dashboards, d'actions, d'expériences, ou ne modifiez aucune config. Vous usurpez l'identité de l'utilisateur du client — tout écrit land dans son projet réel.
Pas de fabrication. Si vous ne trouvez pas l'expérience ou si les données sont vides, dites-le explicitement. N'inventez pas de constatations pour remplir le modèle.
Citez des nombres réels. Chaque affirmation sur les comptes d'exposition, les rapports d'échantillon, ou les volumes d'événements doit provenir d'une requête que vous avez réellement exécutée dans cette session.
Surfacez l'ambiguïté. Si un paramètre pourrait être intentionnel (par ex. fenêtre de conversion basse parce que la conversion se produit rapidement), notez les deux interprétations et demandez au client de confirmer.
Accordez-vous au registre d'écriture du client. Les clients utilisant PostHog sont généralement techniques — ne sursimplifiiez pas. Mais évitez le jargon qu'ils pourraient ne pas encore connaître.

Quand l'audit est terminé

Rappelez à l'utilisateur de :

Quitter Claude Code
Se déconnecter de l'usurpation d'identité Django Admin dans le navigateur
Optionnellement désactiver le plugin posthog : claude plugin disable posthog

L'enveloppe impersonate-audit.sh gère automatiquement les invites de l'étape 3 à la sortie.

experiment-audit