GA4 Sessions Explained: Session Start, Estimates, and UA Differences

GA4’s Sessions metric is not guaranteed to equal the event count for session_start. Sessions are estimated from session-identifying information. When comparing event counts, reports, or BigQuery calculations, align identifiers, dates, collection conditions, and aggregation rules before interpreting a difference.

How a session starts and receives identifiers

When no session is active, viewing a Web page or app screen, or opening an app in the foreground, starts a session. GA4 normally collects session_start and generates ga_session_id and ga_session_number. The former identifies the session; the latter indicates the user’s session sequence. See the official session documentation.

The default timeout is 30 minutes of inactivity and can be changed. This is not a 30-minute maximum duration for continuous activity. Closing a tab, leaving the website briefly, or crossing midnight does not by itself prove that another session has started. The introductory session timeline explains these visit boundaries alongside page views and users.

Separate the Sessions metric from start-event counts

GA4 uses HyperLogLog++ estimation, so a small difference from an exact calculation over observed data can occur. Estimation does not imply that the result must always be lower. Collection and reporting conditions can produce differences in either direction.

A BigQuery calculation is also limited to the exported data available to it. Consent-related gaps, missing identifiers, and late-arriving events can affect coverage. An exact count over that dataset is not automatically a complete count of every real-world visit.

Do not use ga_session_id alone as a globally unique key

The session ID represents the start timestamp in seconds. Different users starting within the same second can share that value. For custom aggregation, combine an appropriate user identifier, such as user_pseudo_id, with ga_session_id and document the chosen definition.

In a fictional example, users A and B both have session ID 1234567890. The combinations A + 1234567890 and B + 1234567890 represent two distinct keys. Deduplicating the session ID alone would produce one. Also report how many rows lack identifiers and how they are treated; silently discarding them or combining them into one session obscures the limitation.

Measurement Protocol and imported events do not necessarily receive session information automatically in the same way as standard collection. Design the required information according to the documented use case. Assigning one fixed session ID to every event simply to make totals agree would merge unrelated visits.

GA4 and historical UA use different boundaries

Use the GA4–UA comparison together with the historical UA session definition. UA behavior should not be copied into instructions for current GA4.

Suppose the same identified user views page A at 23:55 and page B at 00:05 in a fictional example. With no intervening timeout and healthy collection, GA4 keeps one session. UA split it at the date boundary. This can help explain lower GA4 counts, but it does not prove that every difference is expected.

UA is no longer a live collection option. Standard UA stopped processing new data in July 2023 and eligible UA 360 properties in July 2024. The official UA sunset notice provides the historical context for comparing stored exports.

Define date boundaries before adding rows

Daily rows, source-level rows, and a period total can use different deduplication or estimation scopes. Adding rows is not guaranteed to reproduce a separately calculated total. In a custom query, also distinguish sessions that started within the period from sessions with any observed event within it.

For a session crossing midnight, counting only its start event and identifying it from next-day activity answer different questions. Match the intended definition before comparing with GA4. The GA4 page-view reporting guide similarly explains how dimensions and filters affect page totals.

An engaged session is not a successful customer

By default, an engaged session lasts longer than 10 seconds, has an eligible key event, or includes at least two page or screen views. The time threshold can be configured. first_visit, first_open, and session_start do not qualify through the key-event condition even if marked as key events. These rules are explained in the engagement and bounce-rate documentation.

These are activity conditions, not evidence of registration success or satisfaction. Session duration also differs from engagement time while the site or app is in the foreground. Evaluate outcomes using verified success events and an explicit denominator.

A practical reconciliation sequence

1. Align property, dates, time zone, platform, and hostname.
2. Identify whether each value is a Sessions metric, event count, or custom calculation.
3. Match filters, comparisons, and grouping dimensions.
4. Inspect missing IDs, consent conditions, manual sends, duplicates, and delivery failures.
5. Check processing status and compare completed periods; do not promise every value is final within 72 hours.
6. Document the remaining difference as an estimation, collection, or boundary issue where supported.

The goal is an explainable, consistent measure of visits, rather than forcing unlike counts to match. Keep the extraction conditions with the result so later comparisons remain meaningful.