Choosing the Right BI Tool for Your Use Case
In a previous article, I shared my personal ranking of various BI tools based on my preferences and experiences. However, I also mentioned that the best BI tool for you might not be the one that ranked highest on my list. The reality is, the right BI tool for your organization depends heavily on your specific use case and requirements. In this follow-up post, I want to dive deeper into the key questions you should ask and the factors you should consider when choosing a BI tool.
Who will use the BI Tool?
The first and most important question to ask is: Who will be using the BI tool (as a builder but also a consumer)? The answer to this question will significantly narrow down your options and help you make a more informed decision.
Personal Use by Analysts
If the BI tool is primarily for personal use by an analyst who wants to explore data and share insights via screenshots or PowerPoint slides, then you have a wide range of options to choose from. Tools like the free Tableau Public or local Power BI Desktop can do the job here, too.
In this scenario, the focus is on individual exploration and basic sharing. The analyst is the primary user, and the tool should cater to their needs and preferences. As I mentioned in my previous article, tools like Tableau might not rank high on my personal list, but when it’s about exploring and visualizing data, it is one of the best options out there.
Also, Notebook-oriented solutions like Hex and Deepnote or a Canvas-style Count can be great choices. These tools allow analysts to build whatever they want and create a compelling storyline and narrative around the data. When it’s about bespoke analyses, I would give them a shot over generic BI tools.
Interactive Dashboards for Company Use
When you need to build interactive dashboards that will be consumed by others within the company, the requirements change significantly. In this case, you might need a tool that supports interactive features like filters, drop-down menus, and modified date ranges. The number of users and their roles (dashboard builders vs. viewers) become important factors to consider.
For example, you might have a small team of analysts or analytics engineers who build and maintain the dashboards, while the rest of the company simply interacts with them. In this scenario, the “building” process can come with a learning curve in favor of a good “developer experience” and robustness, as not a lot of people will actually build.
Business Analysts Creating Their Own Charts
If business analysts or users are expected to build their own charts and dashboards, ease of use becomes crucial. The tool may offer spreadsheet-like features and be user-friendly for non-technical users (Sigma or Omni). Tools like ThoughtSpot, which cater to business users and offer a more intuitive, search-driven interface, might be a good fit, too.
Metabase’s “Question”-based approach might lead to dashboard sprawl and definition conflicts if you e.g. do not use a rigid Semantic Layer.
In this scenario, the focus is on empowering business users to answer their own business questions and make data-driven decisions. The tool should be accessible and easy to use, with a gentle learning curve and minimal technical requirements.
Customer-Facing Dashboards
For customer-facing dashboards embedded in mobile or web apps, styling and customization are key. You want the dashboards to blend seamlessly with the rest of your application and provide a cohesive, branded experience.
If your front-end framework is React (chances are high), a React SDK for styling might be preferable to avoid the look of a standard embedded dashboard (e.g., a plain Dashboard embedded via iframe).
React SDK’s are supported by a majority of providers (natively or by community-built tools). Also, some tools (1,2) allow you to style your dashboards with CSS. It might sound clunky for the usual Analyst, but exactly what a UX Designer would crave. Don’t forget about other unique requirements and constraints of mobile and web applications.
Deploying multiple tenants (e.g. one instance per client) through an API might be a valid approach. Therefore, definitions as code become a thing to look out for.
Budget Considerations
Once you have a clear idea of who will be using the BI tool and what their requirements are, the next question to ask is: What is your budget? The answer to this question will help you narrow down your options further and ensure that you're considering tools that are within your price range.
Free vs. Paid Tools
There is a wide range of free and paid BI tools available, each with its own strengths and weaknesses. Free tools like Tableau Public or Google Data Studio can be great choices for personal use or small-scale projects, but they might not offer the advanced features and capabilities required for larger, more complex deployments.
You can also self-host Open-Source tools and just pay a few bucks for the hosting. Do not forget that you usually trade time vs money, but that’s sometimes needed. For lightweight setups with moderate traffic, the “Total Cost of Ownership” still remains low, but it obviously is more effort and requires more know-how than a cloud-based plug-and-play solution.
Scalability and Cost Implications
When evaluating the cost of a BI tool, it's important to consider not just the upfront costs but also the long-term costs, considering company development. Some tools have different price tiers based on capabilities (e.g., edit access vs. view-only access), and the costs can quickly escalate as you add more users and features.
For example, if you plan to democratize data access within your organization and provide edit access to a large number of users, this can significantly impact your monthly bill. In this scenario, you might want to consider tools that offer fixed pricing or more flexible, scalable pricing models.
Power BI shines with its comparatively affordable (and presumably heavily subsidized) $14/month seat-based pricing. However, if you reach a certain scale, let’s say your data models exceed 10 GB, you might need to upgrade and double your license cost ($24/month), or need to deal with, in my opinion, somewhat non-trivial Azure Fabric Capacities.
Fixed vs. Scalable Pricing Models
Some BI tools offer fixed pricing, which can provide more predictability and stability in your monthly costs. Other tools offer more flexible, scalable pricing models based on seats that can accommodate fluctuations in usage and user counts.
When evaluating pricing models, it's important to consider your expected growth and usage patterns, as well as your budget and financial constraints.
Data Transformations and Integrations
Another important factor to consider when choosing a BI tool is data transformations and integrations. Where are your data transformations happening, and what tools and technologies are you using to manage and process your data?
Compatibility with Data Warehouses
If you're using a data warehouse like BigQuery or Snowflake to store and manage your data, you'll want to choose a BI tool that integrates well with your specific technology. For example, if you're using BigQuery and want a rather basic setup, Looker Studio might be a great fit, as it's designed to work seamlessly with Google's data warehouse. However, if you're using Snowflake, Looker Studio might not be the best choice, and you might want to consider other options.
Integration with Tools like dbt
If you're using tools like dbt to manage and transform your data, you'll want to choose a BI tool that integrates well with your existing workflows and processes. For example, if you're using dbt to define and manage your data models, you might want to look for a BI tool that offers dbt integrations and allows you to leverage your existing models and definitions.
You may even have database access and just work on .CSV-Exports. Then the transformation capabilities of Power BI might be exactly what you need.
Even though I would always urge for “headless” BI.
Also, a tool like Qlik, I didn’t even mention the last time (because it doesn’t fit into the dbt-centric workflows I prefer) might be a good solution if, e.g., your Organization won’t allow you to apply data transformations in the Data Warehouse. In my opinion, the modern way of doing BI should not rely on heavy transformations within the BI tool and local engines, but rather on a solid foundation in your Cloud Data Warehouse, but I am aware that some Organisations and Setups see and require this differently.
You want to choose a BI tool that fits seamlessly into your existing ecosystem.
Testing and Prototyping
Another important consideration is testing and prototyping. When evaluating BI tools, you want to be able to test and prototype dashboards and reports without affecting your production environment. As I would always rely on something like dbt for my data transformations, and I don’t want to modify C-Level Dashboards in production anymore, it’s a big requirement for ME.
Does the tool support dedicated production and development environments, git branching, or enable me to build on top of different dbt targets? These features can make your life much easier and allow you to test and iterate on your dashboards and reports more effectively, without breaking anything user-facing.
SQL Query Support
Finally, having SQL query support is a big plus when it comes to debugging and understanding how metrics and filters are applied. With SQL query support, you can easily drill down into the underlying data and understand how the BI tool is generating and calculating the results.
This can be especially useful when you're trying to troubleshoot performance issues or optimize complex queries. With SQL query support, you can see exactly what's happening under the hood and make informed, data-driven decisions about how to improve and optimize your dashboards and reports.
No need for fancy DAX hacks, it’s the same optimization you would use for regular SQL queries in your data pipeline, too.
Governance and Management
Another important factor to consider when choosing a BI tool is governance and management. How will you manage and govern your BI deployment, and what tools and features does the BI tool provide to support these efforts?
Discoverability of Dashboards
One important consideration is the discoverability of dashboards and reports. Can you easily discover and find the dashboards and reports that you need, or do you have to rely on links and bookmarks to navigate your BI deployment?
For example, in Looker Studio, you can't see what others have built unless you have the link. This can make it difficult to discover and find the dashboards and reports that you need, especially as your deployment grows and scales over time.
As an admin, you might want to see all dashboards and reports, their usage, and custom definitions. This can help you understand how your BI deployment is being used and identify opportunities for improvement and optimization.
Admin Capabilities and Permissions
Another important consideration is admin capabilities and permissions.
Look for tools that offer robust admin capabilities, including permissions management and access control. Can you e.g. assign users to groups that manage access to certain assets or use that for Row-Level-Security?
The right approach for you will depend on your specific requirements and constraints, as well as your overall security and compliance posture.
API Access for Management
Finally, API access CAN be handy for managing and automating your BI deployment at a certain scale. Look for tools that provide comprehensive API support and allow you to manage and automate your deployment programmatically.
For example, some tools offer APIs for managing users and permissions, while others offer APIs to download and upload charts and dashboard definitions.
Especially for self-hosted setups or certain scales, definitions as code can be a crucial time saver.
Ease of Use and Testing
Another important factor to consider when choosing a BI tool is ease of use and testing. How easy is the tool to use and learn, and what features and capabilities does it offer to support testing and prototyping?
Hands-on Testing with Free Versions or Trials
Most BI tools offer free versions, self-hosting options, or free trials. Take advantage of these offerings to test the tool with your own datasets and use cases. Hands-on testing is invaluable for understanding how well the tool fits your needs and requirements.
When testing BI tools, it's important to involve potential end-users and gather their feedback on ease of use, functionality, and overall experience. This can provide valuable insights into how well the tool will be received within your organization and help you make a more informed decision.
Key Features to Test
When testing BI tools, there are several key features and capabilities that you should evaluate and test. These include:
Pivot tables: Every business user wants to either see or build a pivot table. Test how easy it is to create and manipulate pivot tables within the tool.
Check for more advanced hierarchy-handling (sorting) and look and feel with collapsing/expanding these.
Date comparisons: Test how easy it is to do date comparisons, such as week-on-week or month-on-month comparisons. These are common use cases that can be challenging to implement in some BI tools.
Data exploration and visualization: Test how easy it is to explore what’s already out there instead of re-inventing the wheel (searchability) and how quickly somebody can get a sufficient answer for their question?
AI features: In canned demos, YouTube videos, or presentations, the AI Assistants always look magical. How does it behave with your data, potentially a bit more complex and messy than the usual Tableau Superstore or dbt’s jaffle shop? How picky do you need to be with naming of metrics, and how do you see this working in real life?
Gathering Feedback from End-Users
Finally, it's important to gather feedback from potential end-users and involve them in the testing and evaluation process. This can help you understand how well the tool fits their needs and requirements, as well as identify any potential issues or challenges that might arise during deployment and adoption.
For example, you might want to conduct user interviews or surveys to gather feedback on ease of use, functionality, and overall experience. You might also want to conduct usability testing or user acceptance testing to evaluate how well the tool supports specific use cases and workflows.
Conclusion
Choosing the right BI tool for your organization is a complex and challenging process that requires careful consideration and evaluation of a wide range of factors and requirements. By asking the right questions and testing tools hands-on, you can find the BI tool that best fits your specific use case and requirements.
Remember, the best tool for one organization might not be the best for another, so take the time to evaluate your options carefully and involve potential end-users in the testing and evaluation process. With the right approach and mindset, you can find a BI tool that empowers your users, streamlines your workflows, and drives better, more informed decision-making across your organization.