Strategies for delivering customer-facing analytics
Compare the development effort, customizability, and security of different approaches to data sharing.
The goal: delivering analytics
First, let’s make sure we have a clear goal in mind: delivering analytics to customers. By analytics, we talking about giving your customers the right tools (e.g., charts and dashboards) and materials (the relevant data) to understand their business and make better decisions.
Some context: a lot of companies come to Metabase and say that they want to embed analytics in their application, asking if Metabase can do that. The answer is yes! Embedding is one of the most popular ways to implement customer-facing analytics. But, it’s not the only (or best) way to equip people with the tools and materials they need to do analytics.
If you want to build customer-facing reports or data visualizations (without giving people the option to play with data on their own), check out Publishing data visualizations to the web.
The bar for high quality external analytics
The way you implement customer-facing analytics will depend on your customers’ needs and your development resources, but fundamentally you’ll want to ship a solution that:
- Gives customers the ability to analyze their own data.
- Restricts their analysis to only the data they’re authorized to see.
- Provides a great user experience.
We’ll cover a range of strategies for implementation, from low effort with big payoffs, to high effort with staggering customizability.
In general, we recommend the simplest option that’ll meet your customers’ analytics needs. Once you’ve gotten some adoption and feedback from your customers, you can then escalate the level of effort to move the needle on the user experience.
Strategies for delivering customer-facing analytics with Metabase
The strategies below are ranked from low effort (1) to high (4):
- The Metabase sidecar (start here)
- Metabase interactive embedding
- Fork the Metabase source code
- Roll your own analytics platform
1. The Metabase sidecar
We’re calling our first strategy the “sidecar” because Metabase sits alongside your application, without being embedded in it. The sidecar approach uses single sign-on (SSO) to give customers direct access to your Metabase app, data sandboxing to customize data access for each person, and white labeling (branding) to make Metabase feel cohesive with the rest of your product.
Here’s what to expect from the process: you stand up an instance of Metabase, add your logo and brand colors, and hook up your databases. You then sandbox the data so that customers only see what they are authorized to see, and authenticate users with SSO so that both your app and your Metabase instance can coordinate users’ permissions.
With your branded Metabase sidecar set up, all you need to do is put links to your Metabase instance in your app, and your customers will have beautiful, on-brand dashboards and charts that they can explore themselves with Metabase’s easy-to-use query builders and drill-throughs. You can also set up custom destinations, to send people to other dashboards, questions, or even custom URLs. Your customers get great UX out of the box, and can do their own analysis on top of whatever stock dashboards you’ve set up for them — no embedding required.
The advantages of the sidecar approach are speed of setup and deployment, and also (and perhaps more importantly) that you don’t have to anticipate the kinds of questions your customers will ask of their data. Metabase comes with a graphical query builder tool to help people find, filter, and aggregate data on their own. You can still create stock dashboards to provide a starting point, or an editorial take on the data, but the point is you don’t have to.
Additionally, choosing to stand up a Metabase app as a sidecar to your app derisks the project. A Metabase instance is a prerequisite for options 2 and 3 anyway, and if, during the process of setting up your Metabase application, you find that it doesn’t fit your needs, you won’t have wasted any time figuring out how to incorporate Metabase into your app.
| Advantages | Tradeoffs |
|---|---|
| -Delivers on all three requirements for high quality analytics. - Quick to set up. - Easy handoffs. - Really powerful analytics primitives for your users. - Derisks the process. |
- What you don’t get: a lot of customizability. You’re just using Metabase’s UI and functionality. |
2. Metabase interactive embedding
One rung up on the effort ladder, interactive embedding is the most popular strategy among our customers. This type of embedding puts the entire Metabase app inside your app, giving people access to analytics features such as the action menu for drill-downs and the query builder for self-service data access.
The amount of effort you put into interactive embedding can vary widely, depending on how extensive of an experience you want to build. You can specify a set of screens for customers to navigate through, and you can link those screens or dashboards together. If your set of screens is small and straightforward, it may not be that much more work than a sidecar implementation. But since you are in control of your app, you can (with more effort) create a potentially much richer experience for your customers.
If you just want to provide your customers with simple reports and data visualizations (i.e., you don’t need analytics functionality like drill-downs or querying), you can use other types of embedding, like public embedding or static embedding. For more information, see Publishing data visualizations to the web.
| Advantages | Tradeoffs |
|---|---|
| - You can customize the user experience by setting up specific navigation pathways between any Metabase screens, charts, or dashboards. - Your users won’t have to leave your main app to view these Metabase screens. |
- It’s more work: you’ll need to design the pages that house the embedded Metabase screens. - Metabase offers a fixed number of appearance settings, so there may be some aesthetic variance between the design of your app and the embedded Metabase components. |
3. Fork the Metabase source code
Metabase Pro and Enterprise editions are source available, so you can review the code or fork it and do whatever you want with it. Chart design? Grid system conflicts with your grid? You’ll have access to the CSS, the graphing primitives—the full source code.
You may go this route if you really want to dial in the design of your embedded Metabase app to create a seamless experience. And even if you never take this route, it’s nice to know you have that runway available to change the design or add functionality if you ever have an analytics challenge that the stock Metabase doesn’t address.
| Advantages | Tradeoffs |
|---|---|
| - Granular control over the user experience for seamless integration with your app. - Ability to add functionality to dashboards, charts, and more. - Full control over the design of Metabase and its charts. |
- You have to maintain a fork; as new Metabase versions come out, you’ll have to integrate those changes into your fork. - It’s a lot of work. A lot less work that rolling your own analytics platform, but significantly more than interactive embedding. |
4. Roll your own analytics platform
Too many companies take on the work of building their own analytics software, often for reasons that are unclear. These companies spend a lot of time and money (on the order of millions to tens of millions of dollars) to build sub-par tools that Metabase outclasses out of the box, when they could be applying those resources to their core business and development.
With that said, there are legitimate reasons for building your own analytics platform. In this scenario, you likely already have a third-party analytics solution in place, but it’s falling short of meeting your needs. You know exactly what you need to build (and why you need to build it), and have the engineering resources to commit to the project. For example, you might have a permissions problem that you need to solve that Metabase (or another offering) can’t account for that is more than a simple matter of adding functionality and submitting a pull request. Just make sure the problems you intend to solve by writing your own platform are mission critical, and that existing offerings lack the features to handle them.
| Advantages | Tradeoffs |
|---|---|
| - Full control over the experience, without having to maintain a fork. - Handle use cases other solutions (like Metabase) cannot solve for. |
- Most expensive option, with murky return on investment. |
Which option is right for your organization?
Most companies choose interactive embedding, as they want the extra customizability to provide a more curated set of screens for their customers. But as we’ve discussed above, interactive embedding isn’t the only option for delivering analytics with Metabase. It might not be the best place to begin, especially if you’re a startup trying to make the most out of limited resources. In that case, take a good look at the sidecar approach—setting up Metabase as a sidecar to your application is the fastest way to deliver value to your customers. You can always transition to an embedded solution as you iterate, but in the meantime you’ll already be giving your customers the ability to make data-driven decisions, and you’ll develop a much better understanding of the analytics they need.
For larger companies, forking the source code might make sense. It’s more of an investment, but you’ll be able to deliver a much more cost-effective solution than if you were to take on building an analytics platform from scratch.
And, of course, if you’re not up for maintaining a fork, Metabase accepts pull requests! Take advantage of Metabase’s built-in feature set, submit a PR for that last bit of functionality you need to complete your analytics offering, and you’ll have the custom solution you need at a fraction of the cost it would take to build your own platform, all while improving Metabase for everyone.
Further reading
Next: Publishing data visualizations to the web
Share standalone charts and dashboards with the good people of the internet.