Bounce Rate vs Engagement Rate: What Each One Counts

What bounce rate actually measures

Bounce rate is a ratio with a deliberately simple rule. Take every session that started on your site, count the ones where the visitor saw a single page and did nothing that registered a second interaction, and divide by total sessions. In the classic form, the "second interaction" is just a second pageview. That is all it means.

The simplicity is the appeal. You can explain it to anyone in one sentence, and you can compute it from nothing but a pageview log. It is also the reason the metric has a bad reputation: it treats two very different visits as identical. A reader who lands on your pricing page, closes the tab after four seconds and a reader who lands on a tutorial, reads it for five minutes and leaves both count as one bounce each.

That is not a bug in the arithmetic. It is a consequence of what the metric was built to detect: pages that fail to move a visitor onward. On a page whose job is to send people somewhere else (a landing page, a category page, a search results page), a high bounce rate is a real warning. On a page whose job is to answer a question (a docs page, a blog post, a recipe), a high bounce rate is often what success looks like.

What a "session" means changes the number

Every bounce figure depends on how a tool defines a session. Cookie-based tools typically stitch a visit together with an identifier and a time-based expiry. A cookieless tool has to choose another boundary. GhostMetrics uses the browser tab: the tracker keeps a pageview counter in sessionStorage, and the counter is cleared when the tab closes. A "session" is one tab's lifetime, with no cookies and no visitor IDs involved.

That choice matters when you compare tools. Someone who opens your site, leaves the tab open overnight and clicks a second page the next morning is one session in a tab-scoped model. Someone who opens two articles in two separate tabs is two sessions, each with one page, so each can be a bounce. Neither tool is wrong; they are counting different things.

What GA4's engagement rate measures

When Google replaced Universal Analytics with GA4, it dropped the old bounce rate and introduced engaged sessions. A session counts as engaged if it meets any one of three conditions: it lasts longer than a time threshold, it includes a conversion event (GA4 now calls these key events), or it includes two or more page or screen views. Engagement rate is engaged sessions divided by total sessions. GA4 also exposes a bounce rate again, defined as the share of sessions that were not engaged, so in GA4 the two figures are complements of each other.

The thresholds are configurable and Google has adjusted the reports over time, so check the current Google Analytics documentation before you quote a number. The point for this article is structural: GA4 added a time condition and a conversion condition to the old "second pageview" rule.

That redefinition is a fairer measure of attention. A reader who stays on a long article for several minutes is engaged in GA4 even if they never click anything. It also changes the reading of historical data: the same site can show a noticeably different bounce rate after moving from Universal Analytics to GA4, with no change in visitor behavior at all. If you have ever compared a pre-migration and post-migration chart and wondered what happened to your traffic quality, the definition is the first thing to check. Our migration walkthrough covers what changes when metrics are defined differently across tools.

What GA4 does well here

Be fair to GA4: the conversion condition is genuinely useful. If a visitor lands, fills in a form and leaves, that session is engaged, which matches reality, whereas the classic definition scores it as a bounce. And because GA4 ties sessions to events and, where consent allows, to users, you can analyze engagement by audience, by campaign and by ad platform in ways a cookieless tool does not attempt. The cost is the consent banner and the weight of the tag; see whether GA4 is GDPR compliant for that side of the trade.

Why the two numbers disagree

Put the same traffic through both definitions and four visit shapes land in different buckets. The table lists each shape and how the classic bounce rule and the GA4 rule score it.

The second row is where most of the disagreement lives. Content sites, documentation and blogs produce a lot of long single-page reads, so they typically see classic bounce rates that look alarming and GA4 engagement rates that look healthy for the same readers. Neither figure is lying; the second row simply sits on opposite sides of the line.

The practical conclusion: never put a bounce rate from one tool next to an engagement rate or a bounce rate from another and call one "better". You are comparing rulebooks, not sites. When you change tools, expect the headline figure to move on day one with no change in your audience, and record the date so you can explain the step change later.

How GhostMetrics reports bounce, time on page and scroll depth

GhostMetrics reports the classic definition and does not try to reproduce GA4's engaged-session rule. Concretely: the tracker counts pageviews per tab in sessionStorage. Bounce rate on the dashboard is the pageviews flagged as bounces divided by entry pageviews, and the flag is set when the leave beacon, sent as the tab is hidden or unloaded, reports a session depth of 1. In plain terms, a bounce is a single-page session in that tab. It is not GA4's rule of 10 seconds, a conversion or 2+ pageviews. The flag depends on that leave beacon arriving, so a tab that disappears without sending one (a crashed browser, a killed process) is simply not counted as a bounce. Bounce rows recorded before 16 October 2026 over-counted multi-page sessions, so do not compare a pre-October figure with a later one without allowing for that.

Three implications follow from that design, and all of them are worth knowing before you act on a number:

• It is evaluated at departure. The flag depends on the leave beacon, so the figure reflects visits where the tab was hidden or unloaded and the beacon was sent. A visitor who switches away from the tab on their first page and later comes back and clicks through still carries the bounce flag, because the beacon already fired at depth 1. As with any leave-time signal, treat small movements as noise.
• It is tab-scoped. Two tabs are two sessions. A reader who opens a link from a newsletter, reads, then opens another page from your site in a new tab will register as two single-page sessions.
• There is no user identity. No cookie, no visitor ID, no cross-session link. You cannot ask "what is the bounce rate of returning visitors", because the product has no concept of one.

The metrics that give a bounce its context

Because a classic bounce hides what happened on the page, the dashboard pairs it with other views, all available on the free plan:

• Time on page, with a time-on-page distribution, so you can see whether single-page visits were four seconds or four minutes.
• Scroll-depth funnel, showing what share of pageviews reached 25%, 50%, 75% and 100% of the page. The deepest scroll point is held in page memory and sent with the leave beacon; it is not stored on the visitor's device.
• Entry pages and exit pages, so you can see which pages start visits and which end them.
• Referrers and source types (search, social, direct, referral) and the UTM breakdown, so you can see which channels bring entries. The panels show visit counts, not bounce per channel; for that, group the raw CSV export by referrer or utm_campaign.
• Custom events through data-gm-event or window.ghostmetrics.track, so you can count the action that matters on a single-page visit, such as a click on a signup button.

Together these answer the question the headline bounce rate cannot: was a single-page visit a failure or a finished job? Our guide to tracking custom events without Google Analytics shows how to wire up the action that defines success on a page.

One honest gap: GhostMetrics has no single "engagement rate" number. There is no conversion rule folded into bounce, and no per-visitor funnel. If a combined engagement score is what your team reports on, GA4 supplies one and the dashboard here does not.

A worked example with made-up numbers

The figures below are illustrative, not benchmarks. Suppose a blog post receives 1,000 entry pageviews. Of those, 800 are flagged as bounces under the classic rule, so the bounce rate reads 80%. That looks terrible until you find the post in the pages table and see an average time of several minutes and an average scroll depth near the bottom of the article.

Read together, those views say: the article is doing its job and people leave after finishing it. In GA4, many of the same visits would be engaged sessions on the time condition alone, and the reported engagement rate would look fine. Same readers, same behavior, two headline numbers that point in opposite directions.

Now invert it. A landing page with a 40% bounce rate sounds healthy, but if its average time on page is only a few seconds and the click events on the signup button are near zero, the second pageview may be accidental navigation rather than interest. A low bounce rate can be as misleading as a high one when the page's real goal is an action. That is the reason to count the action directly.

How to read these numbers honestly: a checklist

Run through this once a week. It takes a few minutes and it keeps one metric from steering your decisions alone.

1. Group pages by job. Split your pages into "answer" pages (blog, docs, guides) and "route" pages (home, pricing, category, landing). Judge bounce rate within a group, never across groups.
2. Check the entry pages first. Bounce rate only applies to pages where sessions start. Open the entry pages view and look at the busiest ones, not the whole-site average.
3. Read average time on page for each busy entry page in the pages table, and the site-wide time-on-page distribution for the overall shape. Very short visits are a real bounce in spirit. Long visits on an answer page are a satisfied reader.
4. Check average scroll depth on answer pages. If readers typically reach the end, a high bounce rate is fine. If most leave in the first screen, the headline, the intro or the page load is the problem.
5. Split by source. Compare referrers and source types. Search visitors, social visitors and newsletter visitors read differently, and a site-wide average blends them. The panels give visits per source; for bounce per source, group the raw CSV export by referrer or campaign. UTM-tagged links make this clean; see the UTM guide.
6. Count the action, not just the exit. Put data-gm-event="signup-click" or a similar name on the button that defines success, then compare the event count against entry pageviews on that page.
7. Compare against yourself. Look at the same page week over week, not against an industry figure. Your own history is the only baseline that shares your definition of a session.
8. Write down any definition change. If you switch tools, install a tracker change or turn a banner on or off, note the date next to the chart. Step changes in bounce rate are usually definitional.

Mistakes that distort the story

Chasing a site-wide target

A single target like "bounce rate under 50%" ignores page type. Pushing an answer page's bounce rate down usually means adding forced clicks (pagination, "read more" gates, auto-playing related links), and those make the reader's experience worse while improving the metric. If a change makes the number better and the page worse, the metric stopped measuring what you wanted.

Treating time on page as precise

Time on page is a timing estimate, not a measure of attention. A reader can leave a tab open while making coffee. Use it as a shape (the distribution) and not as a precise duration for one visit. That is also why the distribution view is more useful than the average.

Comparing across tools

The most common mistake is putting a classic bounce rate and a GA4 figure side by side during a migration and concluding that traffic quality changed. Run both tools in parallel for a few weeks and note the offset instead. The same advice applies when you compare different cookieless tools: check each one's definition of a session before comparing results. Our cookieless analytics comparison puts the main tools side by side.

Ignoring non-human and unusual traffic

A burst of single-page sessions from one referrer can be a link in a chat app, a scraper or a misconfigured campaign link. Before you rewrite a page for a bounce rate spike, check the referrers and the source types for the dates in question. A spike of "direct" visits is a hint to check how links are tagged; the direct traffic explainer covers what a missing referrer can and cannot tell you.

Reading a single-page app like a multipage site

In a single-page app, navigating between views does not reload the page. GhostMetrics is SPA-aware: a pushState or popstate navigation counts as a new pageview, so an app that routes client-side can register depth above 1 where a naive tracker would see a bounce. If you compare against a tool that only counts full page loads, expect a gap.

Which metric for which question

Pick the metric from the question you are asking, not from habit.

If your question is about speed, the vitals panel is the right companion; see real-user Core Web Vitals monitoring for how to read it. GhostMetrics captures FCP, LCP, CLS and TTFB from real users and does not capture INP.

The short version: GA4's engagement rate answers "did this session meet a bar of activity?", and classic bounce rate answers "did this visitor go anywhere else?". Both are legitimate questions. Neither answers "was the visitor satisfied?", and nothing in a cookieless or a cookie-based tool does that on its own. Combine a bounce figure with reading depth and a counted action, and you are as close as page-level analytics can get.

FAQ

Keep reading

Disclosure: GhostMetrics is built by Null Agency and we use it on this site, so we are not a neutral party about our own product. GA4's definitions and thresholds are set by Google and change over time; check the current Google Analytics documentation before quoting exact figures. The numbers in the worked example are illustrative, not benchmarks.