> ## Documentation Index > Fetch the complete documentation index at: https://docs.logbrew.co/llms.txt > Use this file to discover all available pages before exploring further. # Was sind Produktanalysen? Metriken und wiederkehrende Nutzer > Wählen Sie ein Projekt und einen Zeitraum. Lesen Sie Aktivität, Trichter, Nutzerbindung und Lebenszyklus. Prüfen Sie vorher die Datenabdeckung. 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](/de/guides/product-events). 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 | Einheit | Bedeutung | | - | - | | Ereignis | Eine aufgezeichnete Aktion. Eine Person kann viele Ereignisse senden. | | Identifizierter Nutzer | Eine stabile, opake Subjekt-ID von der App mit der Art `user`. | | Anonymes Subjekt | Eine typisierte Subjekt-ID, die kein Nutzer ist. Sie zählt nie als Nutzer. | | Sitzung | Eine ausdrückliche Sitzungs-ID von der App. Eine Person kann viele Sitzungen haben. | 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 ```bash theme={null} logbrew analytics overview --project "" --since 7d --json ``` Mit `--until ` 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: ```json theme={null} { "schema_version": 3, "analysis_level": "user_and_session", "summary": { "actions": 120, "active_identified_users": 18, "active_anonymous_subjects": 7, "sessions": 24 }, "coverage": { "identified_actions": 100, "anonymous_actions": 20, "subject_coverage": { "index_version": 1, "identified_user_events": 100, "anonymous_subject_events": 8, "legacy_unknown_kind_events": 4, "missing_subject_events": 6, "historical_unindexed_events": 2 }, "sessionized_actions": 90, "traced_actions": 60, "top_actions_truncated": true }, "next_action": { "code": "build_product_funnel" } } ``` 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 | Antwortfelder | Gezählte Ereignisse | | - | - | | `summary`, `coverage`, `series`, `top_actions` | Produktaktionen, auch Aktionen ohne unterstützte Klassifizierung. | | `classified_activity` | Seitenaufrufe, Bildschirmaufrufe und Interaktionen. Seitenaufrufe sind keine Aktionen. | 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: | `next_action.code` | Bedeutung | | - | - | | `capture_product_activity` | Keine Produktereignisse passen zum Bereich. | | `classify_product_activity` | Es gibt Ereignisse, aber keines ist ein Seitenaufruf, Bildschirmaufruf oder eine Interaktion. | | `identify_product_users` | Kein Ereignis hat ein Subjekt mit der Art `user`. | | `sessionize_product_activity` | Kein Ereignis hat eine Sitzungs-ID. | | `capture_funnel_steps` | Es gibt weniger als zwei benannte klassifizierte Ereignisse. | | `build_product_funnel` | Die Daten reichen für einen Trichter. | Ä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`. ```bash theme={null} curl -sS -G "https://api.logbrew.co/api/telemetry/analytics/overview" \ -H "Authorization: Bearer $LOGBREW_ACCOUNT_BEARER" \ --data-urlencode "project_id=" \ --data-urlencode "since=7d" \ --data-urlencode "response_version=3" ``` `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: ```json theme={null} { "error": "product analytics range must not exceed 31 days", "code": "validation_failed", "next": "use a shorter range or query consecutive bounded windows", "next_action": { "code": "fix_request", "target": "request" } } ``` Werten Sie im Programmcode `code` und `next_action` aus. Zeigen Sie Personen `error` und `next`. Die anderen Fehlerantworten stehen unter [API-Fehler](/de/reference/api-errors). 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: ```bash theme={null} logbrew analytics funnel --project "" --since 7d \ --step page-view /pricing \ --step interaction checkout_started \ --step interaction checkout_completed \ --json ``` 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](/de/reference/telemetry-response-shapes#ordered-funnel-response) 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: ```bash theme={null} logbrew analytics paths following --project "" --since 24h \ --anchor-kind page-view --anchor-event /pricing \ --json ``` 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: ```bash theme={null} logbrew analytics retention --project "" --since 30d \ --start-kind page-view --start-event /signup \ --return-kind interaction --return-event report_opened \ --json ``` `--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: ```bash theme={null} curl -sS "https://api.logbrew.co/api/telemetry/analytics/retention" \ -H "Authorization: Bearer $LOGBREW_ACCOUNT_BEARER" \ -H "Content-Type: application/json" \ -d '{ "project_id": "", "since": "14d", "response_version": 2, "interval": "day", "interval_count": 10, "mode": "return_on", "cohort_mode": "first_in_range" }' ``` 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: ```bash theme={null} logbrew analytics lifecycle --project "" --since 30d \ --event-kind interaction --event report_opened \ --json ``` | Gruppe | Bedeutung | | - | - | | Neu im beobachteten Verlauf | Jetzt aktiv, ohne früheres Ereignis im Verlaufsfenster. | | Wiederkehrend | Jetzt und in der vorherigen Periode aktiv. | | Reaktiviert | Nach einer Pause wieder aktiv. | | Inaktiv | In der vorherigen Periode aktiv, jetzt nicht. | „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: ```json theme={null} { "project_id": "", "since": "30d", "response_version": 2, "interval": "day", "history_period_count": 7 } ``` ## 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. | Beobachtung | Nächste Prüfung | Grenze | | - | - | - | | Ein Ereignis hat zugenommen | Prüfen Sie seine Sitzungen und die Abdeckung. | Mehr Ereignisse zeigen nicht mehr Personen. | | Eine Konversionsrate hat sich geändert | Verwenden Sie für beide Zeiträume dieselben Trichterschritte und dieselbe Einheit. | Vergleichen Sie keine unterschiedlichen Trichterdefinitionen. | | Wiederkehrende Nutzer haben abgenommen | Prüfen Sie berechtigte Nutzer und vollständige Perioden. | Eine neue Kohorte kann schlechter aussehen als eine ältere. | | Nutzer hören bei einem Schritt auf | Lesen Sie die Issues und Logs zu diesem Schritt. | Ein gemeinsamer Zeitraum zeigt keine Ursache. | 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](/de/reference/telemetry-api) und unter [API-Fehler](/de/reference/api-errors). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.