The basic rule:

A session is a contiguous sequence of events from a single user, separated from adjacent sessions by a period of inactivity. The industry-standard threshold is 30 minutes of inactivity (Google Analytics default, Mixpanel default, etc.).

In SQL:

WITH flagged AS (
  SELECT
    user_id, event_ts,
    LAG(event_ts) OVER (PARTITION BY user_id ORDER BY event_ts) AS prev_ts,
    CASE WHEN event_ts - LAG(event_ts) OVER (PARTITION BY user_id ORDER BY event_ts)
              > INTERVAL '30 minutes'
         THEN 1 ELSE 0 END AS is_new_session
  FROM events
)
SELECT
  user_id, event_ts,
  SUM(is_new_session) OVER (PARTITION BY user_id ORDER BY event_ts) AS session_id
FROM flagged;

The running sum of 'session boundary' flags creates a per-user session ID.

Edge cases and design decisions:

Threshold choice. 30 minutes is a default, not a law.
- Video streaming: longer (a user might watch a 2-hour movie with no events).
- Quick-interaction apps (social feeds): shorter (5-10 min).
- Audio/podcast apps: very long, often no timeout at all.
Sessions that span midnight. Does a session started at 23:59 that ends at 00:15 count as today or yesterday? Typically: attribute to the day the session started.
Login across devices. User opens the app on phone (10:00), switches to laptop (10:05). Is that one session or two?
- Device-level sessions: two (each device has its own session).
- User-level sessions: one (the user was continuously active).
- Both valid, measure different things.
Background events. Apps that sync in the background emit events without actual user engagement. If you include them, 'sessions' become meaningless — everyone's always active.
Session start without a discrete 'app open' event. Some telemetry pipelines don't emit an explicit 'session start' event; you have to infer it from the first user action after a gap.
Server-side vs. client-side. If the server defines sessions by request intervals, network hiccups can artificially split sessions.

Business decisions that flow from this:

'Average session duration' is meaningless without naming the timeout.
'Sessions per user per week' compares badly across products with different timeout defaults.
A/B testing 'session length' is fragile — the same underlying behavior can yield different 'session length' numbers depending on the threshold.

Stakeholder framing: "Before I answer 'how long is a typical session,' what timeout do we use? If it's 30 minutes, we'll get one number; if it's 5 minutes, we'll get a much shorter one. Our answer depends on it."

What senior candidates add: session analysis is fundamentally about inferring user intent from noisy behavioral data. It's an inherently fuzzy operationalization — which is why defining 'a good session' (one with a completed core action) is often more decision-useful than defining 'a session at all.'

How do you define a session?

Draft your answer

Stuck? Peek at a hint

More product metrics questions