Bounce rate in the current analytics product is defined as the opposite of engagement rate. That is the vendor’s own wording, and it has a consequence people rarely draw: the metric contains no information the engagement rate does not already contain. It is one number displayed twice.
Worse, it shares its name with a legacy metric that measured something else entirely, so every comparison anyone has made across the migration is a comparison between two different instruments.
This page sets out both definitions, shows how the same visit gets classified in opposite ways, and explains why a landing page was always the wrong place to use this metric.
The current definition, in the vendor’s words
Two sentences do all the work, and the second one is the important one.
Bounce rate. The vendor states that bounce rate is the opposite of engagement rate, and is the percentage of sessions that were not engaged.
Engaged session. A session meeting any of the following criteria: it lasts longer than 10 seconds, it has a key event, or it has 2 or more screen or page views.
Note the word “any”. These are alternatives, not requirements. One is enough. A visitor who stays eleven seconds and does nothing else has produced an engaged session.
The vendor’s own example of a non-engaged session. A user visits the site, reads content for less than ten seconds, then leaves, having triggered no events and visited no other pages. Because none of the criteria are met, the session does not count as engaged.
What that makes bounce rate. A pure derivative. If you know the engagement rate, you know the bounce rate, exactly, with no additional information. Reporting both is reporting the same measurement twice with one of them inverted.
The legacy definition measured something else
The vendor still hosts the old page, explicitly labelled as legacy, which makes the comparison easy to check.
The old definition. A bounce was a single-page session, calculated specifically as a session that triggers only a single request to the analytics server. Bounce rate was single-page sessions divided by all sessions.
The clause that decides everything. The legacy page states that these single-page sessions have a session duration of zero seconds, because there are no subsequent hits after the first one from which the length of the session could be calculated.
What that means. Elapsed time never entered the legacy calculation. It could not: the product had no way to observe it without a second hit. A visitor who spent ten minutes reading a single page and left was recorded as a bounce, with a duration of zero.
So the two metrics are not versions of each other. One counted requests. The other counts a threshold on time, or an event, or a second page view. They answer different questions and happen to share a label.
The practical consequence. Any chart showing bounce rate across the migration date has a discontinuity in it that is a definitional artefact, not a change in behaviour. If your bounce rate improved dramatically at migration, nothing improved.
The threshold that decides half your engagement figure is adjustable, and almost nobody has looked at it.
Where it lives. Admin, then Data Streams, then your web data stream, then Configure tag settings, then Show all, then Adjust session timeout. The panel there offers a timer for engaged sessions, described by the vendor as the number of seconds it takes for a session to be considered engaged.
The default. Ten seconds.
The separate session timeout. By default a session ends after 30 minutes of user inactivity, and the vendor states there is no limit to how long a session can last.
Why the timer matters more than it looks. Every page on your site is being judged against a threshold somebody at the vendor picked, not one you chose for your content. Ten seconds is generous for a pricing page and meaningless for a long article.
What changing it does to your history. It changes the metric going forward and not backward, so a change creates its own discontinuity. If you adjust it, write down the date, because in six months nobody will remember why the line moved.
The honest recommendation. Leave it alone unless you have a specific reason, and stop treating the resulting number as a property of your visitors. It is a property of a setting.
Why this metric was always wrong for a landing page
The migration made the metric different. It did not make it appropriate, and on a landing page it never was.
What a landing page is for. A visitor arrives from an ad, reads one page, and either takes the action or does not. A single-page session is not a failure mode. It is the design.
What bounce rate does to that. Under the legacy definition, a visitor who read the whole page carefully and decided not to convert was indistinguishable from one who left instantly. Both were bounces, both recorded at zero seconds.
What the current definition does to it. It now counts as engaged anyone who lingered eleven seconds, which includes people who were reading the headline and deciding to leave. You have replaced one crude proxy with another.
The specific trap on a converting page. If your form submission fires a key event, every conversion is automatically an engaged session. Your engagement rate therefore has your conversion rate baked into it, and moving one moves the other for reasons that have nothing to do with engagement.
What actually tells you whether the page works. The conversion rate on the action the page exists for, and the cost per that action. Those are the numbers the page was built to move.
And if you want a diagnostic rather than a scorecard. Scroll depth, and the share of sessions that end with no event at all. Those distinguish “read it and declined” from “never engaged”, which is the distinction bounce rate was always failing to make.
The clearest way to see the problem is to put four visitors side by side and ask what the number does with them.
The careful reader who declines. Arrives, reads the whole page for four minutes, decides the product is not for them, leaves. Engaged, under the current definition. Bounced, under the old one. Neither classification tells you anything useful, because the outcome was a considered no.
The wrong-fit arrival. Arrives from a mistargeted ad, realises within three seconds this is not what they wanted, leaves. Not engaged, correctly. This is the only one of the four where the metric is telling you something real, and what it is telling you is about your targeting, not your page.
The distracted tab. Arrives, gets interrupted, leaves the tab open for two minutes, closes it without reading a word. Engaged, on the duration criterion. The metric records attention that did not happen.
The converter. Arrives, reads for forty seconds, submits the form. Engaged twice over, by duration and by key event independently. Also counted in your conversion rate, so this visitor is inflating two metrics you are about to present as separate evidence.
What the four have in common. In three of the four cases, the engagement classification is either wrong or uninformative. The one case it gets right is diagnosing a targeting problem you would have found faster in the campaign report.
The conclusion that follows. This is not a metric to improve. At best it is a smoke alarm for badly targeted traffic, and you already own better smoke alarms.
Three of the four are misclassified or uninformative. The fourth tells you about targeting, not about the page. Source : Applying the vendor's own criteria (2026)
What the vendor does and does not say about using it
Worth being precise here, because both overclaims circulate.
It does not warn against the metric. I looked. The help documentation presents engagement rate and bounce rate neutrally, describing them as important metrics that let you measure and analyse user engagement.
It does not recommend it either. There is no official guidance saying to optimise for it or to set targets on it.
The claim that it was reintroduced after user demand. This circulates widely in secondary commentary about a mid-2022 reintroduction following its absence at launch. I could not locate an official announcement stating it. Treat it as unverified.
What that leaves you with. A metric the vendor supplies without endorsement, defined as the inverse of another metric it supplies, sharing a name with a discontinued metric that measured something else.
The reasonable posture. Report engagement rate if you find it useful, since it at least has a definition of its own. Reporting its inverse alongside it adds nothing.
Stop reporting bounce rate alongside engagement rate. They are the same number. Pick the one with its own definition, which is engagement rate, and drop the other.
Break every chart that crosses the migration date. Either cut the series at the changeover or label the discontinuity. A trend line through two definitions is not a trend.
Check your engaged-session timer. Look at what it is set to before you interpret a single engagement figure. If someone changed it, that alone can explain a shift you have been trying to attribute to your content.
Take bounce rate off landing page reporting entirely. A single-page session is the outcome those pages are built for. Judge them on the action they exist to produce.
Watch for the conversion circularity. If form submission is a key event, your engagement rate moves whenever your conversion rate moves. Do not then present them as two pieces of evidence.
Add the diagnostics that actually separate cases. Scroll depth, and the share of sessions ending with no event. Those tell you whether people read the page and declined, which is what you actually wanted to know.
Cut the series at the migration date, drop the duplicate metric, and replace it with the two diagnostics that separate real cases. Source : Method, applied to the vendor's definitions (2026)
The vendor defines it as the opposite of engagement rate: the percentage of sessions that were not engaged. It is a derived figure, so it tells you nothing that engagement rate does not already tell you.
What makes a session engaged?
Any one of three conditions: it lasts longer than 10 seconds, it contains a key event, or it contains two or more screen or page views. Meeting any single criterion is enough.
How is that different from the old bounce rate?
Entirely. The legacy product counted a bounce as a single-page session triggering only one request to the server. Elapsed time never entered the calculation, because such sessions were recorded with a duration of zero seconds.
So a ten-minute single-page visit was a bounce before?
Yes, and it is not one now. The same visitor behaviour produces opposite classifications in the two products, which is why comparing bounce rate across the migration is meaningless.
Can I change the ten-second threshold?
Yes. It is a property setting, found under Admin, then Data Streams, then your web stream, then Configure tag settings, then Adjust session timeout, where a timer for engaged sessions can be set.
Does the vendor recommend using bounce rate?
It neither recommends nor warns against it. The help documentation presents engagement rate and bounce rate neutrally, as complementary ways to measure user engagement.
Why is bounce rate wrong for a landing page specifically?
Because a single-page session is the intended outcome. The visitor arrives, reads, converts or does not, and leaves. Penalising a page for producing exactly the visit it was built to produce measures the wrong thing.
What should I use instead on a landing page?
Conversion rate on the action the page exists for, and cost per that action. If you want a diagnostic for pages that fail quietly, look at scroll depth and the share of sessions ending without any event.