In Search of the Dark Bounce

What's in an analytics metric name? A bounce by any other name would smell as sweet. Is a bounce always a bounce? Are there unbounced bounces? What is a bounce, exactly? To answer this, we need to explain how a bounce is measured.

Let’s say that you need a Bosch cordless power drill and you need one now. So you grab the iThing fondle-slab from down the side of the sofa and type ‘bosch cordless power drill’ into Google. Nice. Result number two seems to be the one.

Click.

Your browser checks its cache. Does it have a copy of this page in there already? No. It sends off a request for the page. Off the requesting packet goes down a series of glass tubes filled with invisible rainbows [see note 1], clutching the filename required and the address of the server it’s on. It reaches the server, which promptly sends a stream of ones and zeroes back, acknowledging receipt, and gets ready to start sending the file requested.

Now, we think, that from this point onwards, if you decide you’re bored of waiting and either cancel the request, or click off to somewhere else, then that should be measured as a bounce.

But it isn’t.

In fact, a whole bunch of things need to have happened before a visit can even be counted: HTML, CSS and scripts need to be downloaded, the page needs to be rendered and scripts executed – specifically, your analytics tracking script. Any page load that stops before the tracking script fires is never seen by the analytics. A ‘dark bounce’. It becomes an unknown.

Most people (even those whose job it is to analyse web data) don’t even realise that there are an unknown number of visitors who never make it to the bounce. But you know this now. Or, rather, you at least know that you don’t know (Donald Rumsfeld would be proud). In fact, the correlation between bounce rate and page load speed is a correlation for just those patient people who waited for the page load to complete, and then decided that they didn’t much fancy going through that again. Those who were too impatient to wait for that, who ‘dark-bounced’, aren’t part of that story.

So how do we shine a light into this dark corner? If counting people only once they have loaded the page is of no use, where else can we count them? The answer is – count them on the way in – count as they first make the request, not once the request has completed.

1. Web server logs. If you are not using a CDN, you can count sessions begun via the logs your web server maintains of every request it receives. This is decidedly tricky, and will require you to make big assumptions where you have lots of requests coming from a single IP address.
2. Application Performance Monitoring tools such as AppDynamics, dynaTrace or New Relic can be used in much the same way as the webserver logs. With the same IP address trickiness.
3. CDN request logs – just like the server logs, but catch them before they are even sent to the web server. If you are using a CDN switching service (e.g. Cedexis) then this should be straightforward – we’re actually talking with Cedexis at the moment to provide this kind of measurement as standard.

Once you know how many page loads were started, you can deduct the number of pageviews recorded in the analytics. Everything else (pretty much) can be considered a dark bounce.

So. If we improve speed and fewer users abandon pre-bounce, does moving these ‘dark bounces’ into the light make the distribution better? Well, maybe. Maybe it makes it worse as more very slow user experiences get logged, all of a sudden.

My advice would be to watch for the number of sessions in the sub-2-second bucket. Even better, track the increase in growth rate of overall count of un-bounced sessions (and revenue) instead of worrying about how keeping hold of impatient people is skewing your average or distribution. There’s still hope.

Notes

1. All true. The internet really is a series of glass tubes filled with invisible rainbows. If you haven't already read it, may I recommend Tubes by Andrew Blum, despite some grumpy GoodReads reviewers.