Events, gebruikers en sessies
200 acties in 20 sessies betekenen bijvoorbeeld niet dat 20 mensen de app
hebben gebruikt. Eventtotalen zijn exact voor het gekozen tijdvenster. Aantallen
unieke gebruikers, sessies en anonieme subjecten zijn bij benadering.
Gebruik ondoorzichtige ID’s. Gebruik geen namen, e-mailadressen of andere
persoonsgegevens als ID. Responses van productanalyse bevatten nooit ruwe
gebruikers- of sessie-ID’s.
Het overzicht in het dashboard openen
- Open Analytics in het LogBrew-dashboard.
- Kies één project.
- Kies 24 uur, 7 dagen, 14 dagen, 30 dagen of Aangepast.
- Lees de activiteitsgrafiek en daarna Belangrijkste events en Belangrijkste pagina’s en schermen.
- Open Dekking en limieten voordat je gebruikersaantallen leest.
Het projectoverzicht lezen
--until <RFC3339> toe voor een eindtijd. Dat tijdstip zelf valt buiten
het bereik. --interval accepteert auto, 1m, 5m, 15m, 1h, 6h of
1d. --top-limit bepaalt het aantal rijen in elke toplijst, van 1 tot
20. De standaardwaarde is 10. Voeg --service, --release of
--environment toe om op exacte context te filteren. Het API-endpoint is
GET /api/telemetry/analytics/overview.
Het overzicht bevat activiteitstotalen, een tijdreeks, de populairste acties
en geclassificeerde activiteit. Dit fragment toont de totalen en hun dekking:
subject_coverage tellen op tot summary.actions.
Alleen identified_user_events telt mee voor gebruikers. anonymous_actions
omvat de vier andere statussen. In dit voorbeeld zijn er 8 events van
anonieme subjecten, afkomstig van ongeveer 7 verschillende anonieme subjecten. Geen van beide
getallen is een gebruikersaantal. Uit een afgekapte toplijst kun je niet
afleiden dat events met een lager volume ontbreken.
analysis_level is no_data, event_only, user_level of
user_and_session. Het geeft aan welke vragen de gegevens kunnen
beantwoorden. Het niveau is het hoogste niveau dat summary of
classified_activity ondersteunt. Het betekent niet dat beide groepen
gebruikers of sessies hebben.
De twee activiteitsgroepen gescheiden houden
Geclassificeerde schermweergaven en interacties zijn ook acties. Tel
summary.actions niet op bij classified_activity.summary.events. Lees de
dekking van de groep die je gebruikt. De subjectaantallen in
classified_activity.coverage.subject_coverage tellen op tot
classified_activity.summary.events.
summary.actions kan 0 zijn terwijl geclassificeerde paginaweergaven wel
gebruikers- en sessieaantallen leveren. Controleer classified_activity
voordat je concludeert dat er geen productactiviteit is.
De volgende actie volgen
next_action heeft een code, een target en een reason. Het toont het
belangrijkste gat in de vastlegging of de volgende analysestap:
Pas de vastlegging in de app aan en controleer daarna een nieuw event. Oudere
events tonen niet aan dat de wijziging werkt.
De API direct aanroepen
Stuur een account-bearer mee. Stuurresponse_version=3 mee om dezelfde
response te krijgen die de CLI leest. Laat je response_version weg, dan
geeft de API versie 1 terug. Die versie heeft geen aantallen anonieme
subjecten en geen subject_coverage.
since is een positieve duur, zoals 24h, 7d of 30d, of een
RFC3339-tijdstempel. until is een optionele RFC3339-tijdstempel. Het bereik
bevat since en bevat until niet. Laat je until weg, dan eindigt het
bereik op het moment van het request. Een bereik kan niet langer zijn dan 31
dagen.
Stuur voor 12 tot en met 16 april 2026 2026-04-12T00:00:00Z als since en
2026-04-17T00:00:00Z als until.
Een bereik van meer dan 31 dagen geeft HTTP 422:
code en next_action in programmalogica. Toon error en next aan
een persoon. API-fouten beschrijft de andere
foutresponses.
De POST-routes voor productanalyse hieronder verwachten een JSON-body met
dezelfde velden project_id, since, until, service_name, release en
environment. Onbekende velden in de body worden geweigerd.
Een trechter meten
Een trechter meet de conversie over twee tot acht geordende stappen:--unit identified-user om gebruikers over sessies heen te tellen.
Kopieer de eventnamen uit het overzicht. De verhouding tussen twee totalen
zonder verband is geen conversieratio.
De laatste stap moet plaatsvinden binnen het conversievenster dat bij de
eerste stap begint. Stel het in met --conversion-window, bijvoorbeeld 30m
of 1h. De standaardwaarde is 24 uur, of het hele bereik als dat korter is.
Het venster kan niet langer zijn dan het bereik.
De API-route is POST /api/telemetry/analytics/funnel. De
response van de geordende trechter
toont de request-body en de response.
Paden rond één event verkennen
Paden tonen de meest voorkomende reeksen benoemde events na of vóór één ankerevent:preceding in plaats van following voor de events vóór het anker.
--depth bepaalt het aantal events aan die kant, van 1 tot 8. De
standaardwaarde is 4. --path-limit bepaalt het aantal paden, van 1 tot
20. De standaardwaarde is 10. Opeenvolgende identieke events tellen als
één event. Voeg --keep-repeated toe om ze allemaal te houden.
Paden gebruiken sessie-ID’s. Een following-pad begint bij het eerste anker
in elke sessie. Een preceding-pad eindigt bij het laatste anker. Paden
tellen geen gebruikers en laten niet zien waarom een actie mislukte. De
API-route is POST /api/telemetry/analytics/paths.
De retentie lezen
Retentie laat zien of geïdentificeerde gebruikers terugkomen na een startevent:--interval is hour, day, week of thirty-day. thirty-day is 30
dagen, geen kalendermaand. --interval-count loopt van 1 tot 31. De
standaardwaarde is 10. --mode return-on telt terugkeer in elke exacte
periode. return-on-or-after telt terugkeer in of na elke periode.
Een terugkeer moet na het startevent van de gebruiker plaatsvinden. Elke
gebruiker start één keer, bij het eerste startevent in het bereik. Dat event
is niet altijd het allereerste event van de gebruiker. Een gebruiker die in
één periode vaker terugkomt, telt één keer voor die periode.
Lees per periode het aantal behouden gebruikers samen met het aantal
gebruikers dat in aanmerking komt. Gebruikers van wie de periode nog niet
voorbij is, komen niet in aanmerking. Ze tellen niet als verloren. Zo geven
40 teruggekeerde gebruikers van de 100 die in aanmerking komen een retentie
van 40%. Een lager terugkeerpercentage laat niet zien waarom mensen
vertrokken.
Retentie voor alle activiteit opvragen
De API-route isPOST /api/telemetry/analytics/retention. Stuur
response_version 2 en laat start_event en return_event weg om retentie
zonder eventnamen te meten:
query.activity_scope op all_classified_activity. Elke
latere paginaweergave, schermweergave of interactie telt als terugkeer. Wil je
events kiezen, laat dan response_version weg en stuur zowel start_event
als return_event als { "kind": "page_view", "event_name": "/signup" }.
Het bereik gedeeld door het interval, vermenigvuldigd met interval_count,
mag niet meer dan 500 zijn. 14 dagen met day en 10 perioden geeft
bijvoorbeeld 140. Laat je interval weg, dan gebruikt de API hour voor
bereiken tot 48 uur en day voor langere bereiken.
De levenscyclus lezen
De levenscyclus plaatst geïdentificeerde gebruikers die een bepaald event uitvoerden, per periode in één groep:
Nieuw in de waargenomen geschiedenis betekent niet dat het om een nieuwe klant
gaat. Eerdere activiteit kan buiten het geschiedenisvenster vallen. Dat
venster stel je in met
--history-periods. Tel de totalen van perioden niet
op om unieke gebruikers over het hele bereik te tellen.
--history-periods loopt van 2 tot 31 perioden vóór since. De
standaardwaarde is 2. De geschiedenis kan niet langer zijn dan 62 dagen. Het
bereik kan maximaal 100 perioden hebben. Elke periode heeft fully_observed.
Dat is false als de periode nog niet voorbij is. Inactief betekent: niet
actief in de huidige periode. Het betekent niet dat de gebruiker voorgoed
verloren is.
De API-route is POST /api/telemetry/analytics/lifecycle. Wil je alle
geclassificeerde activiteit gebruiken in plaats van één event, stuur dan
response_version 2 en laat event weg:
Twee perioden vergelijken
Vraag elke periode apart op. Gebruik hetzelfde project, dezelfde duur, dezelfde eventnamen en dezelfde filters. Vergelijk de activiteit, de eventmix en de dekking van identiteit en sessies voordat je gebruikersaantallen vergelijkt. Een onvolledige periode kan minder activiteit tonen dan een volledige.
Wijst een resultaat op een fout, lees dan de bijbehorende issues en logs voor
hetzelfde project en dezelfde tijd. Open een trace alleen als een event een
exacte tracelink heeft. Een gedeeld tijdsbereik toont niet aan dat een fout
een daling veroorzaakte.
Wil je een vergelijking herhalen, noteer dan het project-ID, beide
UTC-bereiken, het interval, de filters, de eenheid, de dekking en of
resultaten zijn afgekapt. Noteer geen ruwe gebruikers-ID’s.
Lees voor responsevelden en fouten de
Telemetrie-API en
API-fouten.