In my experience, if your plan is to make a “dashboard”, you’re already on the wrong path. It’s too generic and says nothing about what problems you are there to solve. Think about it yourself: in how many of the products that are important in your life is there any meaningful value produced by a dashboard? Dashboards seem alluring because we imagine that users will sit there and somehow have insights delivered to th…
Ask HN: Lessons learned from implementing user-facing analytics / dashboards?
101–107 of 107 posts
Re: Ask HN: Lessons learned from implementing user-facing analytics / dashboards?
#102The biggest help we got was meeting directly with our customers and asking them “What would it take for you to login everyday to view this dashboard” and they clearly provided metrics and trends they care about but have a hard time getting access to the data. Also don’t get fancy with our visuals. Lots of big metric kpi visuals, tabular visuals, line charts & bar charts. They should be able to glance at the visuals a…
Re: Ask HN: Lessons learned from implementing user-facing analytics / dashboards?
#103For external dashboard not internal: - You can output the most elegant metrics, you will never know if it was the right one until you talk to actual customers. Most of the time, they don't even understand what is presented. - Use libraries, ui-kit made for this, it will save a huge amount of time. - Whatever you do it will: never be enough, wrongly interpreted, used in the wrong context. - Try to tie graph and metric…
Any recommended libraries for making external dashboards?
Re: Ask HN: Lessons learned from implementing user-facing analytics / dashboards?
#104* Design matters a lot - if it looks bad, people won't look at it. * Layout for dashboards is almost completely formulaic. A panel for selected high-level stats (user growth % increase from last year, user % increase from last month, # new users added), a panel for breakdowns (user growth by marketing channel, user growth by registration cohort), a panel at the top for filters ("let's filter the entire dashboard by j…
> * Layout for dashboards is almost completely formulaic. A panel for selected high-level stats (user growth % increase from last year, user % increase from last month, # new users added), a panel for breakdowns (user growth by marketing channel, user growth by registration cohort), a panel at the top for filters ("let's filter the entire dashboard by just this marketing channel, or just this registration cohort") id…
1. Six top-level stats jump out at you: customers, orders, revenue, growth %, current week revenue, previous week revenue. All of these stats are adorned with a few substats (smaller text), almost always a % up/down from last period
2. A few large panels with breakdowns: revenue over time, revenue vs projections, revenue by referral source, revenue by location
3. The top right has your filter buttons, and generally it includes every breakdown dimension on the page. For example, "let's look at this dashboard by just the Google referral source" or "let's look at our stats from the U.S. geography only" or "let's filter this for last 2 years only"
4. Drill-down is "top selling products." This isn't truly a drill-down, as it is still an aggregation, so you really want to drill-down to the record-level. If you filter the dashboard for "U.S. sales by the Google referral source for the last 2 years only", people invariably want to see what the actual row-by-row sales were, and that is the drill-down. They can easily export this and reconcile to source systems. As an example, for some of the work I do, sales reps don't just want aggregations about their sales leads, they want the actual names of actual sales leads (as rows) so they can contact them.
So again, four major parts to a dashboard, which really drive from two simpler (likely familiar to most data analysts): metrics and dimensions.
Re: Ask HN: Lessons learned from implementing user-facing analytics / dashboards?
#105Earlier quoted context omitted.
> * Layout for dashboards is almost completely formulaic. A panel for selected high-level stats (user growth % increase from last year, user % increase from last month, # new users added), a panel for breakdowns (user growth by marketing channel, user growth by registration cohort), a panel at the top for filters ("let's filter the entire dashboard by just this marketing channel, or just this registration cohort") id…
Sure, I could almost choose any one on Google as they all follow the same template - here is one: https://coderthemes.com/hyper/saas/index.html 1. Six top-level stats jump out at you: customers, orders, revenue, growth %, current week revenue, previous week revenue. All of these stats are adorned with a few substats (smaller text), almost always a % up/down from last period 2. A few large panels with breakdowns: reve…
Re: Ask HN: Lessons learned from implementing user-facing analytics / dashboards?
#106Biggest lesson: all metrics _must_ be defined in code, not manager-speak. For instance, if a marketing head wants to plot CAC (cost of acquiring customers) over time, saying CAC is number of customers divided by marketing spend is manager-speak. Spends are budgeted higher early in the month and adjusted with actuals. Customers ask for refunds and cancel accounts. Some campaigns have volume incentives which are known…
And make sure your project plan includes milestones for explicitly aligning all stakeholders on definitions otherwise you'll have a big hot potato game the first time the outputs show something unfavorable.
Re: Ask HN: Lessons learned from implementing user-facing analytics / dashboards?
#107https://jorin.me/gettting-started-building-a-data-driven-bus...
Thought it might be relevant to others here.