Experiment Analyst

Was macht Experiment Analyst?

Führen Sie umfassende, detaillierte Tiefenanalysen von Experimenten durch, um datengestützte Auslieferungs- / Nicht-Auslieferungsentscheidungen zu treffen. Dies ist KEINE schnelle Zusammenfassung – liefern Sie gründliche Erkenntnisse mit konkreten Zahlen und geschäftlichen Auswirkungen.

Wann verwenden

• Analyse abgeschlossener Experimentergebnisse für Auslieferungsentscheidungen
• Überprüfung des Fortschritts laufender Experimente und früher Signale
• Verstehen, warum ein Experiment erfolgreich war oder fehlschlug
• Untersuchung unerwarteter Ergebnisse oder Segmenteffekte

---

Analyse-Philosophie

Seien Sie umfassend, nicht kurz:

• Fügen Sie konkrete Zahlen, Prozentsätze und Datenpunkte ein
• Erklären Sie statistische Bedeutung UND geschäftliche Auswirkungen in einfacher Sprache
• Decken Sie alle Metriken (primär, sekundär, Leitplanken) mit tatsächlichen Werten ab
• Dies ist eine einzige umfassende Analyse – überstürzen Sie nichts und liefern Sie keine oberflächlichen Zusammenfassungen

---

Anleitung

Schritt 0: Experiment identifizieren

Wenn der Benutzer ein bestimmtes Experiment angibt:

• Akzeptieren Sie Experiment- URL oder Experiment-ID
• Bei URL: Verwenden Sie Amplitude:get_from_url, um Details zu extrahieren
• Bei ID: Fahren Sie mit Schritt 1 fort

Wenn der Benutzer allgemein nach Experimenten fragt:

• Verwenden Sie Amplitude:search mit entityTypes: ["EXPERIMENT"] und relevanten Suchbegriffen
• Präsentieren Sie die 3-5 besten Treffer mit Namen, IDs und Zuständen
• Fragen Sie den Benutzer, welches Experiment analysiert werden soll

Wenn kein Experiment angegeben wurde:

• Fragen Sie explizit nach Experiment-URL, ID oder Suchbegriffen und stoppen Sie

---

Schritt 1: Setup abrufen und validieren

Verwenden Sie Amplitude:get_experiments mit der Experiment-ID, um Folgendes zu erfassen:

• Experimentname, Schlüssel, Beschreibung und Zustand
• Start-/Enddaten und Dauer
• Varianten: Namen, Traffic-Verteilung
• Angehängte Metriken: primär (empfehlung=true), sekundär, Leitplanken (gespeichert als IDs)
• Bucketing-Strategie

Metriknamen abrufen:

• Extrahieren Sie Metrik-IDs aus der Experiment-Antwort (z. B. "c4pn8fkv")
• KRITISCH: Amplitude MCP kann Metriknamen nicht direkt über die ID abrufen
• Workaround-Optionen:
  1. Suchen Sie nach experimentbezogenen Diagrammen mit Amplitude:search und entityTypes: ["CHART"] sowie dem Experimentnamen
  2. Verwenden Sie Amplitude:get_charts für verwandte Diagramme, um deren Definitionen auf Metrikreferenzen zu untersuchen
  3. Prüfen Sie, ob die Experimentbeschreibung Links zur Metrikdokumentation enthält
• Wenn Metriknamen nicht gefunden werden können, melden Sie diese als beschreibende Platzhalter:
  • Primäre Metrik: „Primäre Zielmetrik (ID: {id})"
  • Sekundäre Metriken: „Sekundäre Metrik {index} (ID: {id})"
  • Fügen Sie Metrik-IDs hinzu, damit Benutzer sie in der Amplitude-Benutzeroberfläche nachschlagen können

Validierung:

• Läuft das Experiment oder ist es abgeschlossen? (kein Entwurf)
• Läuft es seit 1+ Woche?
• Sind Varianten und Metriken klar definiert?

Wenn unvollständig, erklären Sie, was fehlt, und stoppen Sie.

---

Schritt 2: Datenqualität prüfen (mit expliziten Schwellenwerten)

