session_start

When it fires

In the browser, on the first entry after 30 minutes of inactivity, and whenever the referring host changes. A referrer pointing at your own site is an internal navigation and does not cut a visit: without that rule every full page load would start a new one.

Sessions are cut on the client, once, and never re-derived on the server. Only the client knows the tab is the same tab. A server sees a run of entries carrying one anonymous id and would have to guess the same rule from worse information, on every read, forever.

In a desktop app one run is one session. .NET and Tauri announce it at start-up when lifecycle tracking is on, and again whenever the session is rotated: a session nothing ever announces sits on every later entry and is counted by nothing. The Python client does not write it, and the Node and Go clients have no lifecycle at all.

Attributes

None of its own. The entry is the fact that it happened, and what it carries is what every entry carries.

Every entry also carries the resource its client sends once per batch: session.id, user.id once you have called user(), and the rest of the list on the overview. Anything you pass yourself lands in the same map, and your key wins on a collision.

What it never carries

The new session id is not a payload on this entry. It is on the resource, which puts it on this entry and on every other entry of the visit equally, and that is what makes grouping by session work at all.

Questions it answers

A widget is a filter, a group by, an aggregate, a time bucket and a limit. These are those five parts written out, and every one of them is something you can build yourself.

See also

• page_view
• app_launch
• Identity