Bounce rate: the questions we get asked most

It comes up on almost every project, usually later than it should. The questions about bounce rate that come up most often on our calls.

Measurement is only useful when someone has agreed in advance what they would do differently. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.

Do we need to care about this?

A high bounce rate is not automatically bad. There is a version of this that is over-engineered, and it is worth avoiding. Assume whoever inherits this will have half your context and none of your patience.

Can it wait until after launch?

Occasionally. More often the post-launch version costs several times the pre-launch one. The cost of getting this wrong is rarely visible on the day it happens.

How do we know it is working?

Engagement time is usually the better signal. It is worth being explicit about, because assumptions differ quietly. Doing this properly once is usually cheaper than doing it approximately three times.

The short version

More dashboards rarely produce more decisions. Three things worth confirming about bounce rate before you move on:

• Someone can say what the current setup is without going to look
• Context and page type change what it means — and you know whether that is true here
• There is a way to tell whether the last change to this helped

Most of the value here comes from doing the first two things, not all of them.