amplitude/builder-skills

Experiment-Monitor & Berichtsgenerator

Scannen Sie aktive und kürzlich abgeschlossene Experimente, heben Sie hervor, was Aufmerksamkeit benötigt, und berichten Sie über die, die wichtig sind.

Dies ist ein Überwachungs-Skill – halten Sie die Ergebnisse für Nicht-Experten zugänglich. Vermeiden Sie statistische Fachausdrücke (keine p-Werte, keine Power-Analyse). Für eine detaillierte Analyse eines bestimmten Experiments verwenden Sie stattdessen den Skill analyze-experiments.

---

WICHTIG: Verwaltung der Antwortgrößen

1. get_experiments: Maximal 3-5 IDs pro Aufruf. FILTERN Sie die Ergebnisse der search-Abfrage, BEVOR Sie abrufen.
2. query_experiment-Antworten sind umfangreich. Extrahieren Sie nur die summary-Objekte und Validitätsflags. Ignorieren Sie timeseries, xValues und große Arrays.
3. Metriknamen-Auflösung: search findet KEINE Metrik-IDs in queries. Suchen Sie mit entityTypes: ["METRIC"], leeren queries, limitPerQuery: 50, auf das Projekt beschränkt. Ordnen Sie IDs aus den Ergebnissen zu.

---

Berichtsstruktur

Der Bericht besteht aus zwei Teilen:

1. Zusammenfassung & Aktionen (oben) – Eine Tabelle + Aktionspunkte. Jemand sollte nur diesen Teil lesen können und das vollständige Bild verstehen.
2. Details (unten) – Tiefgehende Analysen zu Experimenten, die Aufmerksamkeit benötigen, Kurzberichte zu kürzlich entschiedenen, Einzeiler zu beobachtenden Experimenten und eine Liste der Einrichtungsbedarfe.

Duplizieren Sie KEINE Informationen zwischen der Zusammenfassungstabelle und den Details. Die Zusammenfassungstabelle ist die einzige Quelle der Wahrheit für den Portfolio-Status. Die Details erweitern bestimmte Experimente.

---

Anweisungen

Schritt 1: Kontext & Entdeckung

1. Rufen Sie Amplitude:get_context auf. Wenn mehrere Projekte vorhanden sind, fragen Sie, welches überwacht werden soll.
2. Suchen Sie nach Experimenten:

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

3. Filterregeln – schließen Sie Experimente ein, die:
   • Laufen und nicht veraltet sind: Jedes Experiment in einem laufenden Zustand, das NICHT als veraltet markiert ist. Veraltete Experimente sind inaktiv und sollten ausgeschlossen werden.
   • Kürzlich entschieden wurden: Abgeschlossene Experimente, die eine Entscheidung aufgezeichnet haben UND innerhalb der letzten 14 Tage geändert wurden. Diese sind eine Überprüfung wert, um die Entscheidung zu bestätigen oder Erkenntnisse zu teilen.
4. Ausschließen: Entwürfe, deaktivierte Experimente und veraltete Experimente.

---

Schritt 2: Metadaten, Metriknamen & primäre Ergebnisse abrufen

1. Rufen Sie Amplitude:get_experiments in Batches von 3-5 IDs auf (nur die gefilterte Menge aus Schritt 1).
2. Extrahieren Sie: Status, Daten/Dauer, Varianten, Metrik-IDs (primär, wo Empfehlung=true), Entscheidung, Eigentümer.
3. Wenden Sie die Filterregeln aus Schritt 1 erneut an, diesmal mit detaillierten Metadaten (einige Felder wie veralteter Status oder Entscheidung sind möglicherweise nur hier verfügbar).
4. Lösen Sie Metriknamen über Amplitude:search({ entityTypes: ["METRIC"], appIds: [projectId], queries: [], limitPerQuery: 50 }) auf. Erstellen Sie eine { id: Name }-Zuordnung.
5. Rufen Sie für Experimente mit konfigurierten Metriken Amplitude:query_experiment({ id: "<id>" }) (ohne metricIds) auf, um primäre Metrikergebnisse und Datenqualitätsflags zu erhalten. Diese Daten speisen sowohl die Zusammenfassungstabelle als auch die tiefgehenden Analysen.

WICHTIG: Zeigen Sie dem Benutzer niemals rohe Metrik-IDs an. Wenn ein Metrikname nicht aufgelöst werden kann, beschreiben Sie ihn anhand seiner Rolle (z. B. „primäre Metrik“, „Guardrail-Metrik“) – zeigen Sie KEINE Zeichenfolgen wie „rrgtky08“ oder „Metrik gvgb5efj“ an. Metrik-IDs sind interne Kennungen, die für einen menschlichen Leser bedeutungslos sind.

---

Schritt 3: Zusammenfassung & Aktionen

Dies ist der obere Teil des Berichts. Er sollte in sich abgeschlossen sein – jemand, der nur diesen Abschnitt liest, erhält das vollständige Bild.

Zusammenfassungstabelle

## Experiment-Monitor: [Projektname]
Datum: [Heute] | Projekt: [Name] ([ID])

