Are dashboards useful?

There’s an interesting post over on Marketing & Graphic Design ROI which raises the point that web analytics dashboards can do more harm than good in some cases, by encouraging users to focus on (and get excited about) metrics that are not necessarily the most important ones that they should be measuring (Joseph cites an example of a user who was excited about PIs and hits(!) going up, but had failed to spot that visits from the target sector were plummeting).

However, although I have my own reservations about dashboards (for which, read on), I think Joseph fingers them slightly unfairly in his post – what he’s actually talking about, and which is a very real problem, is people drawing conclusions (or just drawing comfort) from numbers which aren’t relevant to their business. Dashboards merely exacerbate the problem by making the offending numbers look prettier.

So where do dashboards fit into web analytics? To answer the question, I think it’s important to understand that dashboards fulfil a couple of functions in an analytics interface:

1. They provide very accessible (easy-to-digest) visualizations of key metrics or trends, via devices like dials, traffic lights, pie charts or regular charts;
2. They bring together a number of possibly unconnected measures into one place, making it easier to check a bunch of things in one go;
3. They provide a navigational starting point to help users explore the data further.

Most web analytics vendors focus on nos. 1 and 2 above; creating whizzy (sometimes literally) interface widgets which look good (and certainly have their place in bringing the data to life for users who might not naturally be interested in it) but which can obscure the really interesting stuff, or, worse still, misrepresent what’s really going on by over-simplifying things. Not every aspect of web analytics data can be displayed as a speedometer.

No. 3, on the other hand, is often overlooked, and really holds the most opportunity to make web analytics tools more easy to use. Consider the following usage scenarios:

• A user brings up their dashboard which contains a graphic of conversion activity by geography (i.e. a nice little map). The user is interested in the data for Europe specifically, so they click on that part of the map. A pop-up opens asking them what data they’d like to see for that region; they select what they’re interested in, and that data is displayed.
• A user is looking at a dashboard with two widgets on it; one shows the conversion rate from paid search, the other demographic information (e.g. age) of the users of the site (if you’re thinking that having demographic information about your web users sounds far-fetched, watch this space for what we’re planning to do with the web analytics functionality we’re integrating into adCenter). The user drags the conversion-by-paid-search number over and drops it on the demographic data widget, and a new widget is born which shows conversion data for paid search, broken out by user age.

The first of these scenarios is a relatively simple navigational paradigm which is implemented in some tools, though in a fairly simple way in most cases; and what I’m suggesting here is that the system remembers the segmentation action taken (i.e. “I’m interested in just data for Europe”) and can then apply that filter to other reports requested, which adds a new level of flexibility for users.

The second addresses a very important requirement for the way that dashboards should behave: they must be very easy for users to customize. This is the only way that generic (and often misleading) dashboards can be avoided. In this example, the user should be able to save the dashboard configuration, either over the top of the previous dashboard, or as a new dashboard that they can call up at will.

This allows the user to use dashboards to organize their web analytics data; they can bring together the measures that are relevant to them, and use those visualizations as bookmarks into more detailed data that they may need from time to time. The trick the vendors have to pull off is second-guessing what users may need, so that they have to do the minimum of customization.