Understanding Sessions and the session_start Event in Google Analytics 4

A session is a period during which a user interacts with your website or app. Although Google Analytics 4 is built around events, it still groups related events into sessions so that analysts can understand individual visits, traffic acquisition, engagement, and conversion behavior.

Every session provides a context for the events collected during that visit. A page view, scroll, form submission, purchase, or custom event can be connected to the same session through automatically generated parameters. Understanding how this relationship works is especially important when comparing the Google Analytics interface with BigQuery, sending server-side events through Measurement Protocol, or investigating differences between session and event reports.

Contents

What Counts as a Session

In Google Analytics 4, a session begins when a user engages with an app or website and no session is currently active. For a website, this normally occurs when the user opens or views a page. For an app, it occurs when the app becomes active in the foreground. At the beginning of the visit, Analytics automatically collects a session_start event and generates a session ID and session number. Google Support

A session does not correspond exactly to an open browser tab, login period, or authenticated application session. It is an Analytics-defined grouping of events. A user can remain logged into a product while several Analytics sessions begin and end, and a browser tab can remain open after the Analytics session has expired.

By default, a web session ends after 30 minutes of inactivity. Inactivity means that Google Analytics has not received events indicating continued interaction during the timeout period. The session does not end merely because 30 minutes have passed since the first page view. A user can remain in the same session for several hours if events and engagement continue to be recorded.

If the user returns after the inactivity threshold has been exceeded, Analytics begins a new session. The returning user may receive the same client identifier, but the new visit receives a different ga_session_id and a higher ga_session_number.

The standard timeout can be changed in the web data stream settings. A longer timeout may be appropriate for a SaaS workspace, educational platform, long-form media product, or research interface in which users spend extended periods reading, watching, or working without generating frequent page views. A shorter timeout may be useful when the business needs Analytics sessions to more closely reflect short operational visits.

Changing the timeout affects more than average session length. A shorter threshold generally produces more sessions because one user journey can be divided into several visits. A longer threshold can combine interactions that would otherwise be reported separately. This can affect sessions per user, engagement rate, session-scoped attribution, and comparisons with historical data.

The Analytics session timeout should not be confused with a website’s security timeout. A banking interface may log a user out after ten minutes for security reasons while the Google Analytics configuration uses a different period. The two systems serve different purposes and do not automatically share session state.

GA4 also handles some boundaries differently from Universal Analytics. A continuing session does not automatically restart at midnight, and a new campaign source encountered during an active session does not necessarily create a new session. This is one reason GA4 session totals should not be expected to reproduce historical Universal Analytics totals exactly.

How Events Relate to Session ID and Session Number

When a session starts, Google Analytics automatically collects the session_start event and generates two important parameters: ga_session_id and ga_session_number. These parameters are then associated with events collected during the session. Google Support

The session ID is based on the timestamp, in seconds, at which the session began. It identifies a session within the activity of a particular user or client instance. However, it should not be treated as a globally unique identifier by itself. Two different users can begin sessions during the same second and therefore have the same numeric ga_session_id.

When session-level analysis is performed in BigQuery, the standard approach is to combine a user identifier with the session ID. For anonymous website traffic, the most common combination is:

Google identifies the combination of user_pseudo_id or user_id and ga_session_id as the standard basis for counting unique GA4 sessions outside the reporting interface. Google Developers

The session number indicates the sequential number of the session recognized for that user or client instance. A value of 1 normally represents the first recognized session, while values such as 3 or 5 indicate that earlier sessions were recorded under the same identifier.

This number should not be interpreted as a perfect count of the person’s lifetime visits. It depends on the identifiers available to Analytics. The same person can receive a new client identifier after clearing cookies, switching browsers, using private browsing, moving to another device, reinstalling an app, or changing consent status. In those situations, the session number may begin again even though the person has interacted with the business before.

A properly implemented user_id can improve cross-device analysis for authenticated users, but it should be handled carefully in BigQuery. The field may be absent during anonymous events and appear only after authentication. Replacing user_pseudo_id with user_id without a defined identity strategy can split one journey or combine events inconsistently.

The distinction also matters when diagnosing inflated session counts. Counting distinct ga_session_id values alone can merge sessions belonging to different users. Counting every event that contains a session ID can produce the opposite problem by counting one session repeatedly. The intended unit is the unique combination of the user context and session ID.

How Sessions Link with Other Events

For events collected through the Google tag, Google Tag Manager, or the Google Analytics for Firebase SDK, the active session ID and session number are normally added automatically. Events such as page_view, scroll, form_submit, purchase, and custom events can therefore be grouped into the same session.

