Eventi, utenti e sessioni
Per esempio, 200 azioni in 20 sessioni non significano che 20 persone abbiano
usato l’app. I totali degli eventi sono esatti per l’intervallo selezionato. I
conteggi unici di utenti, sessioni e soggetti anonimi sono approssimativi.
Usa ID opachi. Non usare nomi, indirizzi email o altri dati personali come ID.
Le risposte di analisi non restituiscono mai gli ID grezzi di utenti o
sessioni.
Apri la panoramica nella dashboard
- Apri Analisi nella dashboard di LogBrew.
- Seleziona un progetto.
- Seleziona 24 ore, 7 giorni, 14 giorni, 30 giorni o Personalizzato.
- Leggi il grafico dell’attività, poi Eventi principali e Superfici principali.
- Apri Copertura e limiti prima di leggere i conteggi degli utenti.
Leggi la panoramica del progetto
--until <RFC3339> per un orario di fine escluso dall’intervallo.
--interval accetta auto, 1m, 5m, 15m, 1h, 6h o 1d.
--top-limit imposta le righe di ogni classifica, da 1 a 20. Il valore
predefinito è 10. Aggiungi --service, --release o --environment per
filtrare per contesto esatto. L’endpoint dell’API è
GET /api/telemetry/analytics/overview.
La panoramica contiene i totali dell’attività, una serie temporale, le azioni
principali e l’attività classificata. Questo estratto mostra i totali e la loro
copertura:
subject_coverage è uguale a
summary.actions. Solo identified_user_events conta per gli utenti.
anonymous_actions include gli altri quattro stati. In questo esempio, 8
eventi di soggetti anonimi provengono da circa 7 soggetti anonimi diversi.
Nessuno dei due numeri è un conteggio di utenti. Una classifica troncata non
dimostra che gli eventi con meno volume siano assenti.
analysis_level vale no_data, event_only, user_level o
user_and_session. Indica a quali domande i dati possono rispondere. Il
livello è il più alto supportato da summary o da classified_activity. Non
significa che entrambi i gruppi abbiano utenti o sessioni.
Tieni separati i due gruppi di attività
Anche le visualizzazioni di schermata e le interazioni classificate sono
azioni. Non sommare
summary.actions a classified_activity.summary.events.
Leggi la copertura del gruppo che usi. La somma dei conteggi dei soggetti in
classified_activity.coverage.subject_coverage è uguale a
classified_activity.summary.events.
summary.actions può valere 0 mentre le visualizzazioni di pagina
classificate forniscono i conteggi di utenti e sessioni. Controlla
classified_activity prima di concludere che non c’è attività di prodotto.
Segui la prossima azione
next_action ha un code, un target e un reason. Indica la lacuna di
acquisizione più importante o il prossimo passo dell’analisi:
Modifica l’acquisizione nell’app, poi controlla un nuovo evento. Gli eventi
precedenti non dimostrano che la modifica funziona.
Chiama direttamente l’API
Invia un token bearer dell’account. Inviaresponse_version=3 per ottenere la
stessa risposta che legge la CLI. Se ometti response_version, l’API
restituisce la versione 1, che non ha i conteggi dei soggetti anonimi né
subject_coverage.
since è una durata positiva, come 24h, 7d o 30d, oppure un timestamp
RFC3339. until è un timestamp RFC3339 facoltativo. L’intervallo include
since ed esclude until. Se ometti until, l’intervallo termina all’orario
della richiesta. Un intervallo non può superare 31 giorni.
Per l’intervallo dal 12 al 16 aprile 2026, invia 2026-04-12T00:00:00Z come
since e 2026-04-17T00:00:00Z come until.
Un intervallo più lungo di 31 giorni restituisce HTTP 422:
code e next_action. Mostra error e
next a una persona. Errori API elenca le
altre risposte di errore.
Le route di analisi POST qui sotto accettano un corpo JSON con gli stessi
campi project_id, since, until, service_name, release ed
environment. L’API rifiuta i campi sconosciuti nel corpo.
Misura un funnel
Un funnel misura la conversione lungo una serie ordinata di passaggi, da due a otto:--unit identified-user per contare gli utenti su più sessioni.
Copia i nomi degli eventi dalla panoramica. Il rapporto tra due totali non
correlati non è un tasso di conversione.
L’ultimo passaggio deve avvenire entro la finestra di conversione, che parte
dal primo passaggio. Impostala con --conversion-window, per esempio 30m o
1h. Il valore predefinito è 24 ore, oppure l’intero intervallo se è più
breve. La finestra non può superare l’intervallo.
La route dell’API è POST /api/telemetry/analytics/funnel. La
risposta del funnel ordinato
mostra il corpo della richiesta e la risposta.
Esplora i percorsi attorno a un evento
I percorsi mostrano le sequenze più comuni di eventi con nome dopo o prima di un evento di ancoraggio:preceding al posto di following per gli eventi prima dell’ancoraggio.
--depth imposta il numero di eventi su quel lato, da 1 a 8. Il valore
predefinito è 4. --path-limit imposta il numero di percorsi, da 1 a 20.
Il valore predefinito è 10. Più eventi identici consecutivi contano come un
solo evento. Aggiungi --keep-repeated per tenerli tutti.
I percorsi usano gli ID sessione. Un percorso successivo parte dal primo
ancoraggio di ogni sessione. Un percorso precedente termina all’ultimo
ancoraggio. I percorsi non contano gli utenti e non mostrano perché un’azione
non è riuscita. La route dell’API è POST /api/telemetry/analytics/paths.
Leggi la fidelizzazione
La fidelizzazione mostra se gli utenti identificati tornano dopo un evento iniziale:--interval vale hour, day, week o thirty-day. thirty-day
corrisponde a 30 giorni, non a un mese di calendario. --interval-count va da
1 a 31. Il valore predefinito è 10. --mode return-on conta i ritorni
esattamente in ciascun periodo. return-on-or-after conta i ritorni in
ciascun periodo o dopo.
Un ritorno deve avvenire dopo l’evento iniziale dell’utente. Ogni utente
inizia una sola volta, al primo evento iniziale nell’intervallo. Quell’evento
non è sempre il primo evento in assoluto dell’utente. Un utente che torna più
volte nello stesso periodo conta una sola volta per quel periodo.
Per ogni periodo, leggi il numero di utenti tornati insieme al numero di
utenti idonei. Gli utenti il cui periodo non è ancora finito non sono idonei.
Non contano come utenti persi. Per esempio, 40 utenti tornati su 100 utenti
idonei corrispondono a una fidelizzazione del 40%. Un tasso di ritorno più
basso non spiega perché le persone se ne sono andate.
Richiedi la fidelizzazione per tutta l’attività
La route dell’API èPOST /api/telemetry/analytics/retention. Per misurare la
fidelizzazione senza nomi di eventi, invia response_version 2 e ometti
start_event e return_event:
query.activity_scope su all_classified_activity.
Qualsiasi visualizzazione di pagina, visualizzazione di schermata o
interazione successiva conta come ritorno. Per selezionare gli eventi, ometti
response_version e invia sia start_event sia return_event nella forma
{ "kind": "page_view", "event_name": "/signup" }.
L’intervallo diviso per la granularità, moltiplicato per interval_count,
deve essere al massimo 500. Per esempio, 14 giorni con day e 10 periodi
danno 140. Se ometti interval, l’API usa hour per intervalli fino a 48 ore
e day per intervalli più lunghi.
Leggi il ciclo di vita
Il ciclo di vita assegna gli utenti identificati che hanno eseguito un dato evento a un solo gruppo per periodo:
«Nuovo nella cronologia osservata» non indica un cliente alla prima
esperienza. L’attività precedente può trovarsi fuori dall’intervallo della
cronologia, che imposti con
--history-periods. Non sommare i totali dei
periodi per contare gli utenti unici nell’intero intervallo.
--history-periods va da 2 a 31 periodi prima di since. Il valore
predefinito è 2. La cronologia non può superare 62 giorni. L’intervallo può
avere al massimo 100 periodi. Ogni periodo ha fully_observed, che vale
false quando il periodo non è finito. «Inattivo» significa senza attività
nel periodo corrente, non perso per sempre.
La route dell’API è POST /api/telemetry/analytics/lifecycle. Per usare tutta
l’attività classificata invece di un solo evento, invia response_version 2
e ometti event:
Confronta due periodi
Richiedi ogni periodo separatamente. Usa lo stesso progetto, la stessa durata, gli stessi nomi di eventi e gli stessi filtri. Prima di confrontare i conteggi degli utenti, confronta l’attività, la composizione degli eventi e la copertura di identità e sessioni. Un periodo incompleto può mostrare meno attività di uno completo.
Quando un risultato indica un errore, leggi i problemi e i log correlati per
lo stesso progetto e lo stesso periodo. Apri una traccia solo quando un evento
ha un link esatto alla traccia. Un intervallo di tempo in comune non dimostra
che un errore abbia causato un calo.
Per ripetere un confronto, annota l’ID del progetto, entrambi gli intervalli
UTC, la granularità, i filtri, l’unità, la copertura e gli stati di
troncamento. Non annotare gli ID utente grezzi.
Per i campi delle risposte e gli errori, leggi
API di telemetria ed
Errori API.