Amplitude-Diagramm erstellen
Erstelle Diagramme aus natürlicher Sprache, indem du Ereignisse entdeckst, Diagrammdefinitionen erstellst und Ergebnisse überprüfst.
Planung zuerst (Kritisch)
Vor jedem Tool-Aufruf: Zerlege die Anfrage.
1. Diagrammkomponenten identifizieren:
- Diagrammtyp und Metrik (was wird gemessen)
- Zeitraum (Standard: Letzte 30 Tage, falls nicht angegeben)
- Primäres Ereignis (die Aktion, die gezählt wird)
- Segmentbedingungen (Benutzerfilter/-gruppen)
- Filter, Gruppierungen, Aufschlüsselungen
- Trichter-Schritte (falls Konvertierungsanalyse)
2. Ereignissuche planen:
- EINE Suche pro eindeutigem Ereigniskonzept
- Niemals mehrere Konzepte in einer Suche kombinieren
- Beispiel: "Kauf" und "Anmeldung" benötigen separate Suchen
3. Parallele Tool-Aufrufe planen:
- Kontext abrufen, Ereignisse suchen, Kohorten finden können parallel laufen
- Warte auf Ergebnisse, bevor du die Definition erstellst
Ereignisentdeckung (Kritisch: Entdeckung zuerst)
WICHTIG: Ziehe ein weites Netz, bevor du eingrenzt
Wenn die Anfrage des Benutzers mehrdeutig ist oder auf mehrere Ereignisse abgebildet werden könnte:
- Suche zuerst BREIT, um relevante Optionen zu entdecken
- Überprüfe relevante Ergebnisse – suche nach verwandten Ereignissen, benutzerdefinierten Ereignissen, Meta-Ereignissen
- Präsentiere Optionen dem Benutzer ODER erkläre deine Auswahlbegründung
- Versuche nicht, ohne Erkundung anzunehmen, dass ein einzelnes Ereignis die einzige Antwort ist
Nach Ereignissen suchen:
Amplitude:search mit entity_types=['EVENT', 'CUSTOM_EVENT']
- Suche EIN Konzept nach dem anderen
- Verwende zuerst breite Suchbegriffe (z. B. "KI" nicht nur "KI-Chat")
- ✓ Gut: "Benutzer schließt Kauf ab"
- ✗ Schlecht: "Anmeldung oder Kaufereignisse"
Informierte Entscheidungen treffen, dann erklären:
- Breit suchen, um alle Optionen zu entdecken
- Ergebnisse überprüfen und den umfassendsten/genauesten Ansatz identifizieren
- Treffe eine fundierte Entscheidung (bevorzuge aggregierte benutzerdefinierte Ereignisse gegenüber einzelnen Ereignissen)
- Immer erklären: "Ich habe X, Y, Z Optionen gefunden. Ich habe [X] gewählt, weil [Grund]. Dies schließt [Umfang] ein/aus."
- Der Benutzer kann korrigieren, falls deine Annahme falsch war
Entscheidungskriterien:
- Bevorzuge benutzerdefinierte Ereignisse, die verwandte Aktivitäten aggregieren (z. B. "[2026] Aktivierungsmetrik [nur KI-Ereignisse]")
- Falls kein aggregiertes Ereignis existiert, wähle das primäre Interaktionsereignis
- Bedenke, was "aktiver Benutzer" für diesen Produktbereich typischerweise bedeutet
- Standardmäßig breiteren Umfang wählen, es sei denn, der Benutzer gibt eine enge Fokussierung vor
Beispiele:
- ❌ SCHLECHT: Benutzer fragt "wöchentliche KI-Benutzer" → sofort "KI-Chat: Nachricht senden" auswählen, ohne zu erkunden, keine Erklärung
- ✅ GUT: Benutzer fragt "wöchentliche KI-Benutzer" → nach "KI" suchen, KI fragen, Agents, Sichtbarkeit, benutzerdefiniertes aggregiertes Ereignis finden. Antworten: "Ich habe KI-Aktivitäten in KI fragen, Agents und Sichtbarkeit gefunden. Ich verwende das benutzerdefinierte Ereignis '[2026] Aktivierungsmetrik [nur KI-Ereignisse]', das alle KI-Produktinteraktionen umfasst. Dies gibt dir die Gesamtzahl der KI-Benutzer über alle Funktionen hinweg. Lass mich wissen, ob du dich auf ein bestimmtes KI-Produkt konzentrieren möchtest."
Vor der Verwendung überprüfen:
- Vorhandene Diagramme mit dem Ereignis über die Suche abrufen
- Prüfen, ob das Ereignis tatsächlich Volumen hat (nicht null/veraltet)
- Nach benutzerdefinierten Ereignissen suchen, die verwandte Aktivitäten aggregieren
- Bei Nullergebnissen nach Alternativen suchen
Eigenschaften abrufen:
Amplitude:get_event_properties für genaue Eigenschaftsnamen/-werte
Kohorten finden:
Amplitude:search mit entity_types=['COHORT']
Amplitude:get_cohorts, um vollständige Definitionen zu erhalten
Diagrammtyp-Auswahl
| Diagrammtyp | Verwende, wenn |
|---|---|
eventsSegmentation | Zählen von Ereignissen/Benutzern über Zeit, Trends, Vergleiche, KPIs, Verteilungen, Eigenschaftsanalysen |
funnels | Mehrstufige Konvertierungsanalyse mit einer bekannten Reihenfolge, Abbruchanalyse, Zeit zwischen bestimmten Ereignissen, Zeit-bis-Konvertierung-Metriken |
retention | Rückkehrverhalten von Benutzern, Kohorten-Bindungskurven, Abwanderungsanalyse |
dataTableV2 | Tabellarische Vergleiche, Rangfolgen, mehrdimensionale Aufschlüsselungen |
customerJourney | Pfaderkundung, Entdecken unbekannter Pfade, die Benutzer nehmen, Vergleich konvertierter vs. abgebrochener Pfade |
sessions | Sitzungsdauer, Sitzungshäufigkeit, Zeit pro Benutzer, Sitzungslängenverteilungen |
Kurzreferenz
eventsSegmentation – Am vielseitigsten. Verwende für:
- Benutzerzahlen (DAU, WAU, MAU) mit
uniques-Metrik - Ereignissummen, Durchschnitte, Summen von Eigenschaften
- Perzentile, Verteilungen, Formeln
- Zeitreihen mit gleitenden Fenstern
Aggregationsumfang (eventsSegmentation):
PROPSUM(A)/metric: "sums"= Globale Summe über ALLE Ereignisse hinwegmetric: "frequency"= Verteilung der Ereigniszahlen pro Benutzer (wie viele Benutzer haben es 1x, 2x, 3x getan)- Für "Verteilung der Eigenschaftssumme pro Benutzer": Amplitude unterstützt dies nicht direkt. Verwende
metric: "frequency"für Verteilungen der Ereigniszahlen oder dataTableV2 gruppiert nach user_id mit PROPSUM und exportiere für externe Analysen.
funnels – Konvertierungsanalyse mit vordefinierten Schritten. Verwende für:
- Schrittweise Konvertierungsraten, wenn die erwartete Reihenfolge bekannt ist
- Geordnete oder ungeordnete Sequenzen
- Zeit-bis-Konvertierung (durchschnittliche Zeit zwischen Ereignissen)
- Ausschlussereignisse, Konvertierungsfenster
- Überlappende Ereignisse: Um Benutzer zu finden, die mehrere Ereignisse (in beliebiger Reihenfolge) durchgeführt haben, verwende einen Trichter mit "beliebiger Reihenfolge" und setze das Konvertierungsfenster so, dass es dem Diagrammzeitraum entspricht
- Hinweis: Wenn du entdecken möchtest, welche Pfade Benutzer nehmen, verwende stattdessen
customerJourney
retention – Rückkehrverhalten. Verwende für:
- N-Tage- oder rollierende Bindungskurven
- Kohortenanalyse (neue vs. wiederkehrende Benutzer)
- Startereignis → Rückkehrereignis-Muster
dataTableV2 – Tabellarische Daten. Verwende für:
- Aufschlüsselungen nach Dimensionen (Land, Plattform usw.)
- Multi-Metrik-Vergleiche in Tabellenform
customerJourney – Pfaderkundung und -entdeckung. Verwende für:
- Verstehen der tatsächlichen Pfade, die Benutzer nehmen (vs. erwartete Pfade in Trichtern)
- Analyse von Pfaden, die mit einem bestimmten Ereignis beginnen, enden oder zwischen zwei Ereignissen liegen
- Vergleich von konvertierten und abgebrochenen Benutzerpfaden nebeneinander
- Entdecken unerwarteter Navigationsmuster oder Reibungspunkte
- Erkunden der Pfadhäufigkeit, -ähnlichkeit oder der durchschnittlichen Abschlusszeit
- Überbrückung der Lücke zwischen idealen Kundenreisen und tatsächlichem Benutzerverhalten
sessions – Sitzungsbasierte Engagement-Metriken. Verwende für:
- Sitzungsdaueranalyse (durchschnittliche Länge, verbrachte Zeit, Verteilungen)
- Sitzungshäufigkeit (durchschnittliche Sitzungen pro Benutzer, Gesamtsitzungen)
- Verbrachte Zeit pro Benutzer über Zeit
- Ereignisse innerhalb von Sitzungen (durchschnittliche Ereignisse pro Sitzung)
- Vergleich des Sitzungsverhaltens über Benutzersegmente hinweg
Spezielle Metriken:
- Benutzerzahlen:
metric: "uniques" - Ereigniszahlen:
metric: "totals" - Eigenschaftssummen:
metric: "sums"mit Eigenschaft ingroup_by - Raten/Prozentsätze: Verwende beim Vergleich von Gruppen unterschiedlicher Größe
Meta-Ereignisse:
_active: Jedes aktive Ereignis (DAU, MAU)_new: Neue Benutzer (Erstereignis)_any_revenue_event: Umsatzereignisse
Diagrammdefinitionsstruktur
Kernparameter (alle Diagrammtypen):
{
"name": "Beschreibender Diagrammtitel",
"projectId": "12345",
"definition": {
"app": "12345",
"type": "eventsSegmentation",
"params": {
"range": "Letzte 30 Tage",
"events": [{
"event_type": "Kauf abgeschlossen",
"filters": [],
"group_by": []
}],
"metric": "uniques",
"countGroup": "User",
"interval": 1,
"segments": [{"conditions": []}]
}
}
}
Wichtige Parameter:
countGroup: "User" (eindeutige Benutzer) oder "Event" (Ereignisvorkommen)interval: 1 (täglich), 7 (wöchentlich), 30 (monatlich)segments: Benutzerfilter/-gruppen (leeres Array = alle Benutzer)
Ereignisfilter (inline ODER-Logik):
"filters": [{
"group_type": "User",
"subprop_key": "country",
"subprop_op": "is",
"subprop_type": "event",
"subprop_value": ["Vereinigte Staaten", "Kanada"]
}]
Benutzersegmente (Bedingungen UND-Logik):
"segments": [{
"name": "Aktive Benutzer",
"conditions": [{
"type": "property",
"group_type": "User",
"prop_type": "user",
"prop": "plan",
"op": "is",
"values": ["Pro", "Enterprise"]
}]
}]
Kohortensegmente: Suche nach Kohorte, erhalte ID, dann:
"segments": [{
"name": "Meine Kohorte",
"conditions": [{
"type": "cohort",
"group_type": "User",
"cohort_id": "abc123",
"op": "is_in"
}]
}]
Workflow: Diagramm erstellen
- Kontext abrufen:
Amplitude:get_context (für projectId)
- Ereignisse entdecken (zuerst BREIT suchen):
Amplitude:search für jedes eindeutige Konzept
- Verwende zuerst breite Suchbegriffe
- Suche nach allen zugehörigen Ereignissen, benutzerdefinierten Ereignissen, Kohorten
- Überprüfe ALLE Ergebnisse vor der Auswahl
- Bewerten und entscheiden:
- Überprüfe alle entdeckten Ereignisse und benutzerdefinierten Ereignisse
- Treffe eine fundierte Entscheidung (bevorzuge aggregierte Ereignisse)
- Bereite eine klare Erklärung vor, was du gefunden hast und warum du dich entschieden hast
- Ähnliche Diagramme finden (siehe Beispiele):
Amplitude:search entity_types=['CHART'] query="ähnliches Konzept"
Amplitude:get_charts, um die Definitionsstruktur zu sehen
- Eigenschaften abrufen, falls nötig:
Amplitude:get_event_properties
- Definition erstellen mit entdeckten Namen
- Erkläre die Begründung für die Ereignisauswahl in der Antwort
- Diagramm erstellen:
Amplitude:query_dataset mit vollständiger Definition
-
Ergebnisse überprüfen – prüfen, ob die Daten sinnvoll sind
-
Diagramm speichern:
Amplitude:save_chart_edits mit editId von query_dataset
Fehlerbehandlung
Wenn query_dataset fehlschlägt:
- Lies die Fehlermeldung sorgfältig
- Häufige Probleme: falsche Ereignisnamen, ungültige Filter, falsche Parametertypen
- Korrigiere die Definition und wiederhole den Vorgang
- Überprüfe zuerst über die Suche, ob die Ereignisse existieren
Bei Nullergebnissen:
- Prüfe, ob die Filter nicht zu restriktiv sind
- Überprüfe, ob das Ereignis Daten hat (suche nach Diagrammen, die es verwenden)
- Versuche einen breiteren Zeitraum
- Überprüfe die Segmentbedingungen
Best Practices
Benennung:
- Metrik + Zeitkontext einbeziehen: "Wöchentlich aktive Benutzer der letzten 90 Tage"
- Nicht: "WAU" oder "Benutzer"
Zeiträume:
- Standardmäßig "Letzte 30 Tage"
- Verwende inklusive Zeiträume für bestimmte Zeitabschnitte
- Gib den interpretierten Zeitraum explizit an
Überprüfung:
- Überprüfe immer, ob das Ereignis existiert, bevor du es verwendest
- Suche nach ähnlichen Diagrammen, um die Ereignisnutzung zu verstehen
- Bestätige Eigenschaften mit get_event_properties
Vergleiche:
- Verwende Segmente, um Benutzergruppen im selben Diagramm zu vergleichen
- Verwende Raten/Prozentsätze für unterschiedlich große Gruppen
Immer angeben:
- Diagramm-URL in der Antwort
- Was das Diagramm zeigt
- Wichtige Erkenntnisse aus den ersten Daten
- Verwendete Methodik