Five mistakes teams make with bounce rate

The version of this that works is simpler than the version most people imagine. These are the ones we run into repeatedly when we audit bounce rate.

Data you do not trust is worse than no data, because it gets quoted anyway. Write the reasoning down alongside the decision, because the reasoning is what changes first.

Warning signs

• Treating it as a launch task rather than an ongoing one
• Assuming someone else already owns it
• A high bounce rate is not automatically bad
• Context and page type change what it means
• Never checking whether the fix actually worked

Engagement time is usually the better signal. It is worth being explicit about, because assumptions differ quietly. It is the sort of thing that looks like polish right up until it costs you an enquiry.

Turning this into a decision

In practice

Measurement is only useful when someone has agreed in advance what they would do differently. Three things worth confirming about bounce rate before you move on:

• Someone can say what the current setup is without going to look
• A high bounce rate is not automatically bad — and you know whether that is true here
• There is a way to tell whether the last change to this helped

None of this needs a rewrite. Most of it is a morning's work once someone decides to do it.