One analytics site to rule them all

All tomorrow’s data

I love website usage data. Can’t get enough of it. I love it so much that last August I asked every council in the country to send me some.

And they did (well nearly all of them did). And I poured it all into a big beautiful spreadsheet and put it on the web. The usage of local government websites in Great Britain.

Which was nice.

Unfortunately my love for website usage data is such that it was not enough. I want to know more. What are the annual trends and the seasonal trends. Do areas with significant tourism industries get more interest in the summer (or the winter)? What areas of websites are getting the most traffic?

More FOIA, more hassle

Now I could just ask for this data. That worked tolerably well last time but it’s a pretty unsatisfactory idea. Each FOIA request generates work in each council and when the data comes in, it creates work for me. And, though I love website usage data, that is work time that might be better spent doing things for paying clients so that I can afford to feed my dog.

And also, you know, it’s the 21st century: machines are supposed to do this sort of thing. Some (surprisingly few) councils already publish their website usage data. Getting more of them to do so would be a start but unless we can get the data marked-up against an agreed standard is still going to take a human being a distressingly long time to collate.

The Americans will solve it

In the USA there is a project that could provide a nice model. Its called the Data Analytics Programme.

Participating departments and agencies insert an additional tracking script in their webpages. This sends packets of data back to the project server, and this is then available to anyone who shares my website stats interests.

We could do that here couldn’t we? It would be easy for councils to implement and should ensure that people like me cease to trouble them with FOIA requests in this area. And it will provide really rich benchmarking and research data. If we included mobile app use tracking that would provide really useful evidence in the “I want an app” “No-one will use your app” arguments.

It wouldn’t be entirely free. We’d need some server capacity and some support to maintain the analytics tool. But it would be very low cost.

What’s not to love?

This is not the only way

I know what you’re thinking (no, not that). You’re thinking: couldn’t we just use Google Analytics for this? And the answer is yes, partially.

In principle we could set up a new Google Analytics property for “All council websites” and harvest that data but the combined traffic would significantly exceed the maximum allowed in the Google Analytics free tool.

All but one council already uses an analytics tool so, as an alternative, we could automate the collection of data from their existing tools. Overwhelmingly they use Google Analytics which has a beautiful API so that is certainly feasible. Feasible but practically complex. That means each council will have to manage user credentials and those will also have to be managed by the central datastore. If the council switches analytics tool that will create an additional (and little used so easily forgotten) admin load.

Good idea / bad idea

Who’s with me?

What would be the best tool?

Why is this not the best idea you’ll hear about all day?


Does bounce rate matter?

Invasion of the SpaceHoppers

space hopper invasion by Paul Stevenson used under CC BY 2.0

An interest in bounce rate can severely damage your health.

It’s true.

I recently started to muse about what a “normal” bounce rate might be for local government websites and this led me to spend a surprising amount of time gathering data from (almost) every council in the country.

Now I’m safely out of the other side of that I can muse a bit more about what it all tells us.

Nerdy explanation of bounce rate

In principle this is very straightforward. If I visit a page on your website and then don’t visit any other pages for a while then I “bounced” on that page. If half of the visits to your website were “bounces” then the bounce rate is 50%.

In reality it is slightly more complex than that. If you use Google Analytics to record this data (and 86% of local authorities do) then a bounce occurs if a user triggers only one event. A pageview is an event but Google Analytics can be configured to measure other events: such as playing a video. So if you set up Analytics to measure plays of videos, your bounce rate will go down even if people don’t visit any other pages.

And if people visit a second page but Google Analytics is not set up on the second page (which happens reasonably often in local government when people are passed to back office services (though only if the back office services are poorly configured or a bit pants (which is not-uncommon))) then Google Analytics will record a bounce even though the user is definitely not bouncing.

And finally there is the cross-domain issue. As people move between domains on your web estate (strictly speaking GA properties but it’s easier to think about it as domains). Imagine you have a main site and then your comms team think it’s a jolly wheeze to set up a microsite to promote the council’s vision for the area: When someone visits a news page on the main site and follows a link to the second site Google Analytics will record the first visit as a bounce. This can be fixed using cross-domain tracking though there are some situations when you might not find that helpful.