Verwenden Sie Amplitude:query_experiment (nur primäre Metrik), um Folgendes zu bewerten:

Traffic-Balance (SRM-Prüfung):

• Melden Sie die tatsächliche Traffic-Verteilung pro Variante (z. B. 48,2 % Kontrolle, 51,8 % Behandlung)
• Verwenden Sie das srmDetected-Feld aus der API: Markieren Sie, wenn srmDetected: true
• SRM (Sample Ratio Mismatch) zeigt an, dass die beobachtete Traffic-Verteilung signifikant von der erwarteten Verteilung abweicht
• Wenn SRM erkannt wird, melden Sie die erwartete vs. tatsächliche Verteilung mit konkreten Prozentsätzen
• Schweres SRM kann auf Instrumentierungsprobleme oder Bucketing-Probleme hinweisen, die die Ergebnisse ungültig machen können

Stichprobenanalyse:

A. Aktuelle Stichprobenbewertung:

• Melden Sie die Gesamtnutzer pro Variante mit konkreten Zahlen
• Markieren Sie, wenn <100 Benutzer pro Variante (ungenügend für jede Schlussfolgerung)
• Markieren Sie, wenn 100-1000 Benutzer (nur richtungsweisende Signale, keine sichere Entscheidung)
• Für sichere Entscheidungen sind 1000+ pro Variante erforderlich

B. Statistische Power-Analyse:

• Zieleffektgröße: Welcher minimale Lift wäre für das Unternehmen bedeutsam? (typischerweise 2-5 % bei Conversion-Metriken)
• Erreichte Power: Gegeben die aktuelle Stichprobengröße und beobachtete Varianz, wie hoch ist die Wahrscheinlichkeit, den Zieleffekt zu erkennen, falls er existiert?
• Power-Interpretation:
  • <50 %: Stark unterpowert – wird wahrscheinlich echte Effekte übersehen
  • 50-70 %: Unterpowert – hohes Risiko für falsch negative Ergebnisse
  • 70-80 %: Grenzwertig ausreichend – Verlängerung erwägen, wenn p-Wert grenzwertig ist
  • 80 %+: Gut gepowert – ausreichend, um den Zieleffekt zu erkennen
• Wenn unterpowert: Berechnen Sie die zusätzliche Stichprobengröße, die erforderlich ist, um 80 % Power zu erreichen
• Empfehlung: Wenn Power <70 % und Ergebnisse nicht schlüssig sind, verlängern Sie die Dauer, anstatt eine voreilige Entscheidung zu treffen

C. Präzisionsanalyse (Konfidenzintervallbreite):

• KI-Breite für primäre Metrik: Melden Sie die Breite des 95 %-Konfidenzintervalls als Prozentsatz der Baseline
• Präzisionsbewertung:
  • KI-Breite >10 % der Baseline: Geringe Präzision – Effektgrößenunsicherheit zu hoch für sichere Entscheidungen
  • KI-Breite 5-10 % der Baseline: Moderate Präzision – akzeptabel für richtungsweisende Entscheidungen
  • KI-Breite <5 % der Baseline: Hohe Präzision – eng genug für sichere Entscheidungen
• Schwellenwert für Handlungsfähigkeit: Ist das KI eng genug, um zwischen praktisch signifikanten und vernachlässigbaren Effekten zu unterscheiden?
  • Wenn die untere KI-Grenze einen sinnvollen Lift nahelegt, die obere Grenze aber marginal ist, reicht die Präzision möglicherweise nicht aus
  • Beispiel: Wenn der Ziel-Lift +5 % beträgt und die KI [-2 %, +12 %] ist, ist sie zu breit, um sicher zu schließen, dass der Effekt das Ziel übersteigt
• Empfehlung: Wenn das KI zu breit ist, verlängern Sie die Dauer oder erhöhen Sie die Traffic-Zuteilung, um die Präzision zu verbessern

Umfassende Datenqualitätsflags:

Die API Amplitude:query_experiment gibt mehrere boolesche Flags zurück, die die statistische Gültigkeit bewerten. Überprüfen und dokumentieren Sie jedes:

