Skip to main content
Sessions group a user’s events into a single visit. Every event carries a session ID, so you can answer questions like “how many sessions included a purchase” or “what did this user do in their last session.”

How sessions work

A session starts when the SDK initializes (app launch, first page load) and ends when the user is inactive for longer than the session timeout (30 minutes by default) or exceeds the max session length (24 hours by default). On web, the session ID is persisted to localStorage so page navigations continue the same session. Every event sent during a session shares the same 16-byte session ID. When a session expires and the user returns, a new session ID is generated and all subsequent events are grouped under it. Sessions are tracked alongside a device ID — a persistent identifier for the physical device. The device ID stays the same across sessions; the session ID rotates.

Session lifecycle

On mobile (iOS, macOS, visionOS), the SDK observes app lifecycle events and sends context events at each transition: Active/inactive transitions (e.g. pulling down notification center) update internal state but don’t generate context events — they happen too frequently to be useful.

Session timeout

The default timeout is 30 minutes. If a user backgrounds your app and returns within 30 minutes, the same session continues. If they return after 30 minutes, a new session starts. You can configure this at initialization:

Max session length

Sessions are capped at 24 hours by default to prevent zombie sessions from tabs left open indefinitely. When the max length is reached, the session rotates even if the user is still active.

Context data

Each context event carries a snapshot of the device and app environment. On mobile SDKs, this is collected automatically — you don’t need to send it yourself.

Automatically collected properties

Device App Screen System Locale Session

Adding custom context

Use super properties to attach custom context to every event:
On the server side, pass context as event properties. There’s no fixed schema — the properties field accepts any key-value data, so you can enrich events with whatever is relevant to your application.

Device IDs

The device ID is a 16-byte UUID that persists across sessions and app updates. Mobile SDKs generate and store the device ID automatically. You never need to manage it yourself.

What gets attached to events

Every event (track, identify, group, revenue, alias) automatically gets:
  1. Device ID — from the session manager
  2. Session ID — from the session manager
  3. Minimal device contextdevice_type, operating_system, os_version, app_version (if device context enrichment is enabled)
  4. Timestamp — current time unless overridden
You don’t need to pass any of this manually. The SDK handles it.

Manual session control

You can force a new session at any time:
Call reset() to clear the current user, generate a new anonymous ID, and stop the current session. The next event starts a fresh session.

What’s next