Skip to main content
Produktanalysen zeigen, wie Menschen Ihre App nutzen. LogBrew liest die Produktaktionen, die Ihre App sendet, darunter Seitenaufrufe, Bildschirmaufrufe und Interaktionen. Wie Sie diese Ereignisse mit Nutzer- und Sitzungskontext senden, beschreibt Produktereignisse erfassen. Jedes Ergebnis gilt für ein Projekt und einen Zeitraum. Ein Dienstname wählt kein Projekt aus. Logs und Issues sind eigene Signale. Wenn es sie gibt, heißt das nicht, dass es für denselben Zeitraum auch Analysedaten gibt.

​
Ereignisse, Nutzer und Sitzungen

200 Aktionen in 20 Sitzungen heißen zum Beispiel nicht, dass 20 Personen die App genutzt haben. Ereignissummen sind für den gewählten Zeitraum exakt. Die Zahlen eindeutiger Nutzer, Sitzungen und anonymer Subjekte sind ungefähr. Verwenden Sie opake IDs. Verwenden Sie keine Namen, E-Mail-Adressen oder andere personenbezogene Daten als IDs. Antworten der Analysen geben nie rohe Nutzer- oder Sitzungs-IDs zurück.

​
Übersicht im Dashboard öffnen

  1. Öffnen Sie Analysen im LogBrew-Dashboard.
  2. Wählen Sie ein Projekt.
  3. Wählen Sie 24 Stunden, 7 Tage, 14 Tage, 30 Tage oder Benutzerdefiniert.
  4. Lesen Sie das Aktivitätsdiagramm und danach Wichtigste Ereignisse und Wichtigste Oberflächen.
  5. Öffnen Sie Abdeckung und Grenzen, bevor Sie Nutzerzahlen lesen.
Wählen Sie für Benutzerdefiniert den ersten und den letzten Tag und dann Anwenden. Beide Tage gehören zum Zeitraum. Der 12. bis 16. April sind zum Beispiel fünf Tage. Das Dashboard verwendet UTC-Daten. Ein benutzerdefinierter Zeitraum umfasst höchstens 31 Tage und darf keine künftigen Tage enthalten. Das Dashboard zeigt für dasselbe Projekt und dieselben Tage auch zwei Nutzertrends. Kehren Nutzer zurück? zeigt die Nutzerbindung. Wie verändert sich die Nutzerbasis? zeigt die Lebenszyklus-Gruppen. Beide Trends nutzen die gesamte klassifizierte Aktivität identifizierter Nutzer. Sie wählen dafür kein Ereignis aus.

​
Projektübersicht lesen

Mit --until <RFC3339> legen Sie ein exklusives Ende fest. --interval akzeptiert auto, 1m, 5m, 15m, 1h, 6h oder 1d. --top-limit legt die Zeilen jeder Top-Liste fest, von 1 bis 20. Der Standardwert ist 10. Mit --service, --release oder --environment filtern Sie nach exaktem Kontext. Der API-Endpunkt ist GET /api/telemetry/analytics/overview. Die Übersicht enthält Aktivitätssummen, eine Zeitreihe, die wichtigsten Aktionen und klassifizierte Aktivität. Dieser Ausschnitt zeigt die Summen und ihre Abdeckung:
Die fünf Zahlen in subject_coverage ergeben zusammen summary.actions. Nur identified_user_events zählt zu den Nutzern. anonymous_actions umfasst die vier anderen Zustände. In diesem Beispiel stammen 8 Ereignisse anonymer Subjekte von etwa 7 verschiedenen anonymen Subjekten. Keine der beiden Zahlen ist eine Nutzerzahl. Eine gekürzte Top-Liste zeigt nicht, dass seltenere Ereignisse fehlen. analysis_level ist no_data, event_only, user_level oder user_and_session. Der Wert zeigt, welche Fragen die Daten beantworten können. Er ist die höchste Stufe, die summary oder classified_activity unterstützt. Er heißt nicht, dass beide Gruppen Nutzer oder Sitzungen haben.

​
Die beiden Aktivitätsgruppen getrennt halten

