amplitude/builder-skills

Moniteur d'expériences & générateur de rapports

Analyse les expériences actives et récemment terminées, met en évidence ce qui nécessite une attention, et fait un rapport sur celles qui comptent.

Ceci est une compétence de surveillance — gardez les résultats accessibles aux non-experts. Évitez le jargon statistique (pas de p-values, pas d'analyse de puissance). Pour une analyse approfondie d'une expérience spécifique, utilisez la compétence analyze-experiments.

---

CRITIQUE : Gestion de la taille des réponses

1. get_experiments : 3 à 5 IDs max par appel. Filtrez en utilisant les résultats search AVANT de récupérer.
2. Les réponses query_experiment sont volumineuses. Extrayez uniquement les objets summary et les indicateurs de validité. Ignorez timeseries, xValues, les tableaux massifs.
3. Résolution des noms de métriques : search ne correspond PAS aux IDs de métriques dans queries. Recherchez avec entityTypes: ["METRIC"], queries vide, limitPerQuery: 50, limité au projet. Faites correspondre les IDs à partir des résultats.

---

Structure du rapport

Le rapport comporte deux parties :

1. Résumé et actions (en haut) — Un tableau + des éléments d'action. Quelqu'un devrait pouvoir lire uniquement cela et avoir une vue d'ensemble complète.
2. Détails (en bas) — Analyses approfondies des expériences nécessitant une attention, résumés des expériences récemment décidées, une ligne pour les expériences en surveillance, et une liste des besoins de configuration.

Ne dupliquez PAS les informations entre le tableau récapitulatif et les détails. Le tableau récapitulatif est la source unique de vérité pour l'état du portfolio. Les détails développent des expériences spécifiques.

---

Instructions

Étape 1 : Contexte et découverte

1. Appelez Amplitude:get_context. S'il y a plusieurs projets, demandez lequel surveiller.
2. Recherchez des expériences :

Amplitude:search({
  entityTypes: ["EXPERIMENT"],
  appIds: [projectId],
  queries: [],
  sortOrder: "lastModified",
  sortDirection: "DESC",
  limitPerQuery: 50
})

3. Règles de filtrage — inclure les expériences qui sont :
   • En cours et non périmées : Toute expérience en cours d'exécution qui n'est PAS marquée comme périmée. Les expériences périmées sont devenues inactives et doivent être exclues.
   • Récemment décidées : Les expériences terminées qui ont une décision enregistrée ET ont été modifiées au cours des 14 derniers jours. Celles-ci valent la peine d'être examinées pour confirmer la décision ou partager les apprentissages.
4. Exclure : Les brouillons, les expériences désactivées et les expériences périmées.

---

Étape 2 : Récupération des métadonnées, noms de métriques et résultats principaux

1. Appelez Amplitude:get_experiments par lots de 3 à 5 IDs (uniquement l'ensemble filtré de l'étape 1).
2. Extrayez : l'état, les dates/la durée, les variantes, les IDs de métriques (principales où recommendation=true), la décision, le propriétaire.
3. Appliquez à nouveau les règles de filtrage de l'étape 1 en utilisant les métadonnées détaillées (certains champs comme l'état périmé ou la décision peuvent n'être disponibles qu'ici).
4. Résolvez les noms de métriques via Amplitude:search({ entityTypes: ["METRIC"], appIds: [projectId], queries: [], limitPerQuery: 50 }). Construisez un mapping { id: name }.
5. Pour les expériences qui ont des métriques configurées, appelez Amplitude:query_experiment({ id: "<id>" }) (sans metricIds) pour obtenir les résultats de la métrique principale et les indicateurs de qualité des données. Ces données alimentent à la fois le tableau récapitulatif et les analyses approfondies.

CRITIQUE : Ne montrez jamais les IDs bruts des métriques à l'utilisateur. Si un nom de métrique ne peut pas être résolu, décrivez-le par son rôle (par exemple, « métrique principale », « métrique de garde-fou ») — n'affichez PAS de chaînes comme « rrgtky08 » ou « Métrique gvgb5efj ». Les IDs de métriques sont des identifiants internes qui ne signifient rien pour un lecteur humain.

