Skip to main content
Product analytics shows how people use your app. LogBrew reads the product actions that your app sends, including page views, screen views, and interactions. Use Product event capture to send these events with user and session context. Every result is for one project and one time range. A service name does not select a project. Logs and issues are separate signals. Their presence does not mean that analytics data exists for the same range.

​
Events, users, and sessions

For example, 200 actions in 20 sessions do not mean that 20 people used the app. Event totals are exact for the selected window. Unique user, session, and anonymous-subject counts are approximate. Use opaque IDs. Do not use names, email addresses, or other personal data as IDs. Analytics responses never return raw user or session IDs.

​
Read the project overview

Add --until <RFC3339> for an exclusive end time. --interval accepts auto, 1m, 5m, 15m, 1h, 6h, or 1d. The API endpoint is GET /api/telemetry/analytics/overview. The overview contains activity totals, a time series, top actions, and classified activity. This excerpt shows the totals and their coverage:
The five subject_coverage counts add up to summary.actions. Only identified_user_events counts toward users. anonymous_actions includes the four other states. A truncated top list does not show that lower-volume events are absent. analysis_level is no_data, event_only, user_level, or user_and_session. It shows which questions the data can answer. next_action suggests the next capture or analysis step, such as identify_product_users or sessionize_product_activity. Make that change in the app, then check a new event. Older events do not show that the change works. classified_activity counts page views, screen views, and interactions. Some of those events are also actions. Do not add summary.actions to the classified totals.

​
Measure a funnel

A funnel measures conversion through two to eight ordered steps:
Each later step must occur after the earlier step. The default unit is the session. Use --unit identified-user to count users across sessions. Copy the event names from the overview. A ratio of two unrelated totals is not a conversion rate.

​
Read retention

Retention shows whether identified users return after a start event:
--interval is hour, day, week, or thirty-day. --interval-count is from 1 to 31. --mode return-on counts returns in each exact period. return-on-or-after counts returns in or after each period. Read the retained count with the eligible count for each period. Users whose period has not ended yet are not eligible. They are not counted as lost. For example, 40 returned users of 100 eligible users is 40% retention. A lower return rate does not show why people left.

​
Read lifecycle

Lifecycle puts identified users who did one event into one group per period:
New in observed history does not mean a first-time customer. Earlier activity can be outside the history window, set with --history-periods. Do not add period totals to count unique users across the range.

​
Compare two periods

Request each period separately. Use the same project, duration, event names, and filters. Compare activity, the event mix, and identity and session coverage before you compare user counts. An incomplete period can show lower activity than a complete one. When a result points to a failure, read the related issues and logs for the same project and time. Open a trace only when an event has an exact trace link. A shared time range does not show that an error caused a drop. For response fields and errors, read the Telemetry API and API errors.