Eventos, usuarios y sesiones
Por ejemplo, 200 acciones en 20 sesiones no significan que 20 personas usaron
la app. Los totales de eventos son exactos para el intervalo de tiempo
seleccionado. Los recuentos únicos de usuarios, sesiones y sujetos anónimos son
aproximados.
Usa ID opacos. No uses nombres, direcciones de correo electrónico ni otros
datos personales como ID. Las respuestas de analíticas nunca devuelven ID de
usuario ni de sesión sin procesar.
Abre el resumen en el panel
- Abre Analíticas en el panel de LogBrew.
- Selecciona un proyecto.
- Selecciona 24 horas, 7 días, 14 días, 30 días o Personalizado.
- Lee el gráfico de actividad y después Eventos principales y Superficies principales.
- Abre Cobertura y límites antes de leer los recuentos de usuarios.
Lee el resumen del proyecto
--until <RFC3339> para indicar un final exclusivo. --interval acepta
auto, 1m, 5m, 15m, 1h, 6h o 1d. --top-limit define las filas de
cada lista de principales, de 1 a 20. El valor predeterminado es 10.
Añade --service, --release o --environment para filtrar por un contexto
exacto. El endpoint de la API es GET /api/telemetry/analytics/overview.
El resumen contiene los totales de actividad, una serie temporal, las acciones
principales y la actividad clasificada. Este fragmento muestra los totales y su
cobertura:
subject_coverage suman summary.actions. Solo
identified_user_events cuenta para los usuarios. anonymous_actions incluye
los otros cuatro estados. En este ejemplo, 8 eventos de sujetos anónimos
vienen de unos 7 sujetos anónimos distintos. Ninguno de los dos números es un
recuento de usuarios. Una lista de principales truncada no demuestra que falten
los eventos con menos volumen.
analysis_level es no_data, event_only, user_level o
user_and_session. Indica qué preguntas pueden responder los datos. El nivel
es el más alto que admite summary o classified_activity. No significa que
los dos grupos tengan usuarios o sesiones.
Mantén separados los dos grupos de actividad
Las vistas de pantalla y las interacciones clasificadas también son acciones.
No sumes
summary.actions a classified_activity.summary.events. Lee la
cobertura del grupo que uses. Los recuentos de sujetos de
classified_activity.coverage.subject_coverage suman
classified_activity.summary.events.
summary.actions puede ser 0 mientras las vistas de página clasificadas
aportan recuentos de usuarios y sesiones. Revisa classified_activity antes de
concluir que no hay actividad de producto.
Sigue la siguiente acción
next_action tiene un code, un target y un reason. Muestra la carencia de
captura más importante o el siguiente paso del análisis:
Cambia la captura en la app y después revisa un evento nuevo. Los eventos
anteriores no demuestran que el cambio funcione.
Llama directamente a la API
Envía un token bearer de cuenta. Envíaresponse_version=3 para obtener la
misma respuesta que lee la CLI. Si omites response_version, la API devuelve
la versión 1, que no tiene recuentos de sujetos anónimos ni
subject_coverage.
since es una duración positiva, como 24h, 7d o 30d, o una marca de
tiempo RFC3339. until es una marca de tiempo RFC3339 opcional. El intervalo
de tiempo incluye since y no incluye until. Si omites until, el intervalo
de tiempo termina en el momento de la solicitud. El intervalo de tiempo no
puede superar los 31 días.
Para el periodo del 12 al 16 de abril de 2026, envía 2026-04-12T00:00:00Z
como since y 2026-04-17T00:00:00Z como until.
Un intervalo de tiempo de más de 31 días devuelve HTTP 422:
code y next_action en la lógica del programa. Muestra error y next
a las personas. Errores de la API enumera las demás
respuestas de error.
Las rutas POST de analíticas que siguen reciben un cuerpo JSON con los mismos
campos project_id, since, until, service_name, release y
environment. Se rechazan los campos desconocidos del cuerpo.
Mide un embudo
Un embudo mide la conversión a través de dos a ocho pasos ordenados:--unit identified-user para contar usuarios entre sesiones.
Copia los nombres de los eventos del resumen. La proporción entre dos totales
sin relación no es una tasa de conversión.
El último paso debe ocurrir dentro de la ventana de conversión, que empieza en
el primer paso. Defínela con --conversion-window, por ejemplo 30m o 1h.
El valor predeterminado es 24 horas, o todo el intervalo de tiempo si es más
corto. La ventana no puede ser más larga que el intervalo de tiempo.
La ruta de la API es POST /api/telemetry/analytics/funnel. La
respuesta del embudo ordenado
muestra el cuerpo de la solicitud y la respuesta.
Explora las rutas alrededor de un evento
Las rutas muestran las secuencias más comunes de eventos con nombre después o antes de un evento ancla:preceding en lugar de following para los eventos anteriores al ancla.
--depth define el número de eventos de ese lado, de 1 a 8. El valor
predeterminado es 4. --path-limit define el número de rutas, de 1 a 20.
El valor predeterminado es 10. Los eventos idénticos consecutivos cuentan
como un solo evento. Añade --keep-repeated para conservar cada uno.
Las rutas usan ID de sesión. Una ruta posterior empieza en la primera ancla de
cada sesión. Una ruta anterior termina en la última ancla. Las rutas no cuentan
usuarios ni muestran por qué falló una acción. La ruta de la API es
POST /api/telemetry/analytics/paths.
Lee la retención
La retención muestra si los usuarios identificados regresan después de un evento inicial:--interval es hour, day, week o thirty-day. thirty-day son 30 días,
no un mes natural. --interval-count va de 1 a 31. El valor predeterminado
es 10. --mode return-on cuenta los regresos en cada periodo exacto.
return-on-or-after cuenta los regresos en cada periodo o después.
Un regreso debe ocurrir después del evento inicial del usuario. Cada usuario
empieza una sola vez, en el primer evento inicial del intervalo de tiempo. Ese
evento no siempre es el primer evento del usuario. Un usuario que regresa más
de una vez en un periodo cuenta una sola vez en ese periodo.
Lee el recuento de usuarios retenidos junto con el de usuarios elegibles de
cada periodo. Los usuarios cuyo periodo aún no ha terminado no son elegibles.
No cuentan como perdidos. Por ejemplo, 40 usuarios que regresan de 100
usuarios elegibles es una retención del 40 %. Una tasa de regreso menor no
muestra por qué se fueron las personas.
Solicita la retención de toda la actividad
La ruta de la API esPOST /api/telemetry/analytics/retention. Para medir la
retención sin nombres de eventos, envía response_version 2 y omite
start_event y return_event:
query.activity_scope en all_classified_activity.
Cualquier vista de página, vista de pantalla o interacción posterior cuenta
como regreso. Para elegir eventos, omite response_version y envía
start_event y return_event como
{ "kind": "page_view", "event_name": "/signup" }.
El intervalo de tiempo dividido entre el intervalo y multiplicado por
interval_count debe ser 500 o menos. Por ejemplo, 14 días con day y 10
periodos da 140. Si omites interval, la API usa hour para intervalos de
tiempo de hasta 48 horas y day para los más largos.
Lee el ciclo de vida
El ciclo de vida coloca a los usuarios identificados que hicieron un evento en un grupo por periodo:
«Nuevo en el historial observado» no significa un cliente nuevo. La actividad
anterior puede quedar fuera de la ventana del historial, que defines con
--history-periods. No sumes los totales de los periodos para contar usuarios
únicos en el intervalo de tiempo.
--history-periods va de 2 a 31 periodos antes de since. El valor
predeterminado es 2. El historial no puede superar los 62 días. El intervalo
de tiempo puede tener como máximo 100 periodos. Cada periodo tiene
fully_observed, que es false cuando el periodo no ha terminado. «Inactivo»
significa sin actividad en el periodo actual, no perdido para siempre.
La ruta de la API es POST /api/telemetry/analytics/lifecycle. Para usar toda
la actividad clasificada en lugar de un evento, envía response_version 2 y
omite event:
Compara dos periodos
Solicita cada periodo por separado. Usa el mismo proyecto, la misma duración, los mismos nombres de eventos y los mismos filtros. Compara la actividad, la mezcla de eventos y la cobertura de identidad y de sesión antes de comparar los recuentos de usuarios. Un periodo incompleto puede mostrar menos actividad que uno completo.
Cuando un resultado apunte a un fallo, lee las incidencias y los logs
relacionados del mismo proyecto y del mismo periodo. Abre una traza solo cuando
un evento tenga un enlace exacto a ella. Compartir el intervalo de tiempo no
demuestra que un error causara un descenso.
Para repetir una comparación, anota el ID del proyecto, los dos intervalos de
tiempo UTC, el intervalo, los filtros, la unidad, la cobertura y los estados de
truncado. No anotes ID de usuario sin procesar.
Para los campos de respuesta y los errores, lee la
API de telemetría y Errores de la API.