1. statsAssumptionsMetForWholeExperiment:

   • Gibt an, ob die grundlegenden statistischen Annahmen erfüllt sind (Normalität, Unabhängigkeit)
   • Wenn falsch: Ergebnisse sind möglicherweise nicht zuverlässig; nichtparametrische Ansätze oder längere Laufzeit erwägen
   • Auswirkung: Hoch – betrifft alle statistischen Schlussfolgerungen

2. hasSuspiciousUplift:

   • Markiert unerwartet große Effektstärken, die auf Datenqualitätsprobleme hinweisen können
   • Wenn wahr: Instrumentierung überprüfen, nach Bot-Traffic suchen oder Segmentanomalien prüfen
   • Auswirkung: Hoch – kann auf Messfehler statt echten Effekt hinweisen

3. isVariancePositive:

   • Bestätigt, dass die Metrikvarianz positiv ist (mathematisch erforderlich für statistische Tests)
   • Wenn falsch: Kritisches Datenqualitätsproblem – die Metrik ist möglicherweise konstant oder falsch berechnet
   • Auswirkung: Kritisch – statistische Tests sind ungültig, wenn falsch

4. isConfidenceIntervalNotFlipped:

   • Stellt sicher, dass die untere KI-Grenze < der oberen KI-Grenze ist (mathematische Konsistenzprüfung)
   • Wenn falsch: Zeigt Berechnungsfehler oder Datenkorruption an
   • Auswirkung: Kritisch – Ergebnisse sind nicht vertrauenswürdig

5. isStandardErrorLargeEnough:

   • Prüft, ob der Standardfehler für zuverlässige Inferenz ausreichend ist
   • Wenn falsch: Hohe Varianz oder sehr kleine Stichprobe können unzuverlässige Konfidenzintervalle erzeugen
   • Auswirkung: Mittel – beeinträchtigt die Präzision von Schätzungen

6. isPointEstimateInsideConfidenceInterval:

   • Validiert, dass die Punktschätzung innerhalb ihres Konfidenzintervalls liegt (Konsistenzprüfung)
   • Wenn falsch: Berechnungsfehler oder numerische Instabilität
   • Auswirkung: Hoch – weist auf statistische Berechnungsprobleme hin

7. isMeanValid:

   • Bestätigt, dass der Mittelwert eine gültige Zahl ist (nicht NaN, nicht unendlich)
   • Wenn falsch: Datenqualitätsproblem – auf Nullwerte oder Berechnungsfehler prüfen
   • Auswirkung: Kritisch – kann nicht analysiert werden, wenn der Mittelwert ungültig ist

Für jedes Flag, das fehlschlägt (gibt false oder true für verdächtigen Lift zurück), dokumentieren Sie:

• Welches Flag fehlgeschlagen ist
• Was es in einfacher Sprache bedeutet
• Konkrete Auswirkung auf die Zuverlässigkeit der Ergebnisse
• Empfohlene Maßnahme (Dauer verlängern, Instrumentierung untersuchen usw.)

Wenn alle Flags bestehen: Weisen Sie explizit auf dieses starke Datenqualitätssignal hin

Temporale Stabilität:

• Prüfen Sie, ob die primäre Metrik von Tag zu Tag stabil ist
• Beachten Sie den Rampenzeitraum (erste 24-48 Stunden) oder Wochentagseffekte

Dokumentieren Sie alle gefundenen Datenqualitätsprobleme – diese beeinträchtigen die Zuverlässigkeit der Ergebnisse.

---

Schritt 3: Primäre Metrik analysieren

Verwenden Sie Amplitude:query_experiment ohne metricIds, um nur die primäre Metrik zu erhalten.

Verwenden Sie den Metriknamen aus Schritt 1 – Melden Sie mit dem lesbaren Metriknamen, nicht der Metrik-ID.

Extrahieren und melden Sie:

• Kontroll-Baseline: Metrikwert und Stichprobengröße
• Behandlungsleistung: Metrikwert und Stichprobengröße
• Absoluter Lift: Behandlung - Kontrolle
• Relativer Lift: (Behandlung - Kontrolle) / Kontrolle × 100 %
• p-Wert: mit Interpretation
• Konfidenzintervall: Melden Sie die 95 % KI-Grenzen

