Skip to content
accs-net.com

Press Esc to close

session_start

Glossary · 6 min read ·

session_start is the automatically collected event GA4 fires the moment a new session begins — the starting gun from which session counting, session IDs and session-scoped attribution all flow. You never send it yourself: the tag detects that no session is active and emits the event on its own. This entry covers the mechanics of the event itself — when it fires, the ga_session_id and ga_session_number parameters it mints, the timeout rules, and the counting quirks. For the broader concept of what a session is and how session metrics behave in reports, see the session entry; here we stay close to the machinery.

When session_start Fires

GA4’s tag keeps a lightweight notion of “a session is running” per browser. When an event is about to be sent and no session is active — the visitor just arrived, or came back after a timeout — the tag emits session_start first, then the event that triggered it. Three situations produce it:

  • A genuinely new visit — first pageview of the morning fires session_start, then page_view.
  • Return after inactivity — the visitor left a tab open through lunch; with the default 30-minute timeout, the afternoon click starts a fresh session.
  • A new day is not one of them. Unlike Universal Analytics, GA4 sessions do not reset at midnight, and a mid-session campaign change does not split the session either. A visit that runs 23:50–00:20 is one session in GA4 where UA would have counted two.

The Parameters It Mints

When the session begins, GA4 generates two values that then stamp every event in the session as event parameters:

Parameter What it is
ga_session_id The session’s identifier — in practice a Unix timestamp of the session start. Paired with the client ID, it uniquely names one session of one browser.
ga_session_number A counter: this visitor’s first session is 1, their tenth is 10. The fastest signal of new-versus-returning depth you have at event level.

These two parameters are the connective tissue of GA4’s model. Any event can be assigned to its session by the (client ID, session ID) pair — which is exactly how session-scoped dimensions get built, how the BigQuery export lets you reconstruct sessions with SQL, and how debugging ties a stray conversion back to the visit that produced it.

The Timeout, and Where to Change It

A session ends when no event arrives for the timeout period — 30 minutes by default, adjustable per web data stream between 5 minutes and 7 hours 55 minutes (Admin → Data streams → your stream → Configure tag settings → Adjust session timeout). Two operational notes:

  • Longer is not safer. Stretching the timeout to hours merges genuinely separate visits into one session, deflating session counts and inflating session duration. Change the default only for a documented reason — a long-form video site where 40 quiet minutes mid-content are normal, say.
  • The timeout is inactivity-based, not length-based. A session that keeps receiving events can run all day. There is no maximum session length in GA4 — another difference from UA habits.

Counting Quirks Worth Knowing

  • Sessions are an estimate. GA4 counts sessions by estimating the number of unique session IDs rather than tallying session_start events one by one. The estimate is accurate at normal scales, but it is why the “Sessions” metric and a manual count of session_start events in BigQuery can disagree by a hair — and why neither is “wrong.”
  • Cross-midnight sessions belong to their start date… mostly. Reports slice by event date, so a session spanning midnight contributes events to two dates while remaining one session. Daily session sums therefore need not equal the period total — normal, not a bug.
  • Engagement is a separate ledger. A session that bounces in three seconds still fired session_start. Whether it becomes an engaged session — ten seconds, a conversion, or two pageviews — is decided afterwards by engagement time and events, not by the start event.
  • Blocked starts happen. Ad blockers and consent refusals can suppress the tag entirely; those visits produce no session_start and simply do not exist in GA4. If server logs and GA4 sessions diverge, this gap is the first suspect.

session_start and Traffic Attribution

The start of a session is also where its traffic source is decided. Session-scoped dimensions — session source, session medium, session campaign — derive from the first traffic signals of the session: the UTM parameters or referrer on the entry that fired session_start. Everything later in the same session inherits that origin; a mid-session click on a tagged internal link does not re-source the session (it corrupts it — a separate problem covered under UTM hygiene). Two implications:

  • A visitor who arrives from email at 9:00 and returns direct at 15:00 produces two sessions with two different session sources — correct and intended. The person-level view of “how did they first find us” lives in user-scoped first-touch dimensions instead.
  • Attribution debugging starts at the session boundary: if a campaign’s sessions look misattributed, inspect the actual entry URLs of sessions — the parameters present at session_start time are the ground truth the reports were built from.

Anomalies Seen in the Wild

  • Doubled session_start — nearly always a double-installed tag (theme + plugin both loading GA4) or two configuration calls. The visible symptom is inflated sessions with halved engagement rates.
  • Sessions splitting on a domain hop — a checkout or booking flow on a second domain without cross-domain tracking configured starts a fresh session mid-purchase, and the conversion lands in a direct/referral session disconnected from the ad that earned it.
  • Session undercount against server logs — consent refusals and ad blockers suppress the tag for a slice of visitors; those sessions never exist in GA4. The gap is a property of measurement consent, not a tag bug.
  • Timeout mismatch between properties — comparing two GA4 properties with different session timeouts produces incompatible session counts by definition. Check the setting before declaring one property broken.

Using session_start in Analysis

The event itself is mostly plumbing, but a few direct uses are worth having in the toolkit:

  • Landing-page truth. The page where session_start fired is the session’s real entry point — useful in Explorations when the landing-page dimension needs verifying.
  • Depth cohorts via ga_session_number. Registering nothing, you can still segment “first-session users” vs “session five and beyond” in Explorations — a poor man’s loyalty cohort with zero setup.
  • Session reconstruction in BigQuery. SELECT events grouped by user_pseudo_id, ga_session_id rebuilds sessions row by row — the foundation of almost every custom session analysis on the export.

Frequently Asked Questions

Do I need to send session_start myself?

No — it is automatically collected, and sending your own would create duplicate noise. If you see doubled session_start events, look for a double-installed tag or two configuration calls, not for a missing setting.

Why don’t my daily sessions add up to the weekly total?

Sessions that cross midnight contribute events to two dates while counting as one session, and the sessions metric itself is a statistical estimate of unique session IDs. Small discrepancies between summed days and the period total are expected behaviour.

Does a new campaign or a new day start a new session in GA4?

No to both — these are Universal Analytics behaviours that GA4 dropped. Only inactivity past the timeout (default 30 minutes) ends a session; the next event after that starts a new one.