Bounce Rate Is Not What Most People Think It Is

A bounce counted hits, not disappointment

Google's own legacy documentation is unambiguous about what the metric measured: bounce rate is single-page sessions divided by all sessions, and a bounce is a session that triggers only a single request to the analytics server. Not a short session. Not an unhappy reader. One request. Everything people believe about bounce rate is an interpretation layered on top of a counter that has no opinion about content quality, and cannot have one, because it never observed anything except whether a second packet arrived.

Two consequences follow immediately, and they point in opposite directions. A page that does its job perfectly — a conversion table, an opening-hours line, a definition, a status page — is read, closed, and recorded as a bounce, because there was nothing else to click. Meanwhile a page nobody read at all is recorded as engaged the instant any second hit reaches the server, whether that hit came from a human decision or from a script running on a timer. The metric cannot tell those two apart, and neither can you from the report.

GA4 threw that definition away

This is the part most advice still gets wrong. Google Analytics 4 does not compute the metric described above. It computes an engagement rate first, and defines a bounce as its complement — in Google's words, the bounce rate is the opposite of the engagement rate, the percentage of sessions that were not engaged. A session counts as engaged if it lasts longer than 10 seconds, or has a key event, or has 2 or more page or screen views. Any one of the three is enough.

Read that list again and notice what happened. The old definition asked a question about network traffic. The new one asks a question about a stopwatch — and the stopwatch is a setting. The engaged-session timer defaults to 10 seconds and is adjustable in the tag configuration, which means the single most quoted number in web analytics is now, in the strictest sense, a matter of taste. Two properties on the same site with different timers will report different bounce rates for identical human behaviour, and neither is wrong.

One more detail changes how you read old advice. In GA4 the headline metric in the standard reports is the engagement rate, not the bounce rate; bounce rate exists but has to be added deliberately as a metric. So when a colleague says the bounce rate went down, ask which product they are looking at, which definition it applies, and whether anything in the tag configuration changed in the same window. Half the time the answer explains the whole movement.

The event trick, worked on a thousand sessions

Take one page and one thousand sessions on it. Three hundred of those visitors clicked through to a second page. Seven hundred saw only this page, and their dwell times split like this: 220 left inside ten seconds, 270 stayed between ten seconds and a minute, 150 stayed between one and three minutes, and 60 stayed longer than three minutes. Under the legacy definition the bounce rate is 700 ÷ 1,000 = 70.0%, and that headline covers a group in which 480 people — more than two thirds of the supposed bouncers — stayed longer than ten seconds.

Now add one line of tracking: an event that fires when a visitor is still there after ten seconds. Under the old rules that event is a second hit, so the 480 sessions stop being bounces. The bounce rate falls to 220 ÷ 1,000 = 22.0%, a relative drop of 68.6%, and not one visitor read a word differently. This is the single reason the metric acquired its reputation for being manipulable: it could be halved with a tag change and a straight face.

Here is the part worth sitting with. Apply GA4's default rule to exactly the same thousand sessions and you get 300 multi-page sessions plus 480 that lasted more than ten seconds, so 780 engaged, an engagement rate of 78.0% and a bounce rate of 22.0%. GA4 reproduces the ten-second event trick by definition — it built the workaround into the metric. Set the timer to sixty seconds instead and only 210 of the single-page sessions qualify, giving 510 engaged, a 51.0% engagement rate and a 49.0% bounce rate. Mark one event on the page as a key event and every session that fires it becomes engaged, taking the bounce rate to zero. Same visitors, same page, four answers.

Zero seconds, and the average it poisons

The same documentation explains the second half of the confusion: single-page sessions have a session duration of 0 seconds, since there are no subsequent hits after the first one that would let the tool calculate the length of the session. Duration is measured as the gap between the first hit and the last one. With one hit, there is no gap. The visitor may have read for four minutes; the record says zero.

Put numbers on it. Assume the multi-page sessions really average 180 seconds, and that the seven hundred single-page sessions really average 66.5 seconds, which is what our dwell histogram gives. The true average across all thousand sessions is 100.5 seconds. The tool reports (700 × 0 + 300 × 180) ÷ 1,000 = 54.0 seconds, understating reality by 46.3%. And if you instead restrict the average to sessions that were not bounces, you get 180 seconds — 3.33 times the reported figure. Three numbers, one dataset, and the middle one is the one that ends up on the dashboard.

This is why the two metrics move together in a way that looks like insight and is actually arithmetic. A page whose bounce rate falls will almost always show its average time on page rise at the same moment, because the sessions that stopped being bounces stopped contributing zeros. Reading that as "the new design holds attention better" is the most common false positive in content analytics.