Klassifizierte Bildschirmaufrufe und Interaktionen sind auch Aktionen. Addieren Sie summary.actions nicht zu classified_activity.summary.events. Lesen Sie die Abdeckung der Gruppe, die Sie nutzen. Die Subjektzahlen in classified_activity.coverage.subject_coverage ergeben zusammen classified_activity.summary.events. summary.actions kann 0 sein, während klassifizierte Seitenaufrufe Nutzer- und Sitzungszahlen liefern. Prüfen Sie classified_activity, bevor Sie schließen, dass es keine Produktaktivität gibt.

​
Dem nächsten Schritt folgen

next_action hat einen code, ein target und einen reason. Das Feld zeigt die wichtigste Erfassungslücke oder den nächsten Analyseschritt: Ändern Sie die Erfassung in der App und prüfen Sie dann ein neues Ereignis. Ältere Ereignisse zeigen nicht, dass die Änderung wirkt.

​
API direkt aufrufen

Senden Sie ein Konto-Bearer-Token. Senden Sie response_version=3, um dieselbe Antwort zu erhalten, die die CLI liest. Ohne response_version gibt die API Version 1 zurück. Sie enthält keine Zahlen anonymer Subjekte und kein subject_coverage.
since ist eine positive Dauer wie 24h, 7d oder 30d oder ein RFC3339-Zeitstempel. until ist ein optionaler RFC3339-Zeitstempel. Der Zeitraum schließt since ein und until aus. Ohne until endet der Zeitraum zum Zeitpunkt der Anfrage. Ein Zeitraum darf nicht länger als 31 Tage sein. Für den 12. bis 16. April 2026 senden Sie 2026-04-12T00:00:00Z als since und 2026-04-17T00:00:00Z als until. Ein Zeitraum über 31 Tage gibt HTTP 422 zurück:
Werten Sie im Programmcode code und next_action aus. Zeigen Sie Personen error und next. Die anderen Fehlerantworten stehen unter API-Fehler. Die folgenden POST-Routen der Analysen nehmen einen JSON-Body mit denselben Feldern project_id, since, until, service_name, release und environment an. Unbekannte Felder im Body werden abgelehnt.

​
Trichter messen

Ein Trichter misst die Konversion über zwei bis acht geordnete Schritte:
Jeder spätere Schritt braucht einen späteren Zeitstempel als der Schritt davor. Ein Ereignis kann nicht zwei Schritte abschließen. Die Standardeinheit ist die Sitzung. Mit --unit identified-user zählen Sie Nutzer über Sitzungen hinweg. Übernehmen Sie die Ereignisnamen aus der Übersicht. Das Verhältnis zweier unabhängiger Summen ist keine Konversionsrate. Der letzte Schritt muss innerhalb des Konversionsfensters liegen, das mit dem ersten Schritt beginnt. Legen Sie es mit --conversion-window fest, zum Beispiel 30m oder 1h. Der Standardwert ist 24 Stunden oder der ganze Zeitraum, wenn dieser kürzer ist. Das Fenster darf nicht länger als der Zeitraum sein. Die API-Route ist POST /api/telemetry/analytics/funnel. Die Antwort für geordnete Trichter zeigt den Anfrage-Body und die Antwort.

​
Pfade rund um ein Ereignis untersuchen

Pfade zeigen die häufigsten Abfolgen benannter Ereignisse nach oder vor einem Ankerereignis:
Verwenden Sie preceding statt following für die Ereignisse vor dem Anker. --depth legt die Zahl der Ereignisse auf dieser Seite fest, von 1 bis 8. Der Standardwert ist 4. --path-limit legt die Zahl der Pfade fest, von 1 bis 20. Der Standardwert ist 10. Gleiche Ereignisse direkt hintereinander zählen als ein Ereignis. Mit --keep-repeated behalten Sie jedes einzelne. Pfade nutzen Sitzungs-IDs. Ein folgender Pfad beginnt beim ersten Anker jeder Sitzung. Ein vorangehender Pfad endet beim letzten Anker. Pfade zählen keine Nutzer und zeigen nicht, warum eine Aktion fehlgeschlagen ist. Die API-Route ist POST /api/telemetry/analytics/paths.

​
Nutzerbindung lesen

