Exit Rate vs Bounce Rate: Definitions and How to Analyse Exits in GA4
Published:
Last Updated:
Category: Web Analytics
Authors: Shusaku Yosa
Exit rate describes how often a page is the end of a measured journey, but the legacy Universal Analytics %Exit metric and GA4 exits and bounce rate are different measures. Before comparing numbers, identify the product, numerator, denominator and reporting scope. A finished article and an abandoned application can both be the last page in a session.
Define exit rate and label the legacy UA formula
In legacy UA, %Exit was the proportion of a page’s views that were the last view in a session: page exits divided by that page’s page views, multiplied by 100. This is a historical definition from the UA exit-rate documentation, not a statement that the same standard percentage exists unchanged in GA4.
If page B had 20 views and five were session-ending views, the legacy calculation would be 25%. That does not mean 25% of people left: one session can contain repeated views. If you create an exit-to-view ratio from GA4 data, state that definition explicitly, use consistent page and date scopes, and avoid presenting it as a guaranteed reproduction of UA %Exit.
Distinguish UA bounce from GA4 non-engaged sessions
Measure | Definition or denominator | Important distinction |
|---|---|---|
Legacy UA %Exit | Page exits divided by page views | Not divided by entrances or people |
Legacy UA bounce rate | Sessions beginning on a page with no further interaction | One page alone is not the complete condition |
GA4 Exits | Times the last session event occurred on a page or screen | Not the physical instant a browser closes |
GA4 bounce rate | Non-engaged sessions divided by sessions | Cannot be inferred from page count alone |
GA4 engagement rate | Engaged sessions divided by sessions | Complements bounce rate under the same conditions |
The legacy bounce definition includes the absence of an additional interaction; a single-page session with additional interaction measurement is a different case. GA4 bounce rate instead counts non-engaged sessions. Under the default description, a session is engaged if it lasts longer than ten seconds, includes a qualifying key event, or has at least two page or screen views.
The web stream’s engagement timer can be adjusted, so check the setting when comparing periods or properties. The automatic first_visit, first_open and session_start events do not establish an engaged session even if marked as key events. Engagement also does not prove that someone read every word or was satisfied.
Use Entrances and Exits in a GA4 exploration
GA4 Entrances and Exits refer to the first and last event in a session on a page or screen. They are available in Explore without additional collection setup specifically for those metrics. Google’s official example uses a free-form exploration with Page title and screen class, Entrances and Exits.
- Select the correct property and period, then create a free-form exploration.
- Add Page title and screen class and the Entrances and Exits metrics, then display them by page.
- Check for different pages sharing a title. Confirm compatible dimensions or filters before adding a hostname or more precise page identification.
- Read the counts alongside the page’s purpose and the next actions you can actually verify.
Entrances, exits and sessions need not reconcile in every date range: a session can enter and exit on different days, and some starts do not include a page or screen view. Explorations also depend on event-data retention. Record unavailable history rather than filling it with invented zeros.
Work through page paths, counts and denominators
This fictional example assumes four sessions complete inside one reporting period, all relevant events arrive without duplication or loss, and the final event’s page matches the end of each path. The web engagement timer remains at its default ten seconds. S2’s thirty seconds are measured and received; merely leaving a background tab open is not the assumption.
Session | Path | Engaged in this example? |
|---|---|---|
S1 | A → B | Yes: two page views |
S2 | A only; thirty measured seconds | Yes: default time condition met |
S3 | B → C | Yes: two page views |
S4 | A only; five seconds and no key event | No: none of the conditions met |
Page | Views | Entrances | Exits | Explicitly defined exits ÷ views |
|---|---|---|---|---|
A | 3 | 3 | 2 | 2 ÷ 3 × 100 = approximately 66.7% |
B | 2 | 1 | 1 | 1 ÷ 2 × 100 = 50% |
C | 1 | 0 | 1 | 1 ÷ 1 × 100 = 100% |
Three of four sessions are engaged, giving an engagement rate of 75%. One is non-engaged, giving a bounce rate of 25%. That session-level percentage is different from A’s 66.7% exit-to-view ratio. S2 demonstrates why a single-page visit is not automatically a GA4 bounce. Do not infer UA bounce rate from this GA4 event example.
Interpret exits in the context of page purpose and journeys
C’s 100% ratio could be expected if C is a completion page. A jump to an authentication provider can instead expose a gap in measurement coverage. Identify what should happen next before calling a high exit count a usability failure.
Observation | Possible explanation | Evidence to investigate |
|---|---|---|
Session ends on completion page | The required task may be finished | Accepted result and any remaining action |
User moves to authentication or another domain | Coverage may change | Destination, tagging scope and return path |
Session ends during a form | Error, unclear requirement or another reason | Reproduced interaction, visible error and acceptance record |
Session ends on an article | Answer found or intent mismatch | Search intent, next action and device experience |
Use behavioural evidence to build hypotheses. Heatmaps show measured interactions and scrolling; session recordings reconstruct activity. Neither directly establishes how much was read, satisfaction, or the reason for leaving. Keep the observed action separate from your explanation.
Check measurement before testing an improvement
- Define one page’s purpose and expected next action.
- Check missing or duplicate tags, consent, production hosts and external transitions.
- Compare counts under consistent periods, devices and acquisition conditions.
- Investigate a specific interaction or error before selecting one change.
- Review the same measures and verified successes after that change.
Do not make lower exits a universal objective. A concise answer may reduce time on page while fulfilling the visitor’s purpose. With small samples, report counts alongside percentages because a single session can change a rate substantially. If success conditions or duplicate handling remain unverified, key-event occurrences are not a count of registered people and the outcome remains unmeasured. Documentation was checked on 11 October 2026.
Related guides for the next step:
