[dead]
Ask HN: Lessons learned from implementing user-facing analytics / dashboards?
91–100 of 107 posts
Re: Ask HN: Lessons learned from implementing user-facing analytics / dashboards?
#92Earlier quoted context omitted.
> He, point blank, said: "sometimes I don't even know what I'm asking for" Totally relate to that AND I'm often on the receiving end of those questions in a live setting (eg. board/exec meetings). Funny to stumble on this because just last week I told someone on our BI team, there is not any one "use case" I can lay out. The use case is this, assume I need to answer any random question that comes up. I need analytica…
That’s a fantastic point. The unstated underlying request isn’t to see the same chart, the same way, every week/month/quarter. It’s actually: “Find any abnormalities in the data that could be threats or opportunities, and show me THAT — in a chart, table, email, or whatever medium make makes sense.”
Yes and to say it another way it’s often “tell me the story of something I don’t already know”
Re: Ask HN: Lessons learned from implementing user-facing analytics / dashboards?
#93Earlier quoted context omitted.
This is the right mindset for sure. Most of the time the initial question is very loosely defined, but actually having these conversations with the people who "want data", and helping them structure their thinking is also a hugely rewarding part of working in data and analytics, and will help you advance in your career. It can be easy to have a cynical view of what people are asking for, but in my experience there is…
Can you recommend a good online Excel modeling course? I see tons of courses that teach “Excel skills”, but can’t find any that teach modeling using Excel.
Wall Street Prep and Marquee Group are the ones most of the banks and financial institutions use, as far as I recall.
Here's a self study package from wall street prep: https://www.wallstreetprep.com/self-study-programs/premium-p...
Get your employer to pay for it :)
Re: Ask HN: Lessons learned from implementing user-facing analytics / dashboards?
#94I spent 5 years leading a data team which produced reports for hundreds of users. In our team’s experience, the most important factor in getting engagement from users is including the right context directly within the report - definitions, caveats, annotations, narrative. This pre-empts a lot of questions about the report, but more importantly builds trust in what the data is showing (vs having a user self-serve, ner…
Ironically one of the major uses of analytics has been to highlight the impact of slow response time on user retention for a wide class of applications.
I also feel that speed builds trust, although I don't know specifically why. Perhaps people envision more errors or error-prone processes when a system is slow. It certainly shows more understanding of the data to present it quickly.
Re: Ask HN: Lessons learned from implementing user-facing analytics / dashboards?
#95Earlier quoted context omitted.
> Finally, I think most dashboards miss one fundamental point. Imagine you're the CEO/COO and you've got this beautiful 3 or 4-chart dashboard in front of you. What should you know about what you're seeing? What's the succinct summary? Having been on both sides of this, I think the challenge is that the CEO/COO's job is to figure out "what should we do about this?," which is the right approach to coming up with that…
> I think the challenge is that the CEO/COO's job is to figure out "what should we do about this? Totally agree. I'd even go a little further and say the business is in trouble if the CEO doesn't know "what we should do about this". It's the CEOs job to know those things, and it's the data team's job to provide the tools to make those decisions easier, faster and better.
People frequently overestimate the role of data in decision-making. Metrics, numbers and other quantitative information don't tell the full story. For a CEO to make decisions, the full picture must include qualitative information - risks, opportunities, market events, competitor's actions, etc. Metrics are just part of the full picture. Far less significant than many BI developers and "data teams" tend to think.
Re: Ask HN: Lessons learned from implementing user-facing analytics / dashboards?
#96Earlier quoted context omitted.
PowerBI is a WHOLE other can of fish - I haven't spent long enough with it to figure out how you build a test suite around that - but it sounds tricky!!
I would like to use the Men In Blake eraser pen on my PBI experience. Can’t stand it!
You have my condolences :)
Re: Ask HN: Lessons learned from implementing user-facing analytics / dashboards?
#97Every time I see these self serve systems implemented I do wonder if they are too complicated for the normal user to figure out. I do think that users can get useful insights from their company data, but the tools are just too hard to figure out. Qlik comes to mind!
Re: Ask HN: Lessons learned from implementing user-facing analytics / dashboards?
#98Earlier quoted context omitted.
Similarly titled towards finance. I specialize in what I'll call decision analytics for insurance underwriters. > Which means, the don’t even understand how un-intelligent their BI tool is or why the execs likely aren’t feeling like investing in BI has been worthwhile And this relates to what I was thinking about in my first comment. I once was conversing the COO of my company (my last job), at a 1000+ person company…
> He, point blank, said: "sometimes I don't even know what I'm asking for" Totally relate to that AND I'm often on the receiving end of those questions in a live setting (eg. board/exec meetings). Funny to stumble on this because just last week I told someone on our BI team, there is not any one "use case" I can lay out. The use case is this, assume I need to answer any random question that comes up. I need analytica…
Oh thank you guys! I came to this post with the thinking of "dashboards are hard to build and when they exist it's hard to extend them".
My boss is asking me from time to time to add yet another dashboard to grafana and all I can do is add another piece of specific inner working values because lack of traces - the "what" part.
Up until now if was as if a car driver is asking for the average air volume intake yet in really he probably needs the "why" the air volume changes.
The "probably" part is important here: if the driver is the test-driver then he needs the actual value, the what; is the driver the track performance guy he needs the why; and sometimes they need booth values because they feel more secure with more information.
You guys just opened my eyes, thank you!
Re: Ask HN: Lessons learned from implementing user-facing analytics / dashboards?
#99From my experience:
1. You want to build UI to be config driven. At some point, adding a new chart in code will not scale. Writing good config is hard and require a lot of careful thinking.
2. Product owners want special snowflake, try to push back on any customization as it increase complexity and make config harder. It is better to implement usable search, navigation, sitemap or focus on developer experience (CI/CD, feature flags etc.)
3. GraphQL is overrated, for complex charts with filters and multiple options it makes caching hard to use in practice. I would like to try tRPC next time or similar rpc based approach.
4. Performance impact of large bundles in minimal in practice. You can be shipping 20MB of JS to users, but inefficient re-renders/re-fetches will have way more impact that amount of code. For charting, I would try ECharts or any commercial WebGL based charting library. For tables, I would try something that mimic excel as closely as possible.
5. Centralize state of application via redux/signals/jotai. You want to have clear separation between config and state of components. You want to build this as early as possible. I guarantee that product would want to have URL sharing and adding this later is very difficult.
6. Designers love whitespace, You should fight for information density as much as possible. Design system sounds like a great idea, but it cost millions in practice.
Re: Ask HN: Lessons learned from implementing user-facing analytics / dashboards?
#100I had a read through some of the comments here and it seems to me that the predominant stance is that reports are only useful for understanding the what and the why is addressed through more focused, thorough analysis. Also, most comments mention self-serve analytics are silly because stakeholders often don't know what they're looking for or they rather have a summary.
I understand this, but I disagree with some of this or have trouble understanding how this can be applied in practice:
- Reports can absolutely be built in a way that is flexible enough to enable knowledge discovery. If instead of creating a chart that plots Conversion Rate over time, instead create a chart that plots a Primary Metric against a Primary Dimension and use parameters to allow users to choose what the Primary Metric and Primary Dimension are. This drastically reduces the maintenance costs of reports because you don't need to create more charts, rather you just need to make new data available.
- This design strategy can be expanded to Secondary Metrics, Secondary Segments and Splits to enable comparison between segments. This is a big step towards finding out the why
- If you're a big business with both a team of BI developers and a team of Data Analysts I can imagine you'll have plenty of resources to conduct more thorough analysis whenever they are needed. But if you're a startup, you probably have a few Analytics Engineers doing both BI development and analysis. How do you enable them to do both if stakeholders most often don't know what they need? You have to be efficient and I don't think that means having these few Analytics Engineers holding stakeholders hands through a series of discussions to figure out what the hell do they even need...
- Why would you not want everyone in the business to be able to discover new things in the data? Why only allow data analysts to do that? If you provide a platform that enables data exploration in a guided way to avoid wrong use/interpretation of data, isn't it best to open it up to everyone? More people looking into data = more hypotheses = higher probability that at least one of them will be proven and very impactful.
- I think there are different types of data work: setting up data architecture to collect and transform data into a format that enables easy analysis; building solutions for monitoring KPIs (the what); building solutions for understanding the drivers of KPI fluctuations (the why); advanced analytics to support decision making (the actions). My opinion is that the real value is in the last point. Whatever we can do to serve the other needs with minimal effort, we should do