The standard definition of a bounce is a visitor who only viewed one page on your web site. Your web site’s bounce “rate” is the percentage of visitors who “bounced”. This metric is supposed to give you a very generic estimate of your visitors’ engagement level. If you have a high bounce rate, then your site is apparently very unengaging.
But are single-pageview visits really the best way to define engagement? In the age of blogs and social media, we don’t think so.
Our new release added pinging support to our tracking code. This means that as a visitor to your site stays on a single page, they are still talking to our tracking servers, so we know they are still on your web site. This lets us determine how long a visitor is actually on your web site, even if they only have one pageview.
There is a significant difference between a visitor with one pageview who spends less than 30 seconds on your site, and a visitor with one pageview who spends 5 minutes on your site. But no other analytics service will tell you about this difference – no matter how long any single-pageview visitors are on your site, they are all considered bounces. We think this is horribly broken and misleading, so we decided to redefine what a bounce is.
How Clicky determines a bounce
A visitor who has only one pageview, and who is on your site for less than 30 seconds is what we now consider a bounce. So any visitor who has more than one pageview, or any visitor who has only one pageview but is on your site for at least 30 seconds, is now what we consider “engaged” / not a bounce.
Say you have a blog post that you have shared on a few social media networks like Facebook and Reddit, and you get 1000 visitors to it. Chances are that 95% of these visitors will only view the article that is being linked to – one pageview. Maybe half will read the whole article, half will read part of it, and a few will click through to your front page to see more. Any other analytics service would report a 95% bounce rate for these visitors. But a bounce is negative, so it makes it sound like only 5% of these visitors were engaged. But that’s not true at all – half of them read the entire stinking article!
Since Clicky now sends pings, we can measure how long each visitor is actually online. For the example above, Clicky would report a bounce rate closer to 50% for these visitors. This is a much more accurate representation of how many of these visitors actually “bounced” from your site, versus how many actually stayed online long enough to read what you had to say. Because of this, we think we now have the best bounce rate metric in the industry.
Arguments against this change
We’ve had some feedback that this new measurement is no good either, because there are lots of people who used tabbed browsing and open a bunch of tabs in the background, then go and read them later. This is true, but this is also more of a “power user” tactic. As long as less than 50% of users are doing this (and we think it’s probably more like 10%), then our bounce rate is a much more accurate representation of engagement.
Some people also suggested we make this a different metric altogether, such as “engagement rate”. We considered this, but ultimately we decided that the term “bounce rate” is just defined incorrectly in the first place. This shouldn’t be a new metric – this is the way bounces should be defined, period. This is why it’s called “analytics” – your traffic data is “analyzed” to help you make sense of it. Reporting that 90% of your visitors only had one pageview doesn’t really tell you anything, but reporting that 50% of your visitors had one pageview and were online less than 30 seconds does tell you a lot about your web site’s traffic.
This doesn’t mean we don’t want to make it better though. We will probably add something that detects whether or not the page being viewed is “in focus” or not, and only do the pinging if it is actually being read. This will require a lot of testing, however. For example, a visitor opens a link to your site in the background, but doesn’t actually read it until an hour later. If we don’t ping until the page comes to the foreground, their session will have already expired so the pings won’t register when they are processed on our end. Should we delay the page view log until the page comes to the foreground? That might work, but what if they move the window/tab to the background again and then come back to it another hour later? As you can see, it gets a bit complicated, so we’re not going to change it until we have taken the time to determine the absolute best way to do it, and test the heck out of it.
We’d still like to hear your feedback on this change of course, and what you think would make it better. So have at it in the comments.
