So you need to provide analytics to your customers. You’d like to put dashboards and charts in your app, make sure nobody can see data that isn’t theirs, and put that in front of your customers or users. These customers may be other businesses like vendors, regulatory agencies, or other organizations. Regardless of the audience, they need reporting. How should you go about it, and how would you use Metabase to get the job done?
Some context: a lot of companies come to Metabase saying that they want to embed analytics in their application, asking if Metabase can do that. The answer is yes, it can, and that might indeed be the right option for that company. But that’s not the right question.
In this article we’ll lay out the map for what’s possible with Metabase, and clarify some muddy vocabulary to help surface the options available for shipping analytics with Metabase.
The goal: delivering analytics
First, let’s be especially clear on the goal: what we are talking about is delivering analytics to customers. Can you give customers the data they need to understand their business and make better decisions? To that end, embedding is simply one strategy, not the goal. It can be easy to make the wrong (i.e., needlessly expensive) decision by conflating the two.
The bar for high quality external analytics
If delivering analytics is the goal, then what is the ideal delivery? That depends (and we’ll unpack our options below), but fundamentally the solution that ships should:
- Give customers the ability to analyze their own data.
- Restrict their analysis to only the data they’re authorized to see.
- Provide a great user experience.
With Metabase Enterprise Edition, it takes surprisingly little effort to deliver on all three of the above requirements, but there’s more than one way to get the job done. We’ll go through four strategies, ranging from low effort with big payoffs to high effort with staggering customizability, so you can get a better understanding of the advantages and tradeoffs of each approach, and land on the right strategy for your use case.
For most companies, we’re also going to make a case for the simplest option, because for the most part, escalating the effort only really moves the needle on the user experience.
Four strategies for delivering customer-facing analytics with Metabase
The order below situates the strategies from low effort (1) to high (4):
- The Metabase sidecar (start here)
- Metabase full app 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. You don’t have to embed Metabase in your app, nor are you setting up a standalone Metabase application just for the external folks you want to provide analytics to. Instead, this approach employs single sign-on, data sandboxing, and white labeling (branding) to provide the experience across your application and your existing Metabase instance.
Here’s how it works: 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 single sign-on (SSO) so that both your app and your Metabase instance can coordinate users’ permissions. (We’ll go more in depth about how these various technologies work together in an upcoming post.)
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. 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. Everyone is the hero in this story, without any embedding.
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. With Metabase, you’ll have delivered powerful analytics primitives via Metabase’s notebook editor, which your customers can use to define and save their own questions. 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 of a Metabase sidecar
- 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.
Tradeoffs of a Metabase sidecar
- What you don’t get: a lot of customizability. You’re just using Metabase’s UI and functionality.
2. Metabase full app embedding
One rung up on the effort ladder, full app embedding is the most popular strategy among our customers. You get a lot more control over the experience when you embed Metabase in your app, because you can design the experience around specific dashboards and charts. You can specify a set of screens for customers to navigate through, each with embedded dashboards and charts, and you can link those screens or dashboards together. And because you have the full Metabase app at your disposal, you can also expose the query builder so that users can ask their own questions of their data.
The amount of effort you put into full app embedding can vary widely, depending on how extensive of an experience you want to build. 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.
Advantages of Metabase full app embedding
- You can embed any Metabase screens, dashboards, or charts in your app, with full interactivity.
- Much more customizable, as you can create richer experiences in your app by embedding and customizing links between Metabase dashboards, charts, or pages.
Tradeoffs of Metabase full app embedding
- It’s more work: you’ll need to design and implement the pages that house the embedded Metabase screens.
- For now, you can only change Metabase’s color scheme, so there may be some aesthetic variance between the design of your app and the embedded Metabase components (like the fonts on a chart).
3. Fork the Metabase source code
Metabase Enterprise Edition will soon be source available, so you’ll be able to fork the code and enjoy unlimited power. Don’t like the fonts? Chart design? Grid system conflicts with your grid? You’ll have access to the CCS, the graphing primitives - the full source code. Go nuts.
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 of forking the Metabase source code
- 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.
Tradeoffs of forking the Metabase source code
- 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 full app 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 of rolling your own analytics platform
- Full control over the experience, without having to maintain a fork.
- Handle use cases other solutions (like Metabase) cannot solve for.
Tradeoffs of rolling your own analytics platform
- Most expensive option, with murky return on investment.
Which option is right for your organization?
Most companies choose full app embedding, as they want the extra customizability to provide a more curated set of screens for their customers. But one purpose of this article is to make it clear that embedding is not 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.
In an upcoming post, we’ll provide an overview of the challenges to delivering multi-tenant, self-service analytics, and the technologies Metabase offers to solve for those challenges.