Skip to content
Back to Analytics & Experimentation

Session Analysis

Grouping events into sessions and analyzing session-level behavior —length, depth, exit point —to understand engagement beyond single events.

Why

An event tells you what happened; a session tells you the story. A user who fires 'project_created' and leaves has a different story from a user who fires 'project_created', 'project_configured', 'deploy_started', 'deploy_succeeded', 'invited_teammate' in one session. Session analysis is how you distinguish these stories: it groups events into a continuous interaction (typically 30 min of activity or a gap of 30 min ends a session), and then measures the session's properties —length (events per session), depth (distinct features used), exit point (last event before the gap), and path (the sequence of events). These session-level metrics are what answer 'are users getting deeper into the product?' and 'where do sessions end?', which are questions that event-level analysis cannot answer. A product where sessions get longer and deeper over time is healthy; a product where session count goes up but depth stays flat is acquiring users who bounce, and the session analysis is what reveals the difference.

When

When you need to understand engagement quality (not just event counts), or when designing onboarding/retention. Requires a session model (timeout-based or explicit logout).

How

1. Define the session model: a session is a sequence of events by the same user with no gap > 30 min (industry standard; adjust based on your product —a banking app may use 10 min, a content app 60 min)
2. Implement sessionization: assign a session_id to each event, incrementing when the gap since the last event > timeout. This is done in the analytics pipeline (not the client) for consistency
3. Compute session-level metrics:
   - session_length: count of events in the session
   - session_duration: time from first to last event
   - session_depth: count of distinct feature areas touched
   - exit_event: the last event before the session ended
   - entry_event: the first event of the session
4. Analyze the distribution: median session length, P90, the % of 1-event sessions (bounces), the % of deep sessions (depth >= 3)
5. Segment by user cohort: new users have shorter sessions than returning users; users from paid ads have different session patterns than organic
6. Track session-level metrics over time: is median session length increasing? is bounce rate (1-event sessions) decreasing? these are leading indicators of product health
7. Use session paths (the sequence of events) to identify common flows and friction —a session that goes [view_dashboard, view_project, error, exit] is a friction flow
8. Join session data with funnel data: a user who completes the deploy funnel in one session is different from one who completes it across 3 sessions, and the session-funnel join reveals this

Example

# Session analysis: Sep 2026 cohort
Session model: 30-min timeout  n=38,200 sessions

Session length distribution:
  1 event (bounce):  34%  (12,988)
  2-3 events:        28%  (10,696)
  4-10 events:       24%  (9,168)
  11+ events:        14%  (5,348)
  Median: 2 events  P90: 12 events  Mean: 5.3

Session depth (distinct features):
  depth 1: 38%  (single feature, likely viewing)
  depth 2: 31%
  depth 3+: 31%  (multi-feature, engaged)

Top exit events (where sessions end):
  page_close (implicit):     42%
  view_dashboard (idle):     18%
  deploy_succeeded (goal!):  12%  <- good exit
  error:                     8%
  logout:                    3%

Trend (vs Aug):
  Median session length: 2 -> 2 (flat)
  Bounce rate: 36% -> 34% (improving)
  Deep sessions (depth 3+): 28% -> 31% (improving)
  Goal-exit (deploy_succeeded): 10% -> 12% (improving)

Interpretation: bounce rate and deep-session rate are improving,
  meaning new users are getting past the first interaction and
  into the product. Median length is flat because the improvement
  is in the distribution tails (fewer bounces, more deep sessions),
  not the middle. This is a healthy trend that event-level
  analysis (total events) would miss.

Common Problems

  • ⚠Using a fixed 30-min timeout for all products —a banking app where users check balance and leave in 2 min should use a 10-min timeout; a content app where users read for 45 min should use 60 min; the wrong timeout merges or splits sessions incorrectly.
  • ⚠Counting sessions instead of users —a power user with 20 sessions/day inflates the session count and dominates the averages, making the product look more engaged than it is; report both session and unique-user metrics.
  • ⚠Ignoring session depth —'sessions are getting longer' is good only if the length is from depth (more features) not from repetition (same feature 10x); without depth, length is ambiguous.
  • ⚠Not joining sessions with funnels —a user who deploys in one session is different from one who deploys across three, and the session-funnel join is what reveals the 'time-to-deploy' distribution that onboarding should optimize.

Best Practices

  • ✓Choose the session timeout based on your product's natural interaction length, not the 30-min default —a 2-min banking session and a 45-min reading session need different timeouts, and the wrong choice merges or splits sessions.
  • ✓Report session metrics alongside unique-user metrics —sessions show engagement intensity, users show reach; reporting only sessions lets power users dominate, and reporting only users hides the engagement quality.
  • ✓Always include session depth alongside session length —length without depth is ambiguous (10 events in one feature vs 10 events across 5 features), and depth is what distinguishes 'exploring' from 'stuck in a loop'.
  • ✓Join session data with funnel data to measure time-to-conversion across sessions —'median time from signup to first deploy is 2.3 sessions over 4 days' is a richer metric than '26% convert', and it is what onboarding should optimize.