Der Metrik-Anomalie-Ermittler: Verwandle einen plötzlichen KPI-Anstieg oder -Abfall in eine rangierte Liste wahrscheinlicher Ursachen
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.
Eine Metrik bewegt sich – eine Conversion-Rate sinkt, ein Spike erscheint in Fehlerraten, täglich aktive Nutzer stagnieren – und der erste Instinkt in den meisten Teams ist, mit der Überprüfung von Ursachen in der Reihenfolge zu beginnen, die einem in den Sinn kommt. Das bedeutet normalerweise, zuerst die offensichtlichste oder die zuletzt diskutierte Ursache zu prüfen, selbst wenn sie angesichts des tatsächlichen Musters der Anomalie nicht die statistisch wahrscheinlichste ist.
Was dieser Prompt tut
Dieser Prompt fungiert als Datenanalyst, der eine strukturierte Triage durchführt. Sie beschreiben die Anomalie – welche Metrik sich bewegt hat, um wie viel, welche Segmente betroffen versus nicht betroffen sind und was sich kürzlich in Ihren Systemen geändert hat – und er gibt eine rangierte Liste der wahrscheinlichsten Ursachen zurück, jede mit einem spezifischen, konkreten Check, den Sie ausführen können, um sie zu bestätigen oder auszuschließen. Er rät nicht nur Ursachen; er schlussfolgert aus dem von Ihnen bereitgestellten spezifischen Evidenzmuster und unterscheidet zwischen Hypothesen, die alle Evidenzen erklären, und solchen, die nur einen Teil erklären.
Warum die Struktur wichtig ist
Der Prompt ist bewusst um den Abgleich von Evidenzen herum aufgebaut, nicht um eine generische Checkliste. Ein scharfer, anhaltender, nur auf Mobilgeräten auftretender Abfall deutet auf eine technische Ursache hin (eine Deploy Regression, ein Webhook Failure); ein allmählicher, breit angelegter Abfall deutet auf eine Markt- oder saisonale Erklärung hin. Das Modell dazu zu zwingen, zu erklären, warum jede Ursache zu den spezifischen Evidenzen passt – nicht nur, dass sie allgemein plausibel ist – ist das, was eine Liste von Vermutungen in ein echtes Triage-Werkzeug verwandelt.
Wie man es anpasst
Füllen Sie den Metriknamen, die spezifische Form der Anomalie, Ihre Segmentaufteilung (falls vorhanden) und alle bekannten Änderungen (Deploys, Kampagnenstarts/-enden, Preisänderungen) im betroffenen Zeitfenster aus. Wenn Sie noch keine Segmentdaten haben, sagen Sie dies explizit – der Prompt wird diese Lücke in seinen Konfidenzlabels berücksichtigen, anstatt ein Segmentmuster anzunehmen, das nicht existiert. Je spezifischer Ihre Eingabe, desto mehr wird die rangierte Liste auf wirklich wahrscheinliche Ursachen verweisen statt auf generische.