Bounce rate is the number most likely to be quoted in a meeting by somebody who would struggle to define it. It is worth defining, because the definition is where all the misreading comes from.

The classic definition, and its flaw

Historically, a bounce was a session with exactly one interaction: the visitor arrived, and nothing else was recorded. Bounce rate was the share of sessions that did that.

The flaw is in the phrase "nothing else was recorded". On a page with no outbound-click tracking, no scroll tracking and no events, there is nothing to record except another page view. So the definition collapses to "a session with one page view", and that is a statement about your instrumentation as much as about your visitor.

This produces the famous absurdity. Somebody searches for your opening hours, lands on your contact page, reads the hours, and leaves satisfied. That is a bounce. Somebody lands on a product page, is confused, clicks around three pages looking for a price, gives up and leaves. That is not a bounce. The first visitor got exactly what they came for; the second did not.

There is a worse version. If your page fires a single event on load -- a cookie-banner impression, say -- the session has two interactions and never counts as a bounce at all. Sites have "fixed" their bounce rate this way by accident and congratulated themselves.

What GA4 changed

GA4 replaced bounce rate with engagement rate, and defined an engaged session as one that lasted longer than ten seconds, or had a conversion event, or had at least two page views. Bounce rate came back later as its exact complement: one minus engagement rate.

The ten-second threshold is configurable, and it is the important part. The definition now includes a duration, which means a satisfied one-page visitor who spent forty seconds reading is no longer counted as a failure. That is a genuine improvement.

It also means a bounce rate from GA4 is not comparable with a bounce rate from anything else, or with a GA4 number from before the change, or with a GA4 number from a property where somebody moved the threshold. If you are tracking the metric over a period that spans a migration, the step change in the chart is the definition, not your site.

The measurement problem underneath

Both definitions share a problem that no definition can fix: the browser does not reliably tell you when somebody leaves.

When a visitor closes a tab, the page may get an unload or pagehide event and the browser may or may not deliver a final request. On mobile, where the browser is frequently killed outright rather than closed, it very often does not. So "time on page" for the final page of a session is unknown, and the tool has to either guess it, treat it as zero, or exclude it.

This is why a single-page session historically had a duration of zero: there was no second page view to subtract the first from. It is also why engagement-based definitions need something firing while the page is open -- a heartbeat, a scroll event, a visibility change -- rather than only on arrival and departure.

If you want to know what your tool actually does here, ask what it records for a session with one page view and no other events. The answer tells you how much of its duration reporting is measurement and how much is convention.

How to read the number

Compare it to itself, not to an industry benchmark. Published benchmarks aggregate wildly different definitions across wildly different sites. A 70% bounce rate is catastrophic for a checkout funnel and completely normal for a blog that answers questions.

Segment by intent before drawing a conclusion. Bounce rate for organic search traffic landing on a reference page tells you something completely different from bounce rate for paid traffic landing on a product page. Averaged together they tell you nothing.

Pair it with something that measures satisfaction. Bounce rate on its own cannot distinguish "read it, got the answer, left" from "wrong page, left". Time on page can. Scroll depth can. A page where most visitors reach the bottom and leave is working; a page where most leave in four seconds having scrolled nothing is not.

That pairing is the whole trick. The reason bounce rate has survived so long despite being so easy to misread is that it is cheap: it needs no instrumentation at all. The moment you add anything that measures engagement directly, bounce rate stops being your best available signal and becomes a summary of one.

What to do instead

For most sites, three questions replace it:

  1. Did they get far enough down the page to have read the thing? Scroll depth.
  2. Did they stay long enough to have read it? Active time on page, measured with a heartbeat that stops when the tab is hidden.
  3. Did they do the thing the page exists for? A goal, however small -- a click on the phone number, a form start, an outbound click to a booking system.

If all three look healthy, a high bounce rate is not a problem. If all three look bad, you did not need the bounce rate to tell you.

Where Skomi sits

Skomi measures time on page and scroll depth directly rather than inferring engagement from navigation, so a one-page visit has a real duration rather than a zero. Attention is measured while the tab is actually visible, which matters more than it sounds: a page left open in a background tab for an hour is not an hour of reading.

The Analytics product page covers the engagement metrics, and Behavior adds the heatmaps and session recordings for when the numbers say a page is failing and you want to see why.

The definition Skomi counts by is written down rather than implied: bounce rate, and the visit it is measured over.