Die Nutzerbindung zeigt, ob identifizierte Nutzer nach einem Startereignis zurückkehren:
--interval ist hour, day, week oder thirty-day. thirty-day sind 30 Tage, kein Kalendermonat. --interval-count reicht von 1 bis 31. Der Standardwert ist 10. --mode return-on zählt Rückkehrer genau in jeder Periode. return-on-or-after zählt Rückkehrer in oder nach jeder Periode. Eine Rückkehr muss nach dem Startereignis des Nutzers liegen. Jeder Nutzer startet einmal, beim ersten Startereignis im Zeitraum. Dieses Ereignis ist nicht immer das allererste Ereignis des Nutzers. Ein Nutzer, der in einer Periode mehrmals zurückkehrt, zählt für diese Periode einmal. Lesen Sie die Zahl gebundener Nutzer zusammen mit der Zahl berechtigter Nutzer jeder Periode. Nutzer, deren Periode noch nicht beendet ist, sind nicht berechtigt. Sie zählen nicht als verloren. 40 zurückgekehrte von 100 berechtigten Nutzern sind zum Beispiel 40 % Nutzerbindung. Eine niedrigere Rückkehrrate zeigt nicht, warum Menschen gegangen sind.

​
Nutzerbindung für die gesamte Aktivität anfragen

Die API-Route ist POST /api/telemetry/analytics/retention. Um die Nutzerbindung ohne Ereignisnamen zu messen, senden Sie response_version 2 und lassen start_event und return_event weg:
Die Antwort setzt query.activity_scope auf all_classified_activity. Jeder spätere Seitenaufruf, Bildschirmaufruf oder jede spätere Interaktion zählt als Rückkehr. Um Ereignisse auszuwählen, lassen Sie response_version weg und senden start_event und return_event beide als { "kind": "page_view", "event_name": "/signup" }. Der Zeitraum geteilt durch das Intervall, multipliziert mit interval_count, darf höchstens 500 sein. 14 Tage mit day und 10 Perioden ergeben zum Beispiel 140. Ohne interval nutzt die API hour für Zeiträume bis 48 Stunden und day für längere Zeiträume.

​
Lebenszyklus lesen

Der Lebenszyklus ordnet identifizierte Nutzer, die ein Ereignis ausgelöst haben, pro Periode genau einer Gruppe zu:
„Neu im beobachteten Verlauf“ heißt nicht „erstmals Kunde“. Frühere Aktivität kann außerhalb des Verlaufsfensters liegen, das Sie mit --history-periods festlegen. Addieren Sie keine Periodensummen, um eindeutige Nutzer im ganzen Zeitraum zu zählen. --history-periods reicht von 2 bis 31 Perioden vor since. Der Standardwert ist 2. Der Verlauf darf nicht länger als 62 Tage sein. Der Zeitraum darf höchstens 100 Perioden haben. Jede Periode hat fully_observed. Der Wert ist false, wenn die Periode noch nicht beendet ist. „Inaktiv“ heißt in der aktuellen Periode inaktiv, nicht dauerhaft verloren. Die API-Route ist POST /api/telemetry/analytics/lifecycle. Um die gesamte klassifizierte Aktivität statt eines Ereignisses zu nutzen, senden Sie response_version 2 und lassen event weg:

​
Zwei Zeiträume vergleichen

Fragen Sie jeden Zeitraum einzeln an. Verwenden Sie dasselbe Projekt, dieselbe Dauer, dieselben Ereignisnamen und dieselben Filter. Vergleichen Sie Aktivität, Ereignismix sowie Identitäts- und Sitzungsabdeckung, bevor Sie Nutzerzahlen vergleichen. Ein unvollständiger Zeitraum kann weniger Aktivität zeigen als ein vollständiger. Wenn ein Ergebnis auf einen Fehler hindeutet, lesen Sie die zugehörigen Issues und Logs für dasselbe Projekt und dieselbe Zeit. Öffnen Sie einen Trace nur, wenn ein Ereignis einen exakten Trace-Link hat. Ein gemeinsamer Zeitraum zeigt nicht, dass ein Fehler einen Rückgang verursacht hat. Um einen Vergleich zu wiederholen, notieren Sie die Projekt-ID, beide UTC-Zeiträume, das Intervall, die Filter, die Einheit, die Abdeckung und die Kürzungszustände. Notieren Sie keine rohen Nutzer-IDs. Antwortfelder und Fehler finden Sie in der Telemetrie-API und unter API-Fehler.