GA4Google Analytics 4Google's event-based analytics platform for measuring website and application behavior.Browse All Terminology → engagement rate is the percentage of sessions that meet Google’s engaged-session rule. GA4 bounce rate is the inverse: the percentage of sessions that do not meet it.
Neither metric tells a copywriter how much of an individual page someone consumed.
That is not a criticism of the calculation. It is a scope problem. Engagement rate and bounce rate classify sessions. A page-quality investigation needs evidence tied to the page, its sections, and the action the page is supposed to support.
I use GA4 engagement and bounce rate as coarse checks. For content diagnosis, I add heatmapping and custom Google Tag ManagerGoogle Tag ManagerA tag-management system used to configure and deploy measurement and marketing scripts.Browse All Terminology → scroll events at 10%, 25%, 50%, 75%, and 90%. The distribution shows where attention appears to stop, while the heatmap helps explain what people encountered there.
The Short Answer
In GA4:
Engagement rate = engaged sessions / total sessions
Bounce rate = non-engaged sessions / total sessions
Bounce rate = 1 - engagement rateCheck the inputs, permissions, limits, and failure path before using this in production.
Google defines an engaged session as one that meets at least one of these conditions:
- lasts longer than 10 seconds;
- has a key eventKey eventA GA4 event marked as important to the business and made available for conversion-oriented reporting.Browse All Terminology →; or
- has at least two page or screen views.
Those rules are documented in Google’s current engagement rate and bounce rate guidance.
The calculation can answer, “What percentage of sessions cleared this engagement rule?” It cannot answer, “Did people read this page?”
Universal Analytics Bounce Rate Meant Something Else
Universal Analytics bounce rate was often paraphrased as the percentage of people who left the website. That shorthand was never precise enough.
Google’s legacy definition was a single-page session that triggered only one request to the Analytics server. If someone opened an article, read it carefully, and left without sending another interaction hit, Universal Analytics could count the session as a bounce and assign it a duration of zero seconds. The system had no second hit with which to calculate elapsed time.
That meant a bounce could describe at least two very different experiences:
- a visitor immediately decided the page was wrong; or
- a visitor got the complete answer from one page and left satisfied.
An interaction event could prevent a bounce even if the visitor never loaded another page. A poorly designed event implementation could therefore make bounce rate look healthier without making the experience better. Google’s archived Universal Analytics bounce-rate definition documents both the single-request calculation and the zero-second limitation.
UA bounce rate was useful for diagnosing some landing-page problems. It was never a clean measure of reading, satisfaction, or page quality.
GA4 Reframed the Question Around Engagement
GA4 initially emphasized engaged sessions and engagement rate rather than carrying the Universal Analytics bounce calculation forward.
That was conceptually better. The new model could recognize time, a key event, or a second page or screen instead of treating every one-hit session as equivalent.
People still wanted the familiar bounce-rate label. On July 11, 2022, Google added bounce rate to GA4 and stated plainly that it was calculated differently from Universal Analytics.
The GA4 version did not restore the old metric. It gave users the inverse of engagement rate:
A GA4 bounce is a session that did not last longer than 10 seconds, did not contain a key event, and did not contain at least two page or screen views.
So a UA bounce rate and a GA4 bounce rate with the same percentage do not mean the same thing. Comparing them as one continuous historical metric is not defensible.
Why GA4 Engagement Rate Is Better—and Still Too Coarse
GA4’s definition is better at recognizing that a useful session can happen on one page. It is also more flexible across websites and apps.
The cost of that flexibility is that several unlike behaviors collapse into one “engaged” outcome.
| What happened | GA4 session result | What it says about the page |
|---|---|---|
| A visitor reads one article for four minutes and leaves | Engaged through time | The tab stayed active long enough; reading depth is still unknown |
| A visitor spends 15 seconds deciding the page is wrong | Engaged through time | The opening may have failed despite the engaged session |
| A visitor immediately clicks to a second page | Engaged through two page views | The first page may have helped, confused, or merely redirected them |
| An automatically firing event is incorrectly marked as a key event | Engaged through a key event | The metric may reflect an implementation defect |
The third row matters to content teams. A person can load a page, do almost nothing with its copy, and click to another page. GA4 has correctly identified a multi-page session. It has not proven that the first page’s argument, evidence, or call to action worked.
The fourth row is why an engagement-rate audit should include implementation. A duplicate page_view, an event marked as a key event too broadly, or an event that fires automatically can make nearly every session qualify as engaged.
Engagement Rate Is Session-Scoped, Not Page-Scoped
Google classifies engagement rate and bounce rate as session metrics in its dimensions and metrics reference.
That scope does not disappear when the metric is placed beside a page dimension.
If the report uses Landing page, the row groups sessions by the page on which they began. A session can qualify as engaged because of behavior later in the journey. The landing page receives the session classification, but the qualifying second page view or key event may have occurred elsewhere.
If the report uses Page path or Page title, the interpretation becomes even easier to overstate. Page dimensions describe events associated with pages; engagement rate describes sessions. The table can be valid while the sentence “this page has a 72% engagement rate, therefore its copy is good” is not.
This is the same scope discipline required when comparing first-user and session acquisitionSession source / mediumThe source and medium associated with the start of a particular GA4 session.Browse All Terminology → data in GA4. A familiar metric does not override the scope of the fields around it.
Before using engagement rate as page evidence, ask:
- What dimension is on the row?
- What exactly caused these sessions to qualify as engaged?
- Did that behavior occur on this page or later in the session?
- What page-specific evidence would support the content conclusion?
The Built-In GA4 Scroll Event Is Only a 90% Flag
GA4 enhanced measurement can collect a scroll event without custom code. Google’s enhanced measurement documentation states that it fires the first time 90% of a page’s vertical depth becomes visible.
That is useful for one question: did the visitor reach approximately the bottom?
It cannot distinguish between someone who stopped after the opening and someone who consumed three quarters of a long guide. Both fail to produce the built-in event.
For page-quality work, I want the shape of attention loss, not one bottom-of-page flag.
The Five-Threshold Scroll System I Use
I configure a Google Tag Manager vertical scroll-depth trigger at:
10% → scroll_10
25% → scroll_25
50% → scroll_50
75% → scroll_75
90% → scroll_90Check the inputs, permissions, limits, and failure path before using this in production.
Each threshold is sent as a distinct event. That makes the thresholds immediately usable in GA4 explorations and reports without requiring an analyst to reconstruct the distribution from the built-in 90% event.
I start the trigger at window load rather than DOM ready. Images and other content can still change page height after that point—especially when lazy loading is involved—but waiting for the load event reduces the chance that the threshold denominator is calculated while the initial page is still sizing.
The public version of the implementation deliberately omits client container IDs, property IDs, page volumes, and production naming details. The measurement pattern is the useful part.
The thresholds still need the same destination, consent, firing-order, and deduplication checks as any other analytics event. The companion guide to auditing the live Google Tag Manager container covers that implementation boundary.
Turn One Session Label Into a Page Diagnosis
- Outcome→
Start with the key event or business action the page is intended to support.
- Scroll Distribution→
Compare the share reaching 10%, 25%, 50%, 75%, and 90% using an explicit denominator.
- Heatmap→
Inspect the sections, controls, or layout patterns near the largest loss of continuation.
- Session Cross-Check
Use engagement and bounce rate to spot broad traffic or implementation anomalies—not to grade the copy alone.
Define the Denominator Before Reporting Scroll Rate
Event counts alone do not produce a page-quality rate.
If scroll_50 fired 4,000 times, the number means little until the report states what had the opportunity to reach 50%.
Depending on the question, the denominator might be:
- views of that page;
- sessions that landed on that page;
- users who viewed that page;
- eligible views after excluding pages shorter than the viewport; or
- views within the same device and page-length band.
For copy diagnosis, I usually want a page-view-based distribution:
50% depth rate = eligible page views with scroll_50 / eligible page viewsCheck the inputs, permissions, limits, and failure path before using this in production.
For landing-page analysis, session-based denominators can be appropriate, but they answer a different question. Do not mix a user denominator at 10% with a session denominator at 90%, and do not compare a mobile article with a desktop landing page without segmenting the structural differences.
Read the Shape, Not Just the Final Threshold
A scroll distribution turns “the page underperformed” into a more focused investigation.
| Pattern | Working interpretation | First place to inspect |
|---|---|---|
| Sharp loss from 10% to 25% | The page did not earn the next scroll | Query or ad-message match, headline, hero, opening promise |
| Steady decline through the page | Normal attention decay may be occurring | Compare with similar pages and outcomes before changing anything |
| Concentrated loss near 50% | A middle section may create friction or look like an ending | Dense copy, interruptive modules, layout break, misplaced CTA |
| Strong continuation to 75%, then collapse | Readers may consume the body but miss the final action | Ending, CTA placement, footer-like visual cues |
| High 90% with weak outcomes | Exposure is not the same as persuasion | Offer, action clarity, form friction, audience intent |
These are hypotheses, not automated verdicts. The distribution points to where I should inspect. It does not explain the cause by itself.
Heatmapping Supplies the Missing Page Context
Scroll thresholds tell me where continuation changes. Heatmaps and session-level observation help show what users encountered there.
I use heatmapping to investigate questions such as:
- Are people clicking an element that does not behave like a link?
- Does a visual section look like the end of the page?
- Are mobile users encountering a much taller block than desktop users?
- Is an important CTA placed below the point where most readers stop?
- Are people skipping a dense section and resuming below it?
Heatmaps also need skepticism. A click map does not explain intent. A recording is a sample, not the population. Consent requirements, blockers, and sampling can make observed behavior incomplete. The tool narrows the investigation; it does not remove the need to inspect the implementation and connect behavior to an outcome.
What Scroll Depth Still Cannot Prove
Scroll is a deliberate motor action, but it is not a comprehension test.
A person can drag the scrollbar to the bottom in one movement. A short page can expose the 90% threshold immediately. Sticky elements and lazy-loaded sections can alter the effective page height. A mobile viewport can generate a very different progression from a desktop viewport. A person can read a visible section carefully without crossing the next threshold.
That is why I do not replace one universal score with another.
The practical hierarchy is:
- Outcome events: Did the intended action occur, and does the event mean what its name claims?
- Scroll distribution: Where did page exposure and continuation change?
- Heatmapping and observation: What did users encounter at that point?
- Engagement and bounce rate: Does the broader session pattern support or challenge the diagnosis?
For an article, scroll depth can reveal that most eligible views never reached the worked example. For a lead page, it can show that the form sits below the observed attention ceiling. For a documentation page, a strong 90% rate can still be a warning if users were forced to hunt for one missing answer.
A Practical GA4 Page-Quality Report
For each important page, I would include:
| Report field | Purpose |
|---|---|
| Eligible page views | Denominator for depth rates |
scroll_10, scroll_25, scroll_50, scroll_75, scroll_90 rates | Continuation distribution |
| Primary CTA or key-event rate | Intended outcome |
| Device category | Prevent structurally unfair comparisons |
| Landing-page sessions | Separate entrances from internal page views |
| Source, medium, and campaign | Detect message or audience mismatch |
| Engagement and bounce rate | Coarse session cross-check |
| Page length or template group | Compare like with like |
I would annotate major content, layout, tracking, and campaign changes. Otherwise a shifted distribution can be attributed to the wrong cause.
The report should never hide the event definitions. If scroll_50 changes from 50% of document height to visibility of a specific element, the metric name may look stable while its meaning changes.
The Better Question
Do not ask whether engagement rate or bounce rate is the “right” GA4 metric.
Ask what decision the metric can support.
Use engagement rate to describe how many sessions met Google’s engagement rule. Use bounce rate when stakeholders prefer the inverse framing, while making the GA4 definition explicit. Use neither as a standalone grade for a page.
For page quality, connect a governed outcome to a page-specific scroll distribution, inspect the loss points with heatmapping, and keep the session metrics as context.
That produces a more honest conclusion than “bounce rate went down.” It tells the writer, designer, or analyst where attention appears to stop, what evidence supports the interpretation, and what still needs to be tested.