The bounce that means you did your job

Some pages exist to end a search. A unit conversion, a public holiday date, an error-code explanation, an opening-hours line, a package status. The best possible outcome for those pages is that a visitor arrives, finds the answer in four seconds and leaves satisfied — which is recorded as a bounce with a session duration of zero. Under GA4 it may also be recorded as a non-engaged session, since four seconds is under the ten-second threshold. The measurement system rates a perfect outcome as the worst possible one.

The reverse case is just as real. A page with a confusing layout, an interstitial and an autoplaying video will keep people on screen for twenty seconds while they hunt for the close button, fire three events in the process, and report an excellent engagement rate. Friction and interest produce identical telemetry. If the metric cannot distinguish a satisfied reader from a trapped one, it cannot be the thing you optimise.

What to measure on a content site instead

Start by declaring, per page template, what success looks like. A reference page succeeds when the answer is found; an article succeeds when it is read to the end; a landing page succeeds when a form is submitted. Three different templates, three different measurements, and no single site-wide rate that means anything across all of them. A site-wide bounce rate is an average over pages whose goals contradict each other.

For articles, the honest measures are read depth and return behaviour. Scroll-depth milestones at 25, 50, 75 and 100% of the article body tell you where readers stop, which is actionable in a way no session-level rate is. Returning-visitor share and the proportion of readers who start a second session within a fortnight tell you whether the writing earned trust. Search Console adds the half of the picture analytics cannot see: impressions, click-through rate and average position for the queries that reach the page, all of which live outside your site and cannot be moved by a tag change.

One warning about adding those events. The moment you fire scroll milestones, you have changed the definition of an engaged session on that page, and every bounce or engagement figure from before the change becomes incomparable with every figure after it. Write the date of the tag change into the dashboard, keep the old series as a separate line, and never present a rate that spans the boundary. This is the same discipline the article in this series on campaign tagging argues for: a metric is only comparable across a period in which nothing about its definition moved.

Frequently asked questions

Is bounce rate a Google ranking factor?

Google has never documented it as one, and the mechanics make it implausible: bounce rate is computed inside your analytics product, is undefined for the many sites that use none, and changes value when you edit a tag setting. Google Search Console, the only Google surface that reports on your search performance, does not include a bounce rate metric at all. Treat the claim as folklore and optimise for the things Search Console does show — impressions, click-through rate and position.

Where do I find bounce rate in GA4?

It exists, but it is not the metric the standard reports lead with — the engagement rate is. Bounce rate has to be added deliberately as a metric in an exploration or a customised report, and when you add it, it will always equal 100% minus the engagement rate shown next to it, because that is its definition. If your dashboard shows an engagement rate of 78.0%, you already know the bounce rate is 22.0% and the second number tells you nothing new.

Our bounce rate collapsed overnight. What happened?

Look at the tag configuration before you look at the content. A new automatic event, a marketing script that fires on load, a change to the engaged-session timer, a video embed that reports playback, or an event newly marked as a key event will all move the number without a single visitor changing behaviour. In the example used in this article, adding one ten-second event took the legacy bounce rate from 70.0% to 22.0%. If nothing in the tagging changed, then check traffic mix: a shift of source or device changes the population, not the pages.

Is a high bounce rate always bad?

No, and on reference pages it is the expected shape of success. If a page exists to give one fact — a conversion, a date, a code, a status — the visitor who reads it and leaves has been served perfectly and is recorded as a bounce with zero session duration. The pages where a high rate genuinely signals a problem are the ones with a next step: a category page nobody clicks through, a landing page nobody submits, a checkout step nobody completes. Judge the rate against the job of the template, never against a site average.

What is a good bounce rate?

The question has no cross-site answer, because two properties can report figures decades apart on identical behaviour depending on which product measured them, which timer was set and which events fire. A published benchmark that does not state the tool, the version, the timer and the page type is comparing quantities that are not the same quantity. The comparison that survives is narrow: the same page template, in the same property, with an unchanged tag configuration, before and after a deliberate change.

Should we aim to keep every visitor past ten seconds?

No. Ten seconds is a measurement threshold that happens to be the default in one product, not a property of good content, and treating it as a target is a textbook case of a measure becoming a bad measure once it becomes a target. The behaviours that push a visitor past ten seconds without helping them — slow-loading answers, content hidden behind an accordion, an interstitial — all improve the metric while damaging the page. Optimise for the answer being found, and let the timer report whatever it reports.