What Is a GA4 Session? Differences from UA and How to Read the Counting Conditions
Published:
Last Updated:
Category: Web Analytics
Published:
Last Updated:
Category: Web Analytics
Authors: Shusaku Yosa
When people look up what a session is in analytics, most articles explain the definition and how to check it. In practice, though, what trips people up is not the definition itself but the counting conditions: under what circumstances a session is counted as one. This article organizes, from a technical angle, the exact moments a GA4 session starts and ends and what criteria are used to aggregate events into a single session, alongside how this differs from the older Universal Analytics (UA). If you have moved from UA to GA4 and feel your session numbers no longer match, you will see that the cause lies in these counting differences.
A session is a unit representing a continuous block of time during which a user interacts with a website or app. It groups a user's behavior from arrival to departure as a single visit, and the number of those groupings is aggregated as the session count. Whereas pageviews (PV) count how many times a page was displayed, a session counts a grouping of behavior called a visit, which is the key difference.
In GA4, sessions are managed with an event called session_start as the trigger. When a user arrives, session_start is recorded automatically, and at the same time a ga_session_id (session ID) and ga_session_number (session number) are generated to identify the session. Every subsequent event that user fires is tagged with the same session ID, and GA4 bundles the group of events sharing that session ID into one session. In other words, the GA4 session count is effectively aggregated as the number of times the session_start event occurs.
To read session counts correctly, you need to understand the boundary conditions of when a new session begins and when it ends. GA4's counting conditions are considerably simpler than UA's.
In GA4, a session starts and session_start is recorded when a user views a page or screen in the following states.
When no active session currently exists (first visit)
When a page is viewed again after a previous session has timed out
For apps, when the app is opened in the foreground
The important point is that in GA4, only re-display while no active session exists acts as the trigger to start a new session. Unlike UA (discussed below), a change of traffic source or a date change does not become a start condition.
As a rule, there is only one condition that ends a session in GA4.
No interaction (event) occurs for 30 minutes after the last event (timeout)
As long as the user is viewing pages or events are firing, the countdown to timeout resets each time and the session keeps being extended. Conversely, if no event occurs for more than 30 minutes, the session is considered to have ended at that point. Note that it does not end the instant the browser is closed: even after closing, if the user returns within 30 minutes, it continues as the same session.
This timeout is 30 minutes by default, but it can be changed in the GA4 admin settings and extended up to a maximum of 7 hours and 55 minutes. On sites where intervals between interactions tend to be long, such as long videos or long-form reading content, the timeout may not fit reality and sessions can be split, so consider adjusting it as needed.
GA4 reports include a metric called engaged sessions, separate from sessions. Because the two use different counting criteria, it helps to sort out how they should be read so you don't confuse them.
Of all sessions, those that meet any of the following conditions are counted as engaged sessions.
Sessions that lasted longer than 10 seconds
Sessions in which a key event (formerly a conversion) occurred
Sessions in which two or more pageviews or screenviews occurred
In other words, a session where the user left almost immediately, staying under 10 seconds and viewing only one page, is included in the session count but not in engaged sessions. When assessing site quality, checking not just the raw session count but also the share of engaged sessions (the engagement rate) gives an evaluation closer to reality.
Between GA4 and UA, the word session means the same thing, but the specifications for when a session is divided (reset) differ significantly. This gap is the biggest reason session numbers shift after migration. Let's look at the representative differences condition by condition.
The timeout mechanism, in which a session ends after 30 minutes of no interaction, is common to both UA and GA4. The default value is 30 minutes in both, and both allow the setting to be changed. On this condition alone, there is no difference between UA and GA4.
In UA, if the traffic source (referrer/medium) changed midway through a session, the session was cut off at that point and a new one began. For example, if a user arrived from Google Search and then returned within 30 minutes via Yahoo! Search, UA measured this as two sessions. In GA4, even if the traffic source changes, as long as it is within 30 minutes it is treated as the same session and the count stays at one. In this case, the session's source/medium retains the first traffic source.
In UA, if a session crossed the date boundary partway through, the session was divided there and a new one began. For example, a session starting at 11:59 p.m. would end once at 12:00 a.m. and a second session would begin. In GA4, even when crossing the date boundary, if interaction continues the session is not cut off and continues to be counted as one session.
UA built sessions using the hit as its basic unit, whereas GA4 treats everything as events and uses the occurrence of the session_start event as the session's starting point. This fundamental difference in the measurement model is what leads to the differences in the division conditions above.
30 minutes of inactivity: both UA and GA4 split (shared)
Change of traffic source: UA splits / GA4 does not
Crossing the date boundary: UA splits / GA4 does not
Basis of counting: UA is hit-based / GA4 is the session_start event count
Because of these counting-condition differences, GA4 tends to count fewer sessions than UA for the same user behavior. What UA split into separate sessions on a change of traffic source or a date crossing is, in GA4, bundled into a single session as long as the return happens within 30 minutes.
Therefore, a mismatch between UA and GA4 session counts is not an anomaly but normal behavior as specified. When evaluating post-migration numbers, rather than forcing the two to reconcile, the practical point is to use GA4's measurement criteria as a consistent yardstick and read the trends and comparisons within it.
GA4 sessions are managed with the session_start event as the trigger and are counted by simple rules: the start condition is re-display while no active session exists, and the end condition is a timeout from 30 minutes of inactivity. The change of traffic source and the date crossing that were start and end conditions in UA do not divide sessions in GA4, so for the same behavior the session count tends to be lower than in UA.
Once you have these counting-condition differences down, you can read GA4 session counts correctly and use them as a solid foundation for measuring the effect of acquisition efforts and for site improvement.
A screen-by-screen guide to reading GA4 standard reports: the snapshot, realtime, the life-cycle reports (acquisition, e...
What the GA4 API (Data API) is, what you can do with it, and how it differs from BigQuery export. Covers examples of app...
Learn how to create an access analysis report that gets read—the basic "acquisition to behavior to results" structure, h...
