Universal Analytics gave us one of the most maligned metrics in our profession, and I miss it.

Bounce rate was crude on purpose. Any session that fired exactly one hit was a bounce. One pageview, nothing else, you're out. The definition skipped over time on page, ignored scroll depth, didn't care about engagement signals, and gave you a single column in the Pages report that answered one question very loudly. Of every visitor who landed on this URL, what share didn't earn a second click? You could rank pages by it and start optimizing the same morning. The metric was built for triage and it triaged.

GA4 retired it. Engagement rate is the headline metric now. A session counts as engaged if any of three conditions are met: it lasted at least ten seconds, it included at least two page views, or it included a key event. Bounce rate is whatever's left over. That phrasing matters. UA defined the bounce. GA4 defines the not-bounce, and bounce gets it by elimination.

The new definition is more sympathetic, by design. A reader who landed, read for forty seconds, and left used to be a bounce. Under GA4 they're engaged. That feels right when you say it out loud. The visitor got what they came for. Calling that a bounce always carried a whiff of overreach.

For a stretch, I treated that as progress.

What got lost in the trade

The UA definition was a single-question metric. Did this page earn a second click? GA4's engagement rate answers three different questions at once. A page sitting at a 78 percent engagement rate could be earning long reads, earning second clicks, sitting on a conversion path, or all three in different proportions. The page-level diagnostic is now a totally different signal.

UA's one test versus GA4's three-condition OR UA · ONE TEST session has more than one hit? NO YES BOUNCE not bounce GA4 · ANY OF THREE session lasted ≥ 10 seconds session had ≥ 2 page_view events session included a key event ANY ONE IS ENOUGH ENGAGED
UA asked one question per session. GA4 asks three and accepts any of them. The new test is more forgiving, which is also why the page-level signal it produces is harder to act on.
Same session, four shapes UA GA4
4 seconds, 1 page view, nothing else Bounce Not engaged
30 seconds, 1 page view, nothing else Bounce Engaged
8 seconds, 2 page views Not bounce Engaged
6 seconds, 1 page view, 1 key event Bounce Engaged
Three of the four sessions look identical to GA4. UA split them into three different buckets. That difference is the whole article.

For page-level CRO work, that shift is the difference between a metric you can act on and a flag for one of many signs of life. The page-by-page question I'm trying to answer hasn't changed (Which parts of my funnel are leaking?). UA's bounce rate handed me that column on day one. GA4's engagement rate gives me a number and asks me to figure out what it means.

The best move would be to run with both. A forgiving engagement signal for stakeholder reports, a strict bounce signal for the optimization backlog. GA4 ships one and quietly buries the other. We're going to get it back.

What I still call bounce

I want the old definition back, and I'm not waiting for Google to ship it. There's no column for it in GA4, but the components are sitting there if you assemble them.

For each URL, count the share of its pageviews that ended a session. That's the operational version of bounce I run in production. Strict UA bounce required exactly one event of any kind in the session, but in GA4's event-rich world that bar is harsh to the point of distortion. The looser version answers the question I actually need. Did the visitor leave from this page? Same spirit, more honest to the data model underneath.

Engagement rate tells you the page wasn't a total miss. Bounce rate, the old kind, tells you which pages are leaking.

For the analysts in the room

Two paths, same calculation. Pick the one that fits your stack.

In GA4 Explorations. Build a segment of users who entered on page X. Build a second segment of users who entered on X and exited on X. Pull both totals, drop them in a spreadsheet, divide. Legacy bounce rate on page X is the second number divided by the first. Cumbersome page by page, you'll feel GA4's sampling on the edges, and it's the right path if your org hasn't connected GA4 to a warehouse. Bonus: you can preserve query parameters in the path if you want them, which the standard GA4 UI fights you on by default. Or you can slice and dice your segments further to see how different cohorts bounce.

In BigQuery. Same logic, scaled. The GA4 events export gives you user, session, and event-level data directly, so the calculation runs as a single query rather than a manual segment build. For every pageview event, rank it within its session by timestamp descending. The pageviews with rank one are the session-enders. Group by URL, divide by total pageviews on that URL, refresh daily. Faster than Explorations and uncapped by sampling. Wire in path normalization and a MERGE upsert into a partitioned table, and you can run it as a daily job that backfills the column GA4 hid from you. Production-grade SQL here if you want a starting point. Join against your GA4 source in Data Studio (née Looker Studio) and you're well on your way.

Worth optimizing in 2026

Engagement rate is fine as a portfolio metric. It doesn't tell you which pages to test. Legacy bounce does. It puts your traffic into pages that earn the next click and pages that don't, and it does it in a single column you can sort against. That's the working KPI for prioritizing a CRO backlog. Engagement rate, by collapsing dwell time, depth, and key events into one verdict, just tells you a page wasn't a total miss.

The argument isn't that GA4's definition is wrong. It's that the old one was sharper, and sharp is what optimization programs need. If I'm picking pages to test, I want the metric that flags the leaks, not the one that tells me which pages held attention for ten seconds. Both can live in the same dashboard. One of them has more diagnostic value than the other.

Get your CRO signal back.

A testing program winning on engagement rate but flat on revenue. Page-level KPIs you can't act on. A backlog you can't prioritize. If any of that sounds familiar, you're talking to the right person.

Let's Talk
Back to Frequently Bayesian