---

Étape 3 : Résumé et actions

Ceci est le haut du rapport. Il doit être autonome — quelqu'un lisant uniquement cette section voit l'image complète.

Tableau récapitulatif

## Moniteur d'expériences : [Nom du projet]
Date : [Aujourd'hui] | Projet : [Nom] ([ID])

| Expérience | État | Durée | Lift | Verdict |
|---|---|---|---|---|

Définitions des colonnes :

• Expérience — Nom lisible par l'humain (PAS une URL, PAS un ID)
• État — En cours ou Terminée
• Durée — Jours depuis le début de l'expérience
• Lift — Lift relatif de la métrique principale si disponible, « — » si aucune donnée. Pour les multi-variantes, affichez la plage (par ex., « -17% à -20% »)
• Verdict — Que faire (voir le vocabulaire ci-dessous)

Vocabulaire des verdicts :

Verdict	Quand l'utiliser
Livrer	Primaire significativement positif, garde-fous OK, bonne qualité de données
Itérer	Signal positif mais régression d'un garde-fou ou problème de qualité
Surveiller	En cours, pas encore significatif, rien à faire
Abandonner	Primaire significativement négatif, ou problèmes critiques de qualité de données
Décidé : Livrer	Récemment terminée, l'équipe a décidé de livrer
Décidé : Ne pas livrer	Récemment terminée, l'équipe a décidé de ne pas livrer
Corriger config	Erreur de requête, événement d'exposition cassé, ou trafic gravement déséquilibré
Nécessite métriques	En cours sans métriques — impossible d'évaluer
N/A	Déploiement d'enquête/incitation, pas une expérience de fonctionnalité

Éléments d'action (immédiatement après le tableau)

**Agir maintenant :**
- [Expérience] — [action spécifique avec nom du propriétaire]

**Continuer à surveiller :**
- [Expérience] — [bref statut + quand vérifier à nouveau]

**Nécessite configuration :**
- [Expérience] — [ce qui manque + nom du propriétaire]

Chaque expérience du tableau doit apparaître dans exactement une catégorie d'action. S'il n'y a aucune expérience dans une catégorie, omettez cette catégorie.

---

Étape 4 : Détails

En dessous du résumé, fournissez des détails supplémentaires organisés en sections. Chaque expérience apparaît dans EXACTEMENT UNE section — pas de duplication.

4a : Analyses approfondies (expériences nécessitant une attention)

Analysez en profondeur les expériences avec les verdicts Livrer, Itérer ou Abandonner (jusqu'à 3). Celles-ci ont des résultats significatifs qui méritent d'être examinés.

Pour chacune, générez le rapport complet en une seule passe :

---
## [Nom de l'expérience]
[État] | [Durée]j | Contrôle : [N] / Traitement : [N] | [Lien vers l'expérience]

Qualité des données (d'abord — avant les résultats) :

Vérifiez la qualité des données AVANT de rapporter les résultats des métriques. En cas de problèmes critiques, le lecteur a besoin de ce contexte avant d'interpréter les chiffres.

Si tout est OK, une ligne : « Toutes les vérifications de qualité des données sont OK. » Puis passez à la métrique principale.

Si des problèmes sont trouvés, rapportez-les avant la métrique principale :

### Qualité des données : [N problèmes trouvés]

SRM (Sample Ratio Mismatch) :

• Utilisez le champ srmDetected de la réponse de l'API
• Si srmDetected: true : signalez-le toujours en premier et de manière proéminente
• Rapportez : répartition réelle vs. répartition attendue avec des pourcentages spécifiques

Changements d'allocation de trafic :

• Comparez les pondérations actuelles des variantes par rapport à la distribution d'exposition cumulée
• Si elles ne correspondent pas (par exemple, pondérations actuelles 100/0/0 mais cumul 15/70/15), l'allocation a été modifiée en cours d'expérience
• Signalez-le de manière proéminente — cela signifie que certaines variantes ne reçoivent peut-être plus de nouveau trafic

Taille de l'échantillon :

• <100 par variante : Signalez comme insuffisant — trop tôt pour toute conclusion
• 100–1 000 par variante : Signaux directionnels uniquement, pas assez pour des décisions fiables
• 1 000+ : Adéquat pour l'analyse

Indicateurs de validité — signalez uniquement les échecs :

Indicateur	Ce que cela signifie en cas d'échec	Sévérité
isVariancePositive = false	Les données métriques sont invalides — les tests statistiques ne peuvent pas s'exécuter	Critique
isConfidenceIntervalNotFlipped = false	Erreur de calcul dans les résultats — ne faites pas confiance aux chiffres	Critique
isMeanValid = false	Les valeurs métriques sont cassées (NaN/infini) — impossible d'analyser	Critique
statsAssumptionsMetForWholeExperiment = false	Les hypothèses statistiques ne sont pas remplies — les résultats peuvent être peu fiables	Élevé
hasSuspiciousUplift = true	Effet anormalement important — peut être une erreur de mesure, pas un changement réel	Élevé
isPointEstimateInsideConfidenceInterval = false	Incohérence mathématique interne — les résultats peuvent être erronés	Élevé
isStandardErrorLargeEnough = false	Trop de bruit pour obtenir des estimations fiables	Moyen

Si un SRM est détecté ou qu'un indicateur Critique échoue :

⚠️ Les résultats ci-dessous doivent être interprétés avec prudence en raison de [problème].

Métrique principale :

### [Nom de la métrique] : [Verdict en langage simple]

| Variante | Valeur | Lift | IC 95% |
|---------|-------|------|--------|
| Contrôle | [X] | — | — |
| Traitement | [Y] | [+Z%] | [A% à B%] |

[Une phrase d'interprétation en langage simple.]

Règles de cadrage :

• N'incluez PAS de p-values. Les non-experts ne savent pas ce qu'elles signifient.
• Utilisez « non significatif » au lieu de « aucun effet ». Il peut y avoir un effet — l'expérience ne peut tout simplement pas le détecter avec cette taille d'échantillon.
• Commencez par ce qui s'est passé en langage simple.

Mots du verdict :

• Positif significatif — IC entièrement au-dessus de zéro, lift positif
• Négatif significatif — IC entièrement en dessous de zéro, lift négatif
• Non significatif — IC inclut zéro ; nous ne pouvons pas dire avec certitude qu'il y a une différence réelle pour l'instant
• Tendance positive/négative — Signal directionnel mais IC inclut zéro ; vaut la peine de surveiller

Ajoutez une phrase sur la significativité pratique uniquement si le lift est très petit (<2 %) ou très grand (>20 %).

Garde-fous et métriques secondaires :

Appelez Amplitude:query_experiment({ id: "<id>", metricIds: [...] }).

Concentrez-vous sur la détection des régressions, ne racontez pas chaque métrique.

Si aucune régression significative : « Tous les garde-fous et métriques secondaires sont propres — aucune régression significative détectée. »

Si des régressions significatives sont trouvées :

- **[Nom de la métrique] :** Régression significative ([−X%], IC : [A% à B%]) — [une phrase sur l'impact]

Si des régressions directionnelles importantes (>20 % de lift relatif) qui ne sont pas encore significatives :

- **[Nom de la métrique] :** Non significatif, mais directionnellement négatif ([−X%]) — vaut la peine de surveiller

Les petits changements directionnels non significatifs doivent être omis. Si 5+ métriques, notez que les comparaisons multiples augmentent le risque de faux positifs.

Retours d'information (uniquement si la métrique principale est significative) :

Appelez Amplitude:get_feedback_insights avec des mots-clés liés à l'expérience. Rapportez 2-3 thèmes en une ligne chacun. Si aucun retour pertinent, sautez la section.

Verdict :

### Verdict : [LIVRER / ITÉRER / SURVEILLER / ABANDONNER]
1. [Constat sur la métrique principale — une phrase]
2. [Statut de la qualité / des garde-fous — une phrase]
3. [Que faire ensuite — une phrase]

Matrice de décision (référence interne, ne pas afficher) :

Signal	Livrer	Itérer	Surveiller	Abandonner
Primaire	Positif significatif + pratique	Positif significatif mais régression garde-fou	Pas encore significatif, toujours en cours	Négatif significatif
Qualité	Tout OK	Indicateurs mineurs	Tout OK ou données insuffisantes	SRM ou indicateurs critiques
Garde-fous	Propres	1 régression à corriger	Propres ou pas assez de données	Régression significative sur métrique critique
État expérience	Terminée	Terminée	En cours	Terminée ou en cours

4b : Expériences en cours (surveillance, aucune action requise)

Pour les expériences avec le verdict Surveiller, fournissez un statut d'une ligne chacune :

---
### Expériences en cours

**[Nom]** — En cours depuis [X]j, Contrôle : [N] / Traitement : [N]. [Statut de la métrique principale — par ex., « tendance positive (+3,3 %) mais pas encore significative »]. Qualité des données propre. [Lien]

**[Nom]** — En cours depuis [X]j, Contrôle : [N] / Traitement : [N]. Trop tôt pour des conclusions — [raison, par ex., « les tailles d'échantillon sont dans la plage 100-1 000 »]. [Lien]

Gardez ces éléments concis — une ligne par expérience. Incluez le lien à la fin pour quiconque souhaite vérifier dans Amplitude.

4c : Récemment décidées (résumés brefs)

Pour les expériences avec le verdict Décidé : Livrer ou Décidé : Ne pas livrer :

---
### Récemment décidées

- **[Nom]** — [Livrée/Annulée] le [date] après [X] jours. [Une phrase sur le résultat ou la justification]. [Lien]

Si l'expérience a été livrée sans métriques ou sans significativité statistique, notez-le brièvement.

4d : Nécessite configuration

Pour les expériences avec le verdict Corriger config, Nécessite métriques ou N/A :

---
### Nécessite configuration

- **[Nom]** — [Description du problème]. Propriétaire : [propriétaire].
- **[Nom]** — Déploiement d'enquête/incitation, pas une expérience de fonctionnalité. Aucune analyse requise.

Chaque expérience apparaît dans exactement une section de détail. Ne listez PAS une expérience à la fois dans les actions du tableau récapitulatif ET dans une section de détail avec les mêmes informations — la section de détail développe l'élément d'action, elle ne le répète pas.

---

Cas extrêmes

• Aucune expérience : Rapportez clairement, suggérez de vérifier d'autres projets
• Aucune donnée (<24h) : Notez que l'expérience vient de commencer, revenez dans 7 jours
• SRM détecté : Commencez par cela dans la qualité des données — cela peut invalider tout le reste
• 10+ expériences : Tableau récapitulatif pour toutes, analyse approfondie des 3 premières, proposez d'en analyser plus
• Réponse trop volumineuse / enregistrée sur disque : Extrayez uniquement summary + indicateurs de validité
• Aucune métrique configurée : Listez dans la section « Nécessite configuration », ne faites pas d'analyse approfondie
• Toutes les expériences sont périmées : Rapportez qu'il n'y a aucune expérience active à surveiller
• Erreur de requête de query_experiment : Rapportez l'erreur clairement avec le nom du propriétaire de l'expérience. Signalez comme « Corriger config » dans le résumé. Causes courantes : propriété d'événement d'exposition cassée, clé d'expérience mal configurée.
• Allocation de trafic modifiée en cours d'expérience : Signalez dans la qualité des données. Comparez les pondérations actuelles à la distribution d'exposition cumulée. Notez quelles variantes ne reçoivent plus de trafic.
• Expériences d'enquête/incitation (NPS, etc.) : Notez dans le résumé comme N/A. Aucune analyse requise — sautez l'analyse approfondie.
• Trafic gravement déséquilibré (par ex., 5%/95% ou 0%/100%) : Signalez comme « Corriger config » — impossible de mener une expérience valide sans un groupe de contrôle significatif. Notez dans la section « Nécessite configuration » avec le propriétaire.