A guide to building an embedded BI product in SaaS

Goal

Build a white-labeled customer facing reporting module with enterprise-grade scale and security, embedded in your app.

Problem

Your customers are now generating more data than ever in your app. They love your product, and are demanding more from it in order to improve their experience on your app. However, you are struggling to go-to-market in a timely manner to serve their data needs.

Solution

A white labeled embedded analytics product for your end customers with an enterprise-grade BI experience.

Here are key components of the ideal solution:

Business

1. Single UX for all: internal teams, external users.
2. Self-service - end users can create their own reports, download data and do BI own their own
3. White labelling - embed BI natively into your app
4. Predictable pricing as you scale.
5. Enterprise-grade security

Engineering

1. Auto-scale dashboards as you add more customers
2. Fully flexible to modify. eg: change chart colors, add custom filters, themes etc.
3. Enterprise-grade performance with large datasets

The goal here is to empower your end-users to gain insights from their data sitting in your app with a powerful analytics experience they are used to.

You’d want to satisfy your customers’ request in a timely manner, so you don’t lose new deals or experience churn otherwise.

Tangentially, you will experience higher retention with better reporting.

Complexity of building a reporting module

Before we get into how DataBrain works, here are some challenges you will face as you think about building a customer-facing reporting module:

1. Designing your dashboards
2. Organizing data for analytics
3. Engineering for data security
4. Engineering for self-serve capabilities
5. Engineering for performance and auto-scaling

Let’s visit each one.

🎨 Week 1-2: Designing your dashboards

You’ve decided to build your reporting module and as a designer or product manager, here are questions you will encounter:

1. How can customer requests be mapped to KPIs that provide them with value?
2. What charts and dashboards can be used to better illustrate KPIs?
3. How can KPIs be personalized for different personas?
4. How can KPIs be scaled to fit the needs of different organizations?

The goal here is think deeply about what jobs can be done for your end customers using data they’ve generated within your app. You should also think about how to make the dashboard visually appealing, so that your customers can quickly understand their data. Finally, consider how to make the dashboard flexible, so that it can be easily modified as customer needs change.

🗂️ Week 3-5: Organizing data for analytics

As a product person this is where you will spend most of your time. This is also one of the most important steps, because if you don’t get the data correct, your end-users are going to lose trust in your product and brand. Here are some basic questions you will need to answer:

Product, Data Analyst

1. How do I convert  KPI’s into metrics?
2. What is the SQL for those metrics?

Engineering

1. How do I connect to my data source from my app? eg: MongoDB
2. How do I convert SQL into a chart or a dashboard?
3. How do I ensure performance at scale?
4. Which charting library do I choose?

While the above list is not exhaustive, there are other complex things to research like versioning metrics, choosing the right data format for the charting library etc. The goal here is to ensure your data is ready for analytics purposes, without needing to hire a data engineer, a business analyst or waiting on your data team. You also don’t want to derail your existing engineering roadmap by sending your engineering team on a research hunt.

🛡️Week 6-9: Engineering for data security

Now this is where things start getting serious. You’ve decided you are going to build something but from research, you suddenly realized that there is more than what meets the eye:

Engineering

1. How do I ensure company A’s data isn’t seen by company B?
2. How do I ensure Row-level security?
3. How do I ensure access control among different end-user personas?
4. How do I ensure authentication and authorization?

The goal here is to make sure your customers’ data is secure, and that their data is not accessible or shared with anyone else. You also want to securely provide personalized dashboards based on roles within an org - eg: an Admin dashboard view will be very different to a staff or a member’s view.

🤳🏽 Week 10-13: Engineering for self-serve capabilities

If you want to give your customers the ability to create their own reports and download data, you’ll need to ensure you have the right backend engineering infrastructure. Here are some questions you’ll need to answer:

Engineering

1. How do I ensure customers can create their own charts and dashboards?
2. How do I ensure customers can explore, drill-down and play with datasets?
3. How can I ensure customers can export their data?
4. How do I enable customers to schedule reports?

Product

1. How do I ensure I don’t manually create a dashboard for every single customer?
2. How do I ensure I make changes to dashboards, that affect only specific customers?

The goal here is to enable your customers to gain insights from their data quickly and easily. This will enable them to make decisions faster and improve their experience on your app, without depending on a data analyst or pinging you for data requests.

⚖️ Week 14-16: Engineering for performance and auto-scaling

This is the last piece of engineering that you need to consider when building your customer facing analytics module. Here are some questions you’ll need to answer:

Engineering

1. How do I ensure customers can query large datasets quickly?
2. How do I ensure the customer experience is smooth when the data set grows?
3. How do I ensure performance doesn’t suffer when more customers are added?
4. How do I ensure customers can view data in real-time?
5. How do I ensure customers can cache data and refresh it themselves?

The goal here is to ensure your customers can query and explore large datasets quickly, without suffering performance bottlenecks. You also want to ensure as more data is created, performance does not degrade and everyone has the same consistent experience.

‍