This grouping allows Analytics to connect a chain of interactions. A user may arrive through a paid search ad, view a landing page, open a product page, begin checkout, and complete a purchase. If the events retain the same client and session identifiers, the sequence can be analyzed as one visit.

Client-side collection usually manages this relationship automatically. Problems can still arise when several Google tags are initialized incorrectly, when duplicate tags create duplicate events, when cross-domain tracking is incomplete, or when identifiers are lost during redirects and payment flows.

Server-side Google Tag Manager does not inherently break the session. When browser events are sent through a server container, the relevant client and session values can remain associated with the events. The implementation must preserve the parameters received from the web or app source rather than creating an unrelated identifier for each server request.

Measurement Protocol requires more deliberate handling. Events sent directly from a backend system do not automatically inherit the browser session simply because they belong to the same customer or transaction. The request should include the appropriate client or app instance identifier, and the event parameters should contain the correct session_id when the event needs to be associated with an online session. Google also identifies session_id and engagement_time_msec as important parameters for user activity to appear correctly in reports such as Realtime. Google Developers

Without those values, the purchase may still be collected, but it can be difficult to associate with the correct session, traffic source, or engagement metrics. This can produce unattributed revenue, session-scoped dimensions reported as (not set), or discrepancies between client-side and backend reporting.

For accurate engagement reporting, Google recommends including engagement_time_msec in Measurement Protocol events. The parameter represents the engagement time since the preceding event and helps Analytics place user activity correctly in Realtime and engagement metrics. Google Developers

Session parameters are also not automatically added to arbitrary imported data. A Data Import record can enrich existing Analytics data, but it does not create the same client-side session context as an event generated through the Google tag or Firebase SDK.

In some datasets, events can contain a valid session ID even when the corresponding session_start event is not visible. This can occur when a subproperty filter excludes the start event, when only part of the event stream is exported, when Measurement Protocol events are sent without an explicit start event, or when the selected date range contains events from a session that began earlier.

The absence of a visible session_start row should therefore not automatically be interpreted as proof that the remaining events had no session context. Analysts should inspect the event parameters and collection method before deciding how the events should be grouped.

How the Number of Sessions Is Calculated

Google Analytics does not calculate reliable session totals by counting distinct ga_session_id values alone. Because that value is unique only within a user context, a session should be identified by the combination of a user or client identifier and the session ID.

In the Google Analytics interface, the Sessions metric is generated through GA4’s processed reporting system. Standard reports and the Data API can use cardinality estimation rather than an exact row-by-row distinct count. Google uses the HyperLogLog++ algorithm for common unique-count metrics, including sessions, so a small difference between the interface and an exact BigQuery calculation can be expected. Google Developers

In BigQuery export, analysts have access to granular event rows and can define an exact session key. The following simplified query extracts ga_session_id from the repeated event_params field and counts unique user-session combinations:

WITH events_with_session AS (
  SELECT
    user_pseudo_id,
    (
      SELECT value.int_value
      FROM UNNEST(event_params)
      WHERE key = 'ga_session_id'
    ) AS ga_session_id
  FROM `project.dataset.events_*`
  WHERE _TABLE_SUFFIX BETWEEN '20260701' AND '20260731'
)
SELECT

COUNT(

DISTINCT CONCAT(

user_pseudo_id,

'-',

CAST(ga_session_id AS STRING)

)

) AS sessions

FROM events_with_session

WHERE user_pseudo_id IS NOT NULL

AND ga_session_id IS NOT NULL;

This query is intentionally simplified. A production implementation may need to account for user_id, consent-related records, events without a pseudonymous identifier, data stream differences, and the organization’s reporting identity rules.

Counting session_start events can produce a useful diagnostic metric, but it is not always identical to the Sessions metric. An event stream may contain session-linked events without a visible session_start. Conversely, duplicate implementation issues can produce unexpected start events. Measurement Protocol, filters, partial exports, delayed events, and selected date boundaries can all contribute to differences.

The date range requires special attention. In GA4, a session can continue across midnight. When BigQuery sessions are calculated separately for each day and the daily totals are added together, a session spanning two dates can be counted twice. Google recommends counting the unique combination of user identifier and session ID across the full analysis period rather than reproducing the Universal Analytics practice of resetting sessions at midnight. Google Developers

Late-arriving events can also affect comparisons. Google notes that daily BigQuery export tables may be updated for up to 72 hours with events timestamped for an earlier date. Measurement Protocol and offline app events are common sources of delayed data. Comparisons between the interface and BigQuery should therefore use sufficiently mature dates rather than relying only on the latest day. Google Developers

