Many customers of SaaS products request custom report features, but what they are actually asking for is the ability to explore their own data. Self-serve analytics enable this without needing your team to build and maintain endless bespoke dashboards. Let’s explore who self-serve dashboards are actually for, where common approaches break down, and where custom solutions make sense.
Why SaaS Customers Need Self-Serve Analytics
Any software that stores, processes, or generates customer data creates demand for analytics. The challenge isn’t whether customers want insights, it’s that there is no single set of questions, metrics, or views that works for everyone.
This is especially clear in two-sided marketplaces. These products typically serve two groups: supply-side users and demand-side users. Using Stripe as an example, supply-side users are the businesses that integrate Stripe into their product, while demand-side users are the end customers making payments. Analytics is primarily valuable to the supply-side, who want to understand how demand-side users behave and how that behaviour impacts their business.
Even within that group, analytics needs vary widely. Different customers care about different metrics, levels of granularity, time horizons, and comparisons. Some want high-level trends, others need to drill into individual events. Dashboards that attempt to cover every use case quickly become cluttered and hard to use.
That’s why, as a Stripe customer ourselves, we actually use a completely separate tool to dig into our Stripe data. But, this unfortunately devalues our experience in Stripe.
Many SaaS companies respond by manually building custom dashboards for their highest-value customers. While this can deliver real value and improve retention, it is expensive, slow, and difficult to scale. For the majority of customers, the cost simply doesn’t justify the effort, leaving their analytics needs partially or entirely unmet.
When those needs aren’t met inside the product, customers turn to external BI tools. That pulls insight generation away from your platform, forces users to learn another tool, and reduces engagement with your product. The result is lost value for both the customer and the SaaS provider.
Self-serve analytics exists to close this gap. It allows all customers to shape dashboards around their own questions, choosing which charts matter, how they’re filtered, and how data is explored, without requiring your team to build and maintain bespoke dashboards for every use case.
Common Ways SaaS Teams Add Self-Serve Reporting (and where they fail)
There are a few common approaches to building self-serve dashbaords that we have seen throughout the years, and have seen fail. Let’s have a look at each of them.
1 - Connecting an External Tool
We already mentioned External Tools as an example earlier, but let’s explore this solution in more detail. External Tools have already solved the problem of custom reporting, so why re-invent the wheel? Customers can hook one up to an API, CSV, or database source, and explore their data in a fully custom manner.
They do however offer some shortcomings. External Tools are not specific to your product, so they require deep customization, and a steep learning curve for customers. Once customers have a working setup, they are often too afraid of changing it too much, as it can be easy to break a working report in an external BI environment that you are not deeply familiar with.
If you supply an external tool for your customers, there is also a large support cost. Due to the dashboards not being specific to your products use-case, changes, fixes, and versioning can become a complex and costly task quickly.
Another disadvantage is that external tools take users away from your product. Engagement and usage habits are key factors in retention. Simply put, the more time users can spend on your platform, the more they want to keep using it.
2 - Using CSV Exports and SQL Access
Allowing your customers access to their analytics data directly can be a great benefit. While they still may require an External Tool (see above) to properly analyse their data, they can also simply search through it manually, import it into an excel spreadsheet, or transform and analyse it programmatically, so this solution does offer a lot of flexibility.
However, data access like this always comes with security concerns and consistency issues. It’s critical that the SQL access and CSV exports do not leak any data, and that their schema stays consistent, even when your database evolves, so that customers can keep using their working pipeline to analyse the data exports. Both of these add an engineering burden, and a quite often very manual process of adapting data transforms and schematics, when your product grows.
3 - Hooking Up a Charting Library to Some Data
This can be a quick and easy starting point, that unfortunately doesn’t scale well beyond a hand full of small static charts. Hooking up an open-source react charting library like MUI X Charts, or Remarkable UI to a simple API endpoint and displaying some data is a quick task for many engineers, and can lead to instant results. It’s a great starting point for trying out analytics in your software.
The issue with this solution comes with the growing complexity of your SaaS App, and diverse analytics needs by different user groups. Users may want to drill down into their data in ways you can not predict, and building out every possible use-case can become a daunting engineering task. New metrics generated by new features also require new charts, but not every customer may be interested in every feature, and it can quickly become difficult to prevent your dashboards from feeling crowded and overwhelming.
The solution to cater to as many use-cases as possible, is to allow for deeply customizable dashboards, aka self-serve analytics.
Why Building a Self-Serve BI System is Harder Than it Looks
A self-serve dashboard is a good solution to the problem of diverse customer analytics needs, but what does it take to build one, and what route should you take to make this task as easy as possible?
The difficulty of building and maintaining a self-serve dashboard is highly linked to the complexity of your SaaS. The more data access you add, the more complex it becomes to maintain. The usual first approach to data access for analytics is to write a custom query, just like you would for a simple get endpoint. This adds a lot of maintenance complexity, as every dimension needs its own endpoint.
It also introduces performance scaling complexity. Data requests for analytics can become quite large easily, as customers accumulate a lot of data. It becomes easy to accidentally build queries that do not perform well, and are not easily fixed by adding indexes. Caching strategies and layers become very important to not over burden the database.
There is also a long tail of user interactions and user experience considerations surrounding self-serve analytics dashboards. If your curious to learn more, we’ve written in detail about this in our previous article “How Complex is it to Build Customer-facing Analytics?”.
How an Embedded Analytics Solution Reduces Engineering and Maintenance Overhead
So if building a custom self-serve analytics solution is time and cost consuming, how can we reduce this engineering overhead? There are developer tools and SaaS solutions like Embeddable, that reduce the number of components in a self-serve architecture that you need to own. Challenges an embedded analytics developer tool can help you with include:
Caching and Performance
As previously mentioned, caching performance and scalability are major concerns for overhead. By using data-access tools that perform smart caching, such as Cube, which Embeddable uses internally, these complexity costs can be mitigated. The data access layer can now live separately from your main application, and employ pre-aggregation caching strategies to alleviate the load on your database.
Api Endpoints
An external tool can also implement analytics API endpoints, removing the need for you to write and maintain your own. In conjunction with a data-access layer like Cube, these endpoints can be managed in a way where they allow you to access any data configured in your data-access layer, in a secure and predictable manner.
Dashboard State Management
There is also the matter of state management for dashboards, which can become quite complicated with multi-tenant dashboards specifically. If you want to learn more about how we solve this problem, have a look at our previous article “Managing Real Time Shared State in Embedded Analytics”. Many ready-made BI solutions offer similar features, but choosing a developer-first tool lets you keep full control and ownership over your own components, making your custom dashboard a part of your own platform for customers.
What is Not Outsourced When Using an Embedded Analytics Solution
What remains in your control when outsourcing self-serve to an embedded analytics solution is your data, and the charting components. Data remaining in your control and on your servers means that you do not have to actively export your data, and you do not have to adapt your database or transform your data for a specific analytics solution. The charting components remaining in your control means that you can easily style it in a way where it looks native to your product, and you can re-use your previously built components and design language.
When Building Custom Reporting in-House Actually Makes Sense
It can still make sense to stick to a fully in-house solution in some cases. For some analytics features there’s little need for iteration, and you don’t expect to add new metrics, dimensions, or customer-specific views over time. In these cases, where requirements are predictable, edge cases are limited, and access rules are straightforward, the analytics can be clearly scoped and delivered quickly without much need for further work, and it might therefore make sense to simply build in-house.
Another example is tools that do not only read data, but also transform it and written to the database. An example for this would be if you are developing a CRM. Analytics dev-tools like Embeddable only help in cases where the data is read-only. If your product requires customers to manipulate the data behind their charts directly, you should consider developing a custom solution.
How to Choose the Right Approach for Your SaaS Product
Let’s summarize this article by going through a checklist, so you can determine which approach is right for you.
- Do you have small, well defined project that doesn’t need to scale or change?
- Consider trying to build your own solution
- Are you looking for a comprehensive in-house solution to analyze and manipulate analytics data?
- Look into existing Business Intelligence tools
- Do you need complex customer facing dashboards, that are a part of your platform?
- Try Developer First Analytics Tools
Hopefully this article gave you some insights into choosing the right approach your analytics dashboards, and the reasoning behind it.
