L'Enquêteur d'Anomalies Métriques : Transformez un Pic ou une Chute Soudaine de KPI en une Liste Classée des Causes Racines Probables
Why this prompt matters
Teams without a structured triage process burn 2-3 days chasing anomalies in the wrong order, checking the most obvious cause first even when it's not the most statistically likely one. A ranked, evidence-based starting list turns a multi-day scavenger hunt into a 30-minute focused investigation, and stops teams from declaring a false root cause and shipping a fix that doesn't address the real problem.
What we use it for
Your weekly signup dashboard shows conversions dropped 18% starting Tuesday. You don't know if it's a pricing page bug, a marketing campaign that ended, a competitor promotion, seasonality, or a tracking error — and your team is about to spend the next two days randomly checking each one.
Prompt
Act as [YOUR ROLE, e.g., a senior data analyst / growth analytics lead] investigating a metric anomaly for [YOUR COMPANY/PRODUCT NAME]. Context: - Metric affected: [METRIC NAME, e.g., signup conversion rate, daily active users, checkout completion rate] - What happened: [DESCRIBE THE ANOMALY — e.g., "dropped from 4.2% to 3.4% starting Tuesday July 22, held flat through Friday"] - Normal baseline and recent trend: [PASTE 2-4 WEEKS OF BASELINE NUMBERS OR DESCRIBE THE TREND] - Segments affected vs unaffected: [E.G., "mobile down 30%, desktop unchanged" OR "unknown — haven't segmented yet"] - Known changes in the affected window: [LIST ANY DEPLOYS, MARKETING CAMPAIGN START/END DATES, PRICING CHANGES, THIRD-PARTY INTEGRATION UPDATES, OR SAY "none known"] - Systems involved: [E.G., "Stripe checkout, Segment tracking, a React frontend, a Postgres-backed API"] Task: 1. Generate a ranked list of the 6-10 most likely root causes for this specific anomaly, ordered from most to least probable given the context above. 2. For each cause, provide: - A one-sentence explanation of why it's plausible given the specific evidence provided (not generic reasoning) - A confidence label: High / Medium / Low - One specific, concrete check that would confirm or rule it out (e.g., "check Stripe webhook logs for failed payment_intent events between 2pm-6pm Tuesday" — not "check the payment system") 3. Flag any causes that would explain ALL the evidence versus causes that only explain part of it. 4. If the evidence is ambiguous between two or more causes, say so explicitly and specify what additional data would break the tie. Constraints: - Do not default to the most common textbook cause (e.g., "seasonality") unless the evidence specifically supports it over more specific alternatives. - Do not suggest checks that require data I haven't mentioned having access to — if you need to assume a tool exists (e.g., session replay), say so explicitly as an assumption. - Distinguish clearly between correlation-based hypotheses (something else changed at the same time) and causal hypotheses (this specific thing broke this specific metric). Output format: - A numbered, ranked list (most likely first) - Each entry: Cause name — Confidence — Reasoning (1-2 sentences) — Specific check to run - A closing section: "If none of the above confirm, check next:" with 2-3 lower-probability fallback hypotheses
Result
Ranked Root Cause Analysis: Checkout Conversion Drop (4.2% → 3.4%, starting Tuesday July 22)
- Payment processor webhook failure — Confidence: High. The drop is sharp and sustained rather than gradual, which is more consistent with a technical failure than a demand-side shift, and mobile being disproportionately affected (30% down vs. desktop unchanged) points to a client-specific integration issue rather than a market-wide one. Check: Pull Stripe's webhook delivery logs for `payment_intent.succeeded` and `payment_intent.payment_failed` events between Monday 6pm and Tuesday 6pm, filtered by client type, and compare delivery success rates to the prior week.
- Mobile checkout deploy regression — Confidence: High. If a mobile-specific frontend or checkout-flow deploy went out Monday night or Tuesday morning, this is the single most common cause of a mobile-only conversion drop with no corresponding desktop change. Check: Pull the deploy log for the mobile checkout repo for the 24 hours before the drop started; specifically look for changes to form validation, the payment button component, or any A/B test flag flips.
- Third-party tracking/tag manager misfire — Confidence: Medium. If Segment or a tag manager script started failing to fire the conversion event (rather than the conversion itself failing), you'd see an identical-looking drop in the dashboard while actual revenue in Stripe stays flat — this needs to be ruled out before assuming a real business problem exists. Check: Compare Stripe's raw successful-charge count for the affected period against the analytics dashboard's conversion count; if Stripe shows normal revenue but the dashboard shows a drop, this is very likely a tracking issue, not a real conversion problem.
- New device/OS version compatibility issue — Confidence: Medium. A major mobile OS update rolling out that week could break a specific checkout component (e.g., Apple Pay sheet rendering, autofill behavior) for a subset of users without any deploy on your side. Check: Segment the affected mobile traffic by OS version and browser build number; look for a disproportionate drop concentrated in one specific version.
- Ended marketing campaign changing traffic mix — Confidence: Medium. If a high-intent paid campaign (e.g., a retargeting push) ended Monday, the resulting traffic mix shift toward lower-intent organic/direct visitors could lower the blended conversion rate without any technical fault at all — this would explain a sustained rather than momentary drop. Check: Compare the traffic source mix (paid vs. organic vs. direct) for the week before and after the drop, and calculate conversion rate within each source separately to see if per-source rates actually changed or if only the mix shifted.
- Competitor promotion or price change — Confidence: Low. This would explain a broad-based drop but doesn't naturally explain why mobile is disproportionately affected while desktop is flat, making it a weaker fit for this specific evidence pattern than the technical hypotheses above. Check: Search for competitor pricing or promotional announcements dated on or just before July 22, and check whether the drop is concentrated among returning versus new visitors (returning visitors would be more price-sensitive to a competitor's move).
Note on ambiguity: Causes #1 and #2 both explain the mobile-specific, sharp, sustained pattern equally well and can't be distinguished without the webhook and deploy logs — pull both simultaneously rather than sequentially to save a day of back-and-forth.
If none of the above confirm, check next: a CDN or DNS change affecting mobile asset load times specifically, a browser extension or ad-blocker update interfering with the payment iframe, or a change in the mobile app store review/rating that's suppressing new-user trust at the point of payment.
Une métrique bouge — un taux de conversion baisse, un pic apparaît dans les taux d'erreur, les utilisateurs actifs quotidiens stagnent — et le premier réflexe dans la plupart des équipes est de commencer à vérifier les causes dans l'ordre qui vient à l'esprit. Cela signifie généralement vérifier la cause la plus évidente ou la plus récemment discutée en premier, même lorsqu'elle n'est pas la plus statistiquement probable compte tenu du modèle réel de l'anomalie.
Ce que fait ce prompt
Ce prompt agit comme un analyste de données effectuant un tri structuré. Vous décrivez l'anomalie — quelle métrique a bougé, de combien, quels segments sont affectés par rapport aux non affectés, et ce qui a changé récemment dans vos systèmes — et il renvoie une liste classée des causes racines les plus probables, chacune avec une vérification spécifique et concrète que vous pouvez exécuter pour la confirmer ou l'exclure. Il ne se contente pas de deviner des causes ; il raisonne à partir du modèle de preuves spécifique que vous fournissez, en distinguant les hypothèses qui expliquent toutes les preuves de celles qui n'en expliquent qu'une partie.
Pourquoi la structure est importante
Le prompt est délibérément construit autour de la correspondance des preuves plutôt que d'une liste de contrôle générique. Une chute brutale, soutenue et uniquement sur mobile pointe vers une cause technique (une Deploy Regression, une Webhook Failure) ; une chute progressive et généralisée pointe vers une explication de marché ou saisonnière. Forcer le modèle à expliquer pourquoi chaque cause correspond aux preuves spécifiques — et pas seulement que c'est une cause plausible en général — est ce qui transforme une liste de suppositions en un véritable outil de tri.
Comment l'adapter
Remplissez le nom de la métrique, la forme spécifique de l'anomalie, votre ventilation par segment si vous en avez une, et tout changement connu (déploiements, débuts/fins de campagnes, changements de prix) dans la fenêtre affectée. Si vous n'avez pas encore de données de segment, dites-le explicitement — le prompt prendra en compte cet écart dans ses étiquettes de confiance plutôt que de supposer un modèle de segment qui n'existe pas. Plus votre entrée est spécifique, plus la liste classée pointera vers des causes réellement probables plutôt que génériques.