A dashboard survives if somebody would notice it missing. Almost none would. The usual failure is not bad design, it is that the report answers a question nobody has on a cadence nobody keeps, so opening it is optional and optional loses. The fix is to attach every report to a decision and a moment.
Most companies have between ten and forty saved reports and read two. This is why, and what the two have that the rest do not.
The newsletter
Join our KISS newsletter
One short read a week on what actually moves revenue, in a free email. Read by 10,000+ operators and founders.
No spam. Unsubscribe in one click.
I.Why a dashboard gets built once and never opened again
Four causes, and only one of them is about the dashboard.
A.It answered a question that has already been answered
The single largest category. Somebody asked how mobile signups were trending, an analyst built a view, the question was answered, and the view was saved because saving is the default.
That report had a lifespan of one afternoon and now sits in a list forever, indistinguishable from the ones that matter. The saved-report list is a graveyard of resolved questions, and its length is why nobody browses it.
Answer the question, take the screenshot, put it in the document where the decision lives, and delete the report.
B.Nothing changes depending on the number
Ask of any dashboard: if this figure doubled tomorrow, what would somebody do differently? For most of them the answer is nothing, or the vaguer version of nothing, which is that we would want to know.
Wanting to know is not a decision. It produces a report that is interesting the first week, familiar the second, and invisible by the fourth, because there is no consequence attached to reading it.
C.It has no owner and no cadence
A report that everyone can see is a report nobody checks. Shared ownership of a number means the responsibility for noticing a change belongs to whoever happens to look, which is nobody.
The same applies to timing. A report with no fixed moment competes with everything else on a Tuesday, and loses to whatever is on fire.
4.And it is slow, or it is wrong, once
The smallest cause and the most fatal. A report that takes twelve seconds to load gets opened noticeably less than one that takes two.
Worse is being wrong once. A number somebody could not reconcile, in a meeting, in front of other people, kills a dashboard permanently. It never recovers, because trust in a report is binary and there is no process for restoring it.
Why reports die, and what actually fixes each
Diagnosis view| Cause | Looks like | Fix |
|---|---|---|
| One-off question, saved | Long list, most untouched | Delete it after answering |
| No decision attached | Interesting, never acted on | Attach a decision or drop it |
| No owner | Everyone can see it, nobody checks | One name per report |
| No cadence | Opened when someone remembers | A fixed moment in a fixed meeting |
| Slow | Opened less each week | Narrow the query |
| Wrong once, publicly | Abandoned entirely | Usually unrecoverable |
II.The test a report has to pass to survive
Three sentences before it gets built. If you cannot write them, do not build it.
A.The decision, the person, the moment
Before building anything, write: this report exists so that [person] can decide [decision] at [moment].
“This report exists so the growth lead can decide which channel to cut at the monthly budget review” passes. “This report exists so we can monitor acquisition” does not, and the difference is not pedantry: the second has no trigger for opening it and no consequence for not.
Most proposed dashboards fail this at the second clause. There is a decision in the vicinity but no named person who owns it.
B.Push, do not make people pull
The strongest single change available: stop expecting anyone to visit a dashboard. Send the number to where they already are, on the cadence the decision runs on.
A weekly figure in the channel where the team already talks gets read by everyone. The same figure behind a link gets read by the person who built it. The dashboard still exists, for when somebody wants to dig, but it stops being the delivery mechanism.
Alerting is the same idea with a threshold. Our guide to Slack alerts from analytics covers doing that without training everyone to ignore the channel.
C.Delete aggressively, and keep deleting
Once a quarter, list every saved report by when it was last opened. Anything untouched for three months goes, and almost nothing that goes is missed.
The objection is always that somebody might need it. They might, and rebuilding a report takes ten minutes while a forty-item list nobody browses costs you every report in it.
III.Building the three that get used
Most companies need three recurring reports. The rest is ad hoc, and ad hoc should not be saved.
A.The three
Acquisition, judged on quality. Not volume by channel, which nobody acts on, but what each channel's customers were worth. That is the budget decision, monthly.
Activation. What share of new accounts reach the point where the product has demonstrably worked, and where the ones who do not stop. Owned by product, weekly.
Retention by cohort. Whether the people who arrived three months ago are still here. Slowest to move and the one that decides whether the other two matter. Monthly.
Everything else a business asks is a question, not a report. Ask it, answer it, and do not save it.
B.Same question, same answer, next month
The reason the three survive is that they are comparable over time, and comparability is fragile: someone re-asks in June with a slightly different filter, the numbers disagree, and the meeting becomes about the numbers instead of the decision.
Kissmetrics saves the query rather than the screenshot, so March and June are the same question computed the same way, and a definition change is explicit rather than accidental. Because it captured the events itself, the report is also not reading another tool's summary, which is where most reconciliation arguments start.
None of which makes a report get opened. That is the decision, the owner and the moment, and no product supplies those.
Verdict
Dashboards do not die of bad design. They die because nothing changes depending on what they say, nobody owns noticing, and there is no moment at which anyone is expected to look.
Write the decision, the owner and the moment before you build. Push the number to where people already are rather than expecting a visit. Keep three recurring reports and delete everything untouched for a quarter, because a long list of saved reports is the reason nobody reads the good ones.
Continue Reading
Real-Time Slack Alerts From Analytics: Building a Signal-Based Workflow
Dashboards wait for you to check them. Slack alerts come to you. Building a signal-based alert workflow ensures your team sees critical analytics events the moment they happen.
Read articleHow to Turn Raw Data Into Business Decisions (Without Drowning in Dashboards)
Having data is not the same as making decisions. Most teams drown in dashboards while struggling to translate numbers into action. This guide gives you a framework to close the gap.
Read articleHow to Pick the Right KPIs: Start with Your Business, Not Your Dashboard
Most teams track 50 KPIs and act on zero. The problem is not too few dashboards. The problem is too many metrics. Limit yourself to 10 and you will make better decisions.
Read article