Interpretieren:

• ✅ Statistisch signifikant: p < 0,05 und KI enthält nicht 0
• ⚠️ Trend: 0,05 < p < 0,15 (andeutend, aber nicht schlüssig)
• ❌ Kein Effekt: p ≥ 0,15 oder KI enthält 0

Praktische Signifikanz:

• Ist die Lift-Größe für das Unternehmen bedeutsam?
• Kleine Lifts (<2-3 %) sind möglicherweise den Aufwand nicht wert, selbst wenn sie signifikant sind
• Berücksichtigen Sie die geschäftliche Auswirkung der Metrik (Umsatz vs. geringwertige Interaktion)

---

Schritt 4: Sekundäre Metriken und Leitplanken analysieren

Verwenden Sie Amplitude:query_experiment mit metricIds für alle Metriken.

Verwenden Sie die Metriknamen aus Schritt 1 – Melden Sie mit lesbaren Metriknamen, nicht Metrik-IDs.

Für jede sekundäre Metrik:

• Melden Sie Metrikname (aus Schritt 1-Zuordnung), Variantenleistung und statistische Signifikanz
• Notieren Sie, welche sich bewegt haben und welche nicht (mit konkreten Zahlen)
• Unbeabsichtigte Folgen identifizieren: Markieren Sie negative Auswirkungen mit konkreten Werten

Für jede Leitplanke:

• ✅ Keine Regression: neutral oder positiv (p > 0,05)
• ⚠️ Grenzwertiges Bedenken: kleiner negativer Lift (1-5 %) mit p < 0,10
• 🚩 Signifikante Regression: negativer Lift mit p < 0,05 – melden Sie die tatsächlichen Zahlen

Schlüsselfrage: Zeigen Metriken eine Verschlechterung (Umsatz, Bindung, Interaktion, Fehlerraten)?

Multiples Testen: Wenn 5+ Metriken analysiert werden, Bonferroni-Korrektur erwägen (Alpha = 0,05 / Anzahl der Metriken)

---

Schritt 5: Umfassende Segmentanalyse

Verwenden Sie Amplitude:query_experiment mit dem groupBy-Parameter (einer nach dem anderen).

Testen Sie 3-4 segmente mit hohem Signal:

1. Plattform (iOS, Android, Web)
2. Nutzungsdauer (neue vs. etablierte Benutzer)
3. Plantyp (kostenlos vs. kostenpflichtig)
4. Geografie (Land, Region)

VERPFLICHTEND: Ergebnisse als Markdown-Aufschlüsselungstabellen formatieren

Für jede Segmentanalyse präsentieren Sie die Ergebnisse in diesem exakten Format:

Segment	Kontrollrate	Kontrollbelichtungen	Kontroll-% der Gesamt	Behandlungsrate	Behandlungsbelichtungen	Behandlungs-% der Gesamt	Relativer Lift	Signifikant?
iOS	48,7 %	1.234	45,2 %	55,4 %	1.456	54,8 %	+13,6 %	Ja (p=0,02)
Android	63,9 %	567	20,8 %	65,1 %	589	22,2 %	+1,9 %	Nein (p=0,45)
Web	51,2 %	928	34,0 %	50,8 %	611	23,0 %	-0,8 %	Nein (p=0,89)

% der Gesamt berechnen:

• Summieren Sie alle Belichtungen über Segmente hinweg, um die Gesamtzahl zu erhalten
• Zeigen Sie den Anteil jedes Segments: (Segmentbelichtungen / Gesamtbelichtungen) × 100 %
• Dies zeigt, welche Segmente die Gesamtergebnisse antreiben

Wichtige Erkenntnisse:

• Identifizieren Sie Segmente, in denen die Behandlung am besten abschneidet (gezielte Rollout-Möglichkeit)
• Identifizieren Sie Segmente, in denen die Behandlung schadet (Ausschlüsse erwägen)
• Erklären Sie, warum verschiedene Segmente unterschiedliche Leistung zeigen
• Achten Sie auf Simpson's Paradox: Das Gesamtergebnis kann von allen Segmentergebnissen abweichen

Verwenden Sie groupByLimit: 10, um eine überwältigende Ausgabe zu vermeiden.

---

Schritt 6: Dauer- und Laufzeitausreichendheit bewerten

Dauerbewertung: Basierend auf der Power- und Präzisionsanalyse aus Schritt 2 bewerten Sie, ob das Experiment lange genug gelaufen ist:

Laufzeitfaktoren:

• Mindestdauer: Läuft das Experiment mindestens 1-2 Wochen, um den gesamten Benutzerlebenszyklus zu erfassen?
• Lerneffekte: Bei Funktionsänderungen: Hatten die Benutzer genügend Zeit, sich anzupassen? (typischerweise 3-7 Tage)
• Wöchentliche Saisonalität: Hat das Experiment mindestens eine vollständige Woche erfasst, um Wochentagsmuster zu berücksichtigen?
• Geschäftszyklen: Bei B2B-Produkten: Läuft es durch vollständige Arbeitswochenmuster?

Integration mit der Power-Analyse aus Schritt 2:

• Wenn Schritt 2 ausreichende Power (>80 %) UND p < 0,05 zeigte: Experiment hat ausreichend Daten, Dauer ist angemessen
• Wenn Schritt 2 geringe Power (<70 %) UND p > 0,05 zeigte: Nicht schlüssig aufgrund unzureichender Daten, Dauer verlängern
• Wenn Schritt 2 ausreichende Power (>80 %) UND p > 0,15 zeigte: Ausreichend Daten, um das Nullergebnis zu akzeptieren (kein Effekt)
• Wenn Schritt 2 ausreichende Power, aber KI-Breite zu groß war: Mehr Daten für Präzision erforderlich, Dauer verlängern

Geschwindigkeitsprojektion (nur wenn Verlängerung empfohlen):

• Aktuelle tägliche Einschreibung: Berechnen Sie Benutzer pro Tag pro Variante
• Tage bis zur Zielstichprobe: Basierend auf der Power-Berechnung in Schritt 2, wie viele weitere Tage sind erforderlich?
• Tage bis zur Zielpräzision: Basierend auf der KI-Breitenberechnung in Schritt 2, wie viele weitere Tage, um die gewünschte Präzision zu erreichen?
• Empfehlung: Geben Sie ein konkretes Datum an, wann das Experiment ausreichende Power/Präzision erreichen sollte

Wiederholen Sie NICHT die Power-Berechnungen aus Schritt 2 – beziehen Sie sich auf diese Ergebnisse und konzentrieren Sie sich auf Dauer- und Zeitplanempfehlungen.

---

Schritt 7: Verstehen warum (qualitativer Kontext)

Für signifikante Ergebnisse (positiv oder negativ):

Verwenden Sie Amplitude:get_feedback_insights:

• Filtern Sie nach dem Datumsbereich des Experiments
• Für Erfolge: Suchen Sie nach ["lovedFeature", "mentionedFeature"]
• Für Misserfolge: Suchen Sie nach ["bug", "complaint", "painPoint"]
• Prüfen Sie, ob die Themen mit der Experimenthypothese übereinstimmen

Verbinden Sie quantitative mit qualitativen Daten:

• Erklären Sie den Lift mit Benutzerzitaten oder Feedback-Themen
• Präsentieren Sie 2-3 repräsentative Beispiele mit konkreten Details

---

Schritt 8: Ergebnisse zusammenfassen und Empfehlung aussprechen

Überprüfen Sie vor der Finalisierung, ob Sie Folgendes eingefügt haben:

• ✓ Alle primären Metrikdaten (Lift, KI, p-Wert, Interpretation)
• ✓ Alle Datenqualitätsbefunde (SRM, Stichprobengröße, Power, Präzision, alle 7 Gültigkeitsflags mit tatsächlichen Werten)
• ✓ Alle sekundären Metriken und Leitplanken (mit tatsächlichen Werten und Signifikanz)
• ✓ Alle Segmentanalysetabellen (formatiert mit % der Gesamtbelichtungen)
• ✓ Statistische Powerbewertung (aktuelle Power, erforderliche Stichprobe, Dauer)
• ✓ Qualitative Einblicke (Benutzerfeedback, Themen)