Other differences can come from Google Signals, Consent Mode modeling, reporting identity, attribution processing, sampling in Explorations, report thresholding, high-cardinality aggregation, property filters, and time-zone differences. BigQuery contains collected event data but does not reproduce every form of processing or modeling used in standard reporting.

When numbers do not match, the first step is to confirm that the compared values use the same date range, time zone, filters, identity logic, and metric definition. A technically correct BigQuery query can still disagree with the interface if it answers a different question.

Session Start and First Visit

The session_start event is automatically collected when Google Analytics recognizes the beginning of a session. It requires no separate event setup when the website uses the Google tag or the app uses the Google Analytics for Firebase SDK. The event generates the session ID and session number that can be associated with the remaining events in the visit. Google Support

The first_visit event has a different purpose. For web measurement, it is collected the first time Analytics recognizes a visit from a particular browser or client instance with Analytics enabled. For installed apps, the related automatically collected event is first_open, which is triggered when the app is first launched after installation or reinstallation.

A first_visit should not be interpreted as proof that a person has never interacted with the business before. It indicates a newly recognized client context. The same individual can generate several first visits by using a second browser, moving to another device, clearing cookies, using private browsing, or returning after browser storage has been removed.

The opposite can also occur. Several people using the same browser profile may share one client identifier and may not generate separate first-visit events. Analytics identifies devices, browser instances, app installations, and supplied user IDs—not people with perfect certainty.

The difference is visible in ordinary traffic. A returning user can start a new session every day while generating first_visit only once for that browser identifier. If the person clears the Analytics cookie, the next visit can produce both a new first_visit and a new session_start.

Google defines the New users metric as the number of unique users who logged first_visit or first_open in the selected date range. The metric is useful for analyzing newly recognized users, but its interpretation depends on cookie persistence, consent, platform identifiers, and cross-device measurement. Google Support

Implementing user_id can help Analytics associate signed-in activity across devices and browser contexts. It does not mean that every anonymous event before login can be identified perfectly, and it does not change the underlying fact that first_visit is generated in a client context rather than from verified knowledge of the person’s complete history.

This distinction matters for acquisition analysis. A marketing report may show a user as new because the browser identifier is new, even though the customer previously purchased through another device. Conversely, CRM records may identify an existing customer while GA4 records a first visit from a new browser.

Session_start and User Engagement

The session_start and user_engagement events describe different parts of the visit. The first marks the beginning of the session. The second helps Analytics measure active time when an app is in the foreground or a webpage is in focus.

Google documents user_engagement as an automatically collected event triggered when the app is in the foreground or the webpage is in focus for at least one second. The event uses the engagement_time_msec parameter to report accumulated engagement time. Google Support

The event should not be confused with an engaged session. An engaged session is a session that meets at least one of three conditions: it lasts longer than the configured engagement threshold, contains a key event, or includes at least two page views or screen views.

The default time threshold is 10 seconds, but it can be adjusted in the web data stream settings. Increasing the threshold makes the time-based condition stricter, although a session can still qualify through a key event or multiple views.

A second user may open one page, keep it in focus for 15 seconds, and leave without another page view or key event. That session can qualify because it exceeded the engagement threshold. A third user may view two pages within five seconds and qualify through the page-view condition.

For this reason, the presence of a user_engagement event is not the sole definition of an engaged session, and the event should not be described as firing only when the user spends more than ten seconds, views several pages, or completes a conversion.

Engagement time is also different from elapsed session duration. Engagement time measures the period during which the webpage is in focus or the app is in the foreground. A browser tab that remains open in the background does not represent the same level of active attention.

The engagement_time_msec parameter can be attached to events other than user_engagement. Google explains that first_visit and session_start do not contain this parameter because no engagement time has elapsed since a preceding event. The value is accumulated as the user continues interacting with the page or app. Google Support

When server-side activity is sent through Measurement Protocol, session_id alone does not provide complete engagement context. Google recommends including engagement_time_msec for accurate Realtime and engagement reporting. The value should represent the milliseconds of engagement since the preceding event rather than an arbitrary total session duration. Google Developers

Engagement rate is calculated as engaged sessions divided by total sessions. Bounce rate is the percentage of sessions that were not engaged, making it the inverse of engagement rate in GA4. Neither metric should be evaluated without considering the site’s purpose. A short session can still be commercially successful if the user immediately completes a key event, while a long session can indicate either strong interest or difficulty finding information.

The practical distinction is therefore clear: session_start establishes the visit, ga_session_id connects events to that visit, user_engagement contributes active-time information, and the engaged-session rules determine whether the visit qualifies as meaningfully engaged in GA4 reporting.