All Dashboards Should be Feeds
dashes.com
dashes.com
Level 1) Are you recording metrics?
That's the first basic level of maturity, without recording data you cannot have data from which to support any decisions. Without data you are blind. The assumption here is that you are able to record everything that you need to... recording 3 metrics isn't enough, you need to be able to get to all your data and record it over time.
Level 2) Are you able to visualise your raw data?
This is the basic dashboard. Whether you build something pretty or use an existing software package it's just the ability to see the data that you are collecting. This relies on people to figure out the inter-connectedness of data and to make inferences from it. Basic graphs and trend analysis fit in here.
Level 3) Are you able to visualise insights in your data?
This is about changing your dashboard or reports such that you can start to consider metrics that are abstractions from the raw data but important to you. Think of cohort charts, revenue relationships to user behaviour, UX funnels, engagement charts, etc.
Level 4) Are you able to record exceptions in your reporting?
As in, can you create thresholds against a metric such that if the metric goes above or below the threshold an event is triggered to record it. Exception tracking coupled with the insights in level 3 should give you the ability to do things like release a new feature and see the resulting effect on certain metrics and be alerted when those effects are outside of some normal range.
Level 5) Are you able to visualise your exceptional events?
And here we are at the newsfeed of data, the events which stand-out are highlighted and all of the other noise drops away. This is great for producing a list of things you might want to know or react to... but you can't get here without going through (and still having) levels 1-4 and it's important to understand that different people in your organisation still need all those prior levels (try telling your sysadmin that he can't have log files or munin and that instead he's got a news feed).
Otherwise at day X+60 you'll end up wondering what went wrong since day X (when your traffic peaked) and blame a new release on X-1 whereas on day X you had just hit the HN/RWW/BBC homepage.
I didn't really want to get into any detail on how to make a specific chart, or capture a specific event... just a general scale of maturity whereby you can't generally do the higher levels without having the earlier levels in place and done reasonably well.
Charts and gauges display "raw data". The downside of this approach is that a human has to process that data to turn it into useful information. The upside is that humans are _very_ good at this.
The feed displays higher level information extracted from the raw data. On the upside, you don't have to have someone sitting around watching it. The downsides are that it requires a higher up-front investment to program or train the system to extract this information, and the system will never (given current technology) be as good as a human for any substantial correlation.
The correct balance depends on your situation (resources, uptime requirements, implementation details of your system), but dashboards displaying raw or summary data that enable you to see unusual patterns, monitoring (which is very similar to a "feed"), and comprehensive stats gathering (which you won't look at on a day to day basis, but is tremendously powerful when diagnosing issues) are all tools that any team should be looking at using.
Chartbeat's UI tries to provide context. The dial shows the concurrents number in the context of your 30-day performance, the chart overlays your current performance on top of the same day last week, and the traffic sources show typical values, for example.
That being said, we are adding more feed-type features. For example, we already offer traffic spike detection on a page level in the higher-priced Publishing product. The reason many of these features aren't present in regular Chartbeat is that they require data scientists to create a model, developers to build a system around it, and servers to actually run the calculations. None of this is free. :)
All Dashboards should show goals you set or something that's unusual compared to your past data. THAT is the reason why everyone's confused by most dashboards - they're visualization for the sake of looking good first. When they're done right they let you see the state of things, whereas feeds are like alarms - too many or too few can make you stop giving a damn.
Be like a scientist - ask every question you can think of. Then try to answer it with data and if that answer changes over time, keep it on a dashboard. Then set alerts and snapshots to the feed, so only what's really important will bother you.
What we need to work on is how deep you can ask questions of an external service. Giving me my choice of 12 pre-baked table columns or API endpoints isn't going to answer my real goals. 12 pre-designed draggable widgets aren't either. I want to ask big questions first instead of combining little answers.
Yeah, this is definitely true. But it correctly puts the burden on the developer instead of the user. What's more, generally it makes for a more forgiving environment by which the user can interpret the data. If you say "you had a huge ecommerce day!" and it's Black Friday, the user interpreting it will be able to put that together, even if the app (initially) can't.
Part of my bias here is that this is based on our experiences building ThinkUp, which is open source, and thus we're hoping to iterate on exactly these kinds of improvements when community members find the insights to be insufficiently, well, insightful.
They had some clever algorithms that simplified time series data from google analytics so that you could see at what points real changes occurred.
Some screenshots here: http://analytics.blogspot.com.au/2009/08/api-integration-to-...
You can see how it's able to take something noisy like time series data and turn it into a stream of discrete events. It's really quite clever.
Obviously, the real secret to success is to use judgement, but that doesn't make for catchy headlines.
You can partly agree that dashboards should be smart but not every dashboard _needs_ to be so. Creating smart dashboards requires you to actually identify the metrics and the requirements of the end-user.
When you generalize this, you end up having a dashboard that's Google Analytics. It's gigantic and by letting the user decide what labels he wishes to give to the numbers, it's actually way more smarter than the 'feeds.'
That's just my humble opinion but I sure don't feel comfortable about how other dashboards are treated in this piece.
And if someone's interested: http://thisiscsr.com/post/40088895750/dashboards-smartness
I might be projecting, though. I talk regularly with the people behind Pirate Metrics (http://piratemetrics), which does that sort of thing. (Records, displays, but makes suggestions as well.) S, that sort of idea has been on my mind.
This seemed intuitive to me, and it's kind of a combination of ideas I've taken from other stat tracking applications like gaug.es, Mixpanel, and Chartbeat. Each application seemed to be missing one or the other.
If the best interface is no interface, then here "language", a very common and familiar interface, approximates "the best interface".
Show live updates, but allow users to also see older data.
I'm not convinced a feed would allow me to do that.