Time is also a factor in bounce rate. If I visit a page now and then come back in 15 minutes and visit a second page should we record that as one visit involving two pages (and so no bounces) or two visits each involving one page (two bounces)? Google Analytics by default assumes that there must be a gap of at least 30 minutes and so would plump for the one visit option. If the second page is visited 31 minutes after the first one that would make it two visits.  

What bounce rate is best?

It’s definitely not possible to say “local government websites should have a bounce rate of X%”. The correct bounce rate, ultimately, is the one that shows the website is being used as it was designed.

Many public sector sites are designed to work well with search engines (in the UK, let’s face it that’s basically Google) and to resolve the user’s question immediately. So if I type “Christmas holidays Barnet” into my favourite search bar I get a link to the Barnet School Term and holiday dates page. This gives me the answer I was looking for and so I go about my business. I just bounced on Barnet’s site (they can thank me later).

So if we’ve designed the site to work this way and it is working as designed, we would expect high bounce rates. If we believe that people are more likely to visit the front page of the website and then navigate to the answer and the site is working as designed then we would expect lower bounce rates.

Of course the local government digital estate is about more than delivering small packets of information. It’s about (or should be about) much more complex interactions, looking for support with housing, working out what support at home would be best for mum, understanding what options my visually impaired daughter has to get the best out of her further education.

These interactions are likely to be very different, longer, more interactive, perhaps paused halfway through for a bit of consideration and discussion. So if you’ve designed the site for these sorts of interactions and the site is working as designed bounce rate would be lower. The degree to which this affects the overall bounce rate will depend on the mix of the straightforward and the complex interactions. And the way you expect users to interact with your site.

So is it useful to monitor bounce rate for your site?

Yes and no.

Some eloquent explanations of why it is not useful to look at bounce rate were posted as comments on my blog a couple of months ago.

While I don’t disagree with the points made there but I do have a different take on the situation.

Consider the rev-counter on your car. It displays a single figure indicating the number of revolutions per minute your engine is making). When you depress the throttle the rate goes up and the indicator shows this change.

But the situation under the hood is much more complex: valves are opening and closing, fuel is being sprayed, exhaust gasses are leaving the cylinders and being exhausted.

RPM is a result of all of this activity, it’s not a measure of all of it but it is affected by changes in the whole system.

I think bounce rate is a bit like this. Overall bounce rate is a result of the design decisions you make for your site and how users actually use it. A web manager should have a good idea of what bounce rate they expect across their site(s). So if the rate they actually see is radically different that means something odd is going on. And if the rate changes suddenly that’s another indicator something needs investigation (or conversely if the rate doesn’t change when they expected it to).

What bounce rate should I expect?

The simple answer, without knowing anything much about your site, is between 40% and 51% because 50% of all local government sites are within that range.

Which doesn’t mean that if you have a bounce rate of 60% you are doing something wrong. It means that your site has an unusual bounce rate. If that’s what you expect then that’s great news (isn’t it?).

On the whole English district councils and London Boroughs tend to be a bit less bouncy than other councils. The explanation for this could be as simple as not having public transport responsibilities which we might expect to drive lots of “when’s the next bus” type traffic.

People visiting council sites from internal addresses tend to be much less bouncy than visitors overall. So if you have a site targeted at school professionals, for example, you would expect much lower bounces.

And the design decisions you take will also play a key role. Are you handing people to third-party sites for example?

Cross domain tracking rocks

One thing that struck me when I was asking councils for data on their website visits was the number of councils tracking each domain (or microsite) separately. If you treat your digital newsroom as a distinct analytics property to your main site, both will look artificially bouncy. If you use cross-domain tracking you’ll get a much more realistic sense of what is happening to traffic between those sites.

A tool, not a grade

To me using website analytics data is all about understanding what your site is designed for, how it is being used and then tweaking and improving the design to meet the needs of your users. A single figure (like bounce rate) can never give you the full detail of what’s going on under the hood but it can tell you whether things seem to be working as they should or need closer investigation.