A grouping rule applied at read time. Events belonging to one actor are folded into a visit whenever the gap between them is under thirty minutes, producing a start, an end, a duration, per-kind counts and a one-line summary of where they were and what they did.
Also called: session grouping · how many visits · how long were they in there
- 1Events are ordered per actor and split wherever the idle gap exceeds thirty minutes.
- 2Each group yields start and end times, minutes, counts by kind, and a summary line.
- 3Consecutive identical events are folded with a repeat count so a session reads cleanly.
- 4The same thirty-minute window is used by the account-entry throttle, so one visit leaves one entry row.
The reasoning is about durability rather than convenience: 'A stored session id would have to survive token refreshes, multiple tabs and subdomain hops to stay honest; a gap rule needs none of that and can be recomputed differently later without a migration.' Aligning the entry throttle to the same window is what keeps the two views consistent — 'one visit should leave one enter row.'
- Stored session ids drift out of honesty across tabs, refreshes and host hops.
- A raw event list doesn't answer 'how many visits' or 'how long'.
- Changing the definition of a session would otherwise require a migration.
See it on your own jobs
Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.
or keep browsing features →