Sessions
The Sessions page (sidebar Explore → Sessions) shows aggregated session analytics — how many sessions are happening, how long they last, and how cleanly they end.
A session in Beacon represents one continuous period of activity by an actor. Sessions are created and ended by the SDK based on StartSession() / EndSession() calls (or auto-managed by the JavaScript SDK, which rotates sessions after 30 minutes of inactivity).
When to use it
- Tracking engagement — are sessions trending up over time?
- Measuring session length — are people in your application long enough to find value?
- Comparing engagement across releases — did v1.4 increase or decrease average session length vs. v1.3?
- Spotting incomplete sessions — high “Timed Out” counts indicate users abandoning the app or the SDK never receiving an
EndSession()call.
If you only call Track() without StartSession(), the events are recorded but no session is created and Sessions stays empty.
Filters
A simple filter strip:
- Product — limit to one application.
- Source version — narrow to a specific release.
- Time range with presets and custom selection. Default is 30 days.
A built-in previous period comparison is always on — the page automatically computes a prior window of equal length and shows it as a comparison baseline on the trend charts and KPI deltas.
Sections
Session stats cards
Five cards summarizing the window:
- Total Sessions — sessions started in the window.
- Completed — sessions that ended (any reason — clean
EndSession()or timed out). This is the count of sessions for which an end has been recorded; the Timed Out card breaks out the subset that ended without a clean signal. - Timed Out — sessions that the server marked timed-out because no
EndSession()arrived within the expected window. Counted within Completed. A large or growing timed-out count usually indicates apps that crash or close without graceful shutdown. - Avg Duration — mean session length, in seconds.
- P95 Duration — 95th-percentile session length. Useful for understanding how long the longest 5% of sessions actually run; the average can hide long-tail behavior.
Each card shows a delta versus the previous period.
Session count chart
A time-series of session counts over the window (current period as the solid line, previous period as a lighter dashed line).
Session duration chart
A time-series showing Median (P50) and P95 session duration over the window. Plotting both means you can see typical session length and long-tail behavior in the same chart — useful when an average would hide one or the other.
Active actors chart
A time-series of distinct actors active in each time bucket — your engagement curve.
Session aggregate table
Below the charts, a paginated table aggregating sessions by date, product, and source version. Each row shows the session count, completed count, timed-out count, and average duration for that combination. Sortable by any column.
This is not a per-session log — Beacon doesn’t expose individual session rows on this page. Use Event Explorer and filter by session_id if you need to inspect the events within one session.
Data freshness
Sessions data is aggregated with the same 15-minute cadence as the rest of the Explore section. A session your application just started won’t appear here until the next refresh.
If you need to confirm a session is live right now (during integration testing), use the SDK’s getSessionId() (JavaScript) or check that your StartSession() call returned without error.
Common questions
Total Sessions is much lower than total events.
Expected — one session typically contains many events. If Total Sessions is zero but events exist, your application isn’t calling StartSession() (or its equivalent). Check the SDK setup guide for your platform.
A large fraction of sessions are Timed Out rather than cleanly ended. Three common causes:
- Application crashes — if the app crashes before
EndSession(), the session never closes cleanly. - Process kills — users force-quitting from the OS, especially mobile.
- Missing
EndSession()call in the SDK integration. Audit the application’s shutdown path.
The Avg Duration shows a very small number (e.g., 0.5s) but P95 is reasonable. Often means a few sessions started and ended almost immediately — debug-mode or test-fire calls. Sort the aggregate table by date and source version to find which builds are responsible.
Next
You’ve finished the core “exploring” guide. Continue with:
- Funnels, Retention & Churn, Exceptions, Segments, and Anomalies — the analytics surfaces that sit on top of your event data.
- Allowlists Basics — set up event allowlists and register version boundaries.
- Billing & Plans — view your plan and usage, upgrade or cancel.
- Troubleshooting — what to do when events don’t show up.