| Experiment | Status | Dauer | Lift | Votum |
|------------|--------|-------|------|-------|

Spaltendefinitionen:

• Experiment – Menschenlesbarer Name (KEINE URL, KEINE ID)
• Status – Läuft oder Abgeschlossen
• Dauer – Tage seit Start des Experiments
• Lift – Relativer Lift der primären Metrik, falls verfügbar, „—“ wenn keine Daten. Bei mehreren Varianten Bereich anzeigen (z. B. „-17% bis -20%“)
• Votum – Was zu tun ist (siehe Vokabular unten)

Votum-Vokabular:

Votum	Wann verwenden
Ausrollen	Signifikant positive primäre Metrik, Guardrails sauber, Datenqualität gut
Iterieren	Positives Signal, aber Guardrail-Regression oder Qualitätsbedenken
Beobachten	Läuft, noch nicht signifikant, kein Handlungsbedarf
Aufgeben	Signifikant negative primäre Metrik oder kritische Datenqualitätsprobleme
Entschieden: Ausrollen	Kürzlich abgeschlossen, Team hat sich für Ausrollen entschieden
Entschieden: Nicht ausrollen	Kürzlich abgeschlossen, Team hat sich gegen Ausrollen entschieden
Konfiguration reparieren	Abfragefehler, defektes Exposure-Event oder stark ungleicher Traffic
Benötigt Metriken	Läuft ohne Metriken – kann nicht bewertet werden
N/V	Umfragen-/Nudge-Bereitstellung, kein Feature-Experiment

Aktionspunkte (unmittelbar nach der Tabelle)

**Jetzt handeln:**
- [Experiment] – [spezifische Aktion mit Name des Eigentümers]

**Weiter beobachten:**
- [Experiment] – [kurzer Status + wann zurückkommen]

**Einrichtung erforderlich:**
- [Experiment] – [was fehlt + Name des Eigentümers]

Jedes Experiment aus der Tabelle sollte in genau einer Aktionskategorie erscheinen. Wenn es in einer Kategorie keine Experimente gibt, lassen Sie diese Kategorie weg.

---

Schritt 4: Details

Unterhalb der Zusammenfassung geben Sie zusätzliche Details, organisiert in Abschnitten. Jedes Experiment erscheint in GENAU EINEM Abschnitt – keine Duplikation.

4a: Tiefgehende Analysen (Experimente, die Aufmerksamkeit benötigen)

Tiefgehende Analyse für Experimente mit den Voten Ausrollen, Iterieren oder Aufgeben (maximal 3). Diese haben signifikante Ergebnisse, die einer Prüfung wert sind.

Geben Sie für jedes den vollständigen Bericht in einem Durchgang aus:

---
## [Experimentname]
[Status] | [Dauer]d | Kontrolle: [N] / Behandlung: [N] | [Link zum Experiment]

Datenqualität (zuerst – vor den Ergebnissen):

Überprüfen Sie die Datenqualität, BEVOR Sie Metrikergebnisse melden. Wenn es kritische Probleme gibt, benötigt der Leser diesen Kontext, bevor er Zahlen interpretiert.

Wenn alle Prüfungen bestanden sind, eine Zeile: „Alle Datenqualitätsprüfungen bestanden.“ Dann weiter zur primären Metrik.

Wenn Probleme gefunden wurden, melden Sie diese vor der primären Metrik:

### Datenqualität: [N Probleme gefunden]

SRM (Sample Ratio Mismatch):

• Verwenden Sie das Feld srmDetected aus der API-Antwort
• Wenn srmDetected: true: immer zuerst und prominent melden
• Melden Sie: tatsächliche Aufteilung vs. erwartete Aufteilung mit spezifischen Prozentangaben

Änderungen der Traffic-Verteilung:

• Vergleichen Sie die aktuellen Varianten-Gewichtungen mit der kumulativen Verteilung der Expositionen
• Wenn sie nicht übereinstimmen (z. B. aktuelle Gewichtungen sind 100/0/0, aber kumulativ ist 15/70/15), wurde die Verteilung während des Experiments geändert
• Kennzeichnen Sie dies prominent – es bedeutet, dass einige Varianten möglicherweise keinen neuen Traffic mehr erhalten

Stichprobengröße:

• <100 pro Variante: Als unzureichend kennzeichnen – zu früh für Schlussfolgerungen
• 100–1.000 pro Variante: Nur richtungsweisende Signale, nicht genug für sichere Entscheidungen
• 1.000+: Ausreichend für Analyse

Validitätsflags – nur Fehler melden:

Flag	Bedeutung bei Fehler	Schweregrad
isVariancePositive = false	Metrikdaten ungültig – statistische Tests können nicht ausgeführt werden	Kritisch
isConfidenceIntervalNotFlipped = false	Berechnungsfehler in den Ergebnissen – Zahlen nicht vertrauenswürdig	Kritisch
isMeanValid = false	Metrikwerte defekt (NaN/unendlich) – Analyse nicht möglich	Kritisch
statsAssumptionsMetForWholeExperiment = false	Statistische Annahmen nicht erfüllt – Ergebnisse möglicherweise unzuverlässig	Hoch
hasSuspiciousUplift = true	Ungewöhnlich großer Effekt – möglicherweise Messfehler, keine echte Veränderung	Hoch
isPointEstimateInsideConfidenceInterval = false	Interne mathematische Inkonsistenz – Ergebnisse möglicherweise falsch	Hoch
isStandardErrorLargeEnough = false	Zu viel Rauschen, um zuverlässige Schätzungen zu erhalten	Mittel

Wenn SRM erkannt wurde oder ein kritisches Flag fehlschlägt:

⚠️ Die folgenden Ergebnisse sollten aufgrund von [Problem] mit Vorsicht interpretiert werden.

Primäre Metrik:

### [Metrikname]: [Klartext-Votum]

| Variante | Wert | Lift | 95% KI |
|----------|------|------|--------|
| Kontrolle | [X] | — | — |
| Behandlung | [Y] | [+Z%] | [A% bis B%] |

[Ein Satz in Klartext interpretiert.]

Rahmenregeln:

• Keine p-Werte einfügen. Nicht-Experten wissen nicht, was sie bedeuten.
• Verwenden Sie „nicht signifikant“ anstelle von „keine Wirkung“. Es könnte einen Effekt geben – das Experiment kann ihn bei dieser Stichprobengröße nur nicht erkennen.
• Führen Sie mit dem, was passiert ist, in Klartext.

Votum-Wörter:

• Signifikant positiv – KI vollständig über Null, positiver Lift
• Signifikant negativ – KI vollständig unter Null, negativer Lift
• Nicht signifikant – KI enthält Null; wir können nicht mit Sicherheit sagen, dass es einen echten Unterschied gibt
• Trend positiv/negativ – Richtungsweisendes Signal, aber KI enthält Null; Beobachtung wert

Fügen Sie einen Satz zur praktischen Signifikanz nur hinzu, wenn der Lift sehr klein (<2%) oder sehr groß (>20%) ist.

Guardrails & Sekundäre Metriken:

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

Konzentrieren Sie sich darauf, Regressionen zu erkennen, nicht jede Metrik zu kommentieren.

Wenn keine signifikanten Regressionen: „Alle Guardrails und sekundären Metriken sind sauber – keine signifikanten Regressionen erkannt.“

Wenn signifikante Regressionen gefunden wurden:

- **[Metrikname]:** Signifikante Regression ([−X%], KI: [A% bis B%]) – [ein Satz zu den Auswirkungen]

Wenn große richtungsweisende Regressionen (>20% relativer Lift) vorliegen, die noch nicht signifikant sind:

- **[Metrikname]:** Nicht signifikant, aber richtungsweisend negativ ([−X%]) – Beobachtung wert

Kleine richtungsweisende Änderungen, die nicht signifikant sind, sollten weggelassen werden. Wenn 5+ Metriken, weisen Sie darauf hin, dass multiple Vergleiche die Wahrscheinlichkeit von Fehlalarmen erhöhen.

Feedback (nur wenn primäre Metrik signifikant ist):

Rufen Sie Amplitude:get_feedback_insights mit experimentbezogenen Schlüsselwörtern auf. Berichten Sie 2-3 Themen in je einem Satz. Wenn kein relevantes Feedback vorhanden ist, überspringen Sie den Abschnitt.

Votum:

### Votum: [AUSROLLEN / ITERIEREN / BEOBACHTEN / AUFGEBEN]
1. [Primäre Metrik-Erkenntnis – ein Satz]
2. [Qualitäts-/Guardrail-Status – ein Satz]
3. [Was als Nächstes zu tun ist – ein Satz]

Entscheidungsmatrix (interne Referenz, nicht ausgeben):

Signal	Ausrollen	Iterieren	Beobachten	Aufgeben
Primär	Signifikant positiv + praktisch	Signifikant positiv, aber Guardrail-Regression	Noch nicht signifikant, läuft noch	Signifikant negativ
Qualität	Alle bestanden	Kleinere Flags	Alle bestanden oder unzureichende Daten	SRM oder kritische Flags
Guardrails	Sauber	1 Regression muss behoben werden	Sauber oder nicht genug Daten	Signifikante Regression bei kritischer Metrik
Experimentstatus	Abgeschlossen	Abgeschlossen	Läuft	Abgeschlossen oder läuft

4b: Laufende Experimente (Beobachtung, kein Handlungsbedarf)

Für Experimente mit dem Votum Beobachten geben Sie jeweils einen einzeiligen Status:

---
### Laufende Experimente

**[Name]** – Läuft seit [X]d, Kontrolle: [N] / Behandlung: [N]. [Status der primären Metrik – z. B. „Trend positiv (+3,3%), aber noch nicht signifikant“]. Datenqualität sauber. [Link]

**[Name]** – Läuft seit [X]d, Kontrolle: [N] / Behandlung: [N]. Zu früh für Schlussfolgerungen – [Grund, z. B. „Stichprobengrößen liegen im Bereich 100-1.000