O Investigador de Anomalias de Métricas: Transforme um Pico ou Queda Repentina de KPI em uma Lista Ranqueada de Causas Raiz Prováveis
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.
Uma métrica se move — uma taxa de conversão cai, um pico aparece nas taxas de erro, os usuários ativos diários estagnam — e o primeiro instinto na maioria das equipes é começar a verificar causas na ordem que vier à mente. Isso geralmente significa verificar a causa mais óbvia ou a mais discutida recentemente primeiro, mesmo quando ela não é a mais provável estatisticamente dado o padrão real da anomalia.
O que este prompt faz
Este prompt atua como um analista de dados realizando uma triagem estruturada. Você descreve a anomalia — qual métrica se moveu, em quanto, quais segmentos são afetados versus não afetados, e o que mudou recentemente em seus sistemas — e ele retorna uma lista ranqueada das causas raiz mais prováveis, cada uma com uma verificação específica e concreta que você pode executar para confirmá-la ou descartá-la. Ele não apenas adivinha causas; ele raciocina a partir do padrão de evidências específico que você fornece, distinguindo entre hipóteses que explicam todas as evidências e aquelas que explicam apenas parte delas.
Por que a estrutura importa
O prompt é deliberadamente construído em torno da correspondência de evidências, em vez de uma lista de verificação genérica. Uma queda acentuada, sustentada e apenas em mobile aponta para uma causa técnica (um Deploy Regression, uma Webhook Failure); uma queda gradual e ampla aponta para uma explicação de mercado ou sazonal. Forçar o modelo a explicar por que cada causa se encaixa nas evidências específicas — não apenas que é uma causa plausível em geral — é o que transforma uma lista de palpites em uma ferramenta de triagem real.
Como adaptá-lo
Preencha o nome da métrica, a forma específica da anomalia, sua segmentação se você a tiver, e quaisquer mudanças conhecidas (deploys, início/término de campanhas, mudanças de preço) na janela afetada. Se você ainda não tem dados de segmento, diga isso explicitamente — o prompt levará essa lacuna em consideração em seus rótulos de confiança, em vez de assumir um padrão de segmento que não existe. Quanto mais específico for seu input, mais a lista ranqueada apontará para causas genuinamente prováveis em vez de genéricas.