What's Covered
Headless BI (business intelligence) is one of the more recent developments in the headless architecture trend. Its applications and benefits are yet to be commonly understood, but those who do can stand to benefit greatly.
Using a headless architecture to accurately compile data and show the same results across different front-ends isn’t necessarily a new idea. We’ve already seen the success of headless CMSs, for example.
However, headless business intelligence (BI) is a more recent idea. It comes from the need to properly define business concepts so all stakeholders can get the same results when querying a database—no matter where they’re making the request from. 'Data consistency and reliability' is the name of the game.
In this article, we’ll explain what a headless BI is, how it’s different from a semantic layer, and when to consider this option for your internal or customer-facing analytics.
Design, embed your analytics experience, and manage API calls from your headless BI with Embeddable.
Learn More.
What is headless BI?
Headless BI is an architecture model that introduces a new ‘layer’ to your data stack that sits in the middle of your data warehouse or database and the tools that consume the information. It acts as a single source of truth for interpreting raw data.
The key aim of Headless BI is to model the data and provide a consistent, human naming convention for key metrics (e.g., MRR, ARR, or active subscribers) before they enter your multiple BI and reporting tools. This enables you to present KPIs consistently across the business.
‘Headless’ simply means ‘without a presentation layer’ —A.K.A, no front-end. In the background, a headless BI essentially separates the back-end (i.e., modeling and semantic layers) from the front-end (i.e., visualization layer). This makes the former available to multiple front-ends through an API, which makes your data more reliable and consistent across all of your business applications.
Looker (now owned by Google) became a popular BI tool partly because of LookML, its modeling language that allows users to model the data within the platform. However, LookML is tightly coupled with the BI tool, meaning you can’t use all that modeling work in your other data-consuming business applications. Looker is now reportedly working on separating their modeling layer from their BI tool so you can use LookML as part of a headless BI architecture. Headless BI is sometimes confused with a semantic layer, but they’re a little different, as we’ll explain in more detail below.
With traditional architectures, your business applications access your database directly while you model data and calculate metrics like ‘Paying Subscribers’ within your BI and reporting tools. Just to reiterate: Headless BI is an architecture that extracts that process from those tools and establishes a new, centralized layer in your data stack to manage it. This layer then feeds into all of your BI and reporting tools via an API.
A headless architecture usually breaks into two core and two optional components.
Core Components:
- Data modeling. Model datasets, columns, tables, dimensions, facts, relationships, and measures to ensure these are consistent across the business.
- Semantic layer. Align all business concepts and definitions and make it easy for people to read, understand, and get the same results when querying the data in any business application or tool across the business.
Optional components:
- Access control. Define all governance rules, permissions, and security measures within the headless BI, centralizing access control to certain data. Note—some prefer to manage access control in each business application separately as some teams may have different user permissions in each one. It can also make it easier to add or remove access in the tools’ UI.
- Caching. Determine which pre-aggregated data your system will store to reduce the latency and fetch data faster. Note–some argue this shouldn’t be centralized as you may have different latency and freshness requirements across various business applications feeding from the same data sources.
A headless BI architecture is also different from standard architectures because the semantic and modeling layers are separated from the visualization layers. This means that the metrics are defined once, and all of the business applications that need to use the data are fed from a single source of truth.
Here’s a (simplified) diagram to help visualize the difference in the approaches:
Why you need to have a single source of truth
Let’s say a sales manager asks a data engineer to build a dashboard with the number of monthly active users (MAU), daily new leads and their sources, and revenue up to date. They use the internal BI tool to take data directly from Salesforce.
While building the charts, they identify different metrics that could go under MAU: total active users, monthly paid accounts, and free active users. They choose to show the total active users as MAU. This works fine, the sales manager is happy about the assumption and uses the dashboard to inform future decisions.
However, let’s say there’s another person from sales who manages a different account. They ask another data engineer to make them a dashboard with the same KPIs, but this person chooses to show monthly paying accounts as MAU. Now salesperson #1 and salesperson #2 are viewing two different data sets and comparing accounts thinking they’re viewing the same metric.
This kind of issue happens when you don’t have a single source of truth where you have defined how some concepts, metrics, or measures are calculated and what they mean to your business (more about this below).
Why is headless BI important?
Headless BI can enable companies to maintain data consistency and easily manage models and definitions across all data tools. “Headless BI gives you higher confidence in your data and reduces the data engineering time when managing models and definitions,” says Harry Marshall, COO at Embeddable.
As we’ve seen, a headless BI architecture enables you to have a single source of truth, which ensures data reliability and consistency across your business. When changes are made to your centralized data models and semantic definitions, they update across your entire architecture automatically.
This positively impacts the amount of time, effort, and complexity of dealing with updates, introducing new concepts, or holding investigations. A headless BI reduces management and maintenance overheads.
Adopting this architecture can also help improve security when choosing to centralize data management and access permissions—although you could also do this in connected business applications.
What is a semantic layer?
A semantic layer is what the name suggests: It’s a layer between your raw data and your consumer data where you take messy, non-human information and create semantic (i.e., word-based) definitions. These concepts allow your team, customers, investors, or any other viewer to read and understand the information easily.
Airbyte describes it as follows: “The semantic layer is a translation layer that sits between your data and your business users.” In other words, this is the layer that makes your data and business concepts speak the same language.
By defining your business concepts in the headless semantic layer, anyone from your company could query any system (connected to the same data source) and get accurate results.
The semantic layer is where you might define something like an 'active subscriber', i.e. 'users' (in the user table) where there is a corresponding row in the 'subscriptions' table with the same user_id and a status of 'active'.
All BI tools, like Power BI, Looker, Tableau etc. arguably enable you to create a ‘semantic layer’ within them, in that they allow you to take the raw data from your database and create analytics like Active Subscribers, New Users per Month, or MRR (Monthly Recurring Revenue). These metrics are typically not already defined in a nice clean database table for you to just pull into a line chart - they require modeling and defining. When you take the raw data and create these models and definitions within your BI tools and other business applications, you are creating the semantic definitions over and over again across each tool.
By creating these definitions in the semantic layer of a headless BI architecture, this this will ensure that all business applications have the same definition, and one of them can't erroneously define it as, for example: 'users' (in the user table) where there is a corresponding row in the 'payments' table with the same user_id (this would be a customer who has paid something, but not necessarily one with an active subscription). When you define your business concepts in a headless semantic layer, anyone from your company could query any system (connected to the same data source) and get consistent results.
Headless BI vs semantic layer
The difference between headless BI and the semantic layer is that the former is the architecture, whereas the latter is one of its components.
Note: You can execute the semantic layer within BI tools and other business applications, or within a headless BI architecture that houses the semantic modeling and feeds the tools.
Examples of headless BI tools and semantic layers
Given this is a new trend, there aren’t many plug-and-play solutions in the market. The most established (and very robust!) provider of headless BI is Cube.dev. This company offers both an open-source headless BI (you can find the source code in its GitHub repo) and an API-first semantic layer. Cube’s headless BI comes with four components for data modeling, access control, caching, and APIs.
Another provider is dbt. It has excellent tools for modeling data and has become very popular, but (at the time of writing) is still working on its semantic layer before public release. In dbt, you can define your metrics and models in a centralized way, and feed them into your analytics tool. Its offering is currently in beta and not yet available to the public.
As mentioned above, it’s rumored that Looker is also working on separating its modeling layer from the BI tool. This would enable users to use LookML within a headless architecture.
When to use headless BI
Many businesses are now opting for a headless architecture for their BI requirements because they have multiple tools consuming data from the same source (most companies!) and require data consistency across the business. A headless architecture creates data consistency and reliability by centralizing the data processing and business logic, independent of the multiple visualization layers.
This creates a ‘source of truth’ for your company metrics, where a MAU chart in any tool will display exactly the same data.
If you’re feeding raw data into your BI tool, customer-facing analytics, financial reporting tools, a CRM, a data room and any number of other third-party tools - there’s a high degree of probability that you’ve got some inconsistencies in your definitions of core business metrics when you calculate them within each tool.
If you have inconsistently-defined data, you may be overreporting or underreporting key metrics on which critical business decisions are made. Your team may become frustrated and confused when they see different numbers across different reporting tools, and they may not know what the source of truth is.
If you’re experiencing inconsistencies in metrics reported across your business, then it might be worth considering moving to a headless BI architecture, as this will ensure that all reports on key metrics match each other. The alternative is likely to be lengthy investigations into ‘which tool is right’ (if any) and long discussions about which way of reporting your MRR/MAUs/Active Subscribers etc. is ‘correct’.
Without a unified approach, different departments might calculate key metrics differently. Some examples of where this can have negative consequences include: if your financial reporting and your marketing teams metrics are not at parity, you may have a marketing team taking actions that do not align with the financial needs of the company. Similarly, if the marketing department and the sales department might also have different definitions for a "lead," leading to misalignment in strategies and goals.
Using headless BI for embedded analytics
If you’re going to opt for a headless architecture, it’s good practice to use it to feed ALL of your data-consuming processes, including user-facing analytics.
Where some BI tools and embedded analytics tools can be quite opinionated on how they work with the data they are presented with, some tools are more agnostic. For example, Embeddable is built from the ground up to work with headless BI tools like Cube.dev and can easily receive pre-modelled and defined data to be presented in your customer facing analytics experiences.
The benefit of modeling this data before it goes into Embeddable (and some other embedded analytics tools), is that non-technical people, and people who are not very familiar with your database tables can come in and easily build a dashboard from the predefined data models you expose to the tool. This means your product team can create new charts and dashboards for your customers without having to schedule a ticket into the next sprint, or having to wishfully place it in the backlog.
Of course, as you’ll know from above, the metrics you show to your customers will also be consistent with how you report on those metrics internally–as is the intent of this architectural approach.
If you’re exploring adding customer-facing analytics to your application or replacing your current architecture, make sure your headless BI platform integrates with your embedded analytics tool.
How to use headless BI with Embeddable
If you’re using a headless architecture for embedded analytics, you’ll be glad to hear that Embeddable enables you to do that right out of the box. This means you’ll be able to present consistent data to your users in a fast-loading, fully bespoke analytics experience that didn’t take an army of developers to build.
If you’re not yet familiar, Embeddable is a toolkit for developing fully bespoke, highly performant analytics experiences and embedding them into your app.
Like in a headless architecture, Embeddable decouples the front-end and the back-end of the traditional customer-facing analytics approach. In traditional embedded BI tools like Power BI and Looker, the back-end is provided for you (great!), alongside the front-end components (for which you have absolutely no access to the code).
This saves you lots of work on the back-end, but it limits the level of customization you can achieve on the front–end—and restricts you from delivering truly remarkable analytics that look like they are part of your application.
Embeddable gives you full control over the visualizations while we handle the boring back-end bits that take up a ton of your time.
Like in a headless architecture, Embeddable also is agnostic to the rest of your stack. This means you can connect any database to it. And since you own the front-end code in your Git repo, you can use any charting library you want, as well as access some out-of-the-box charts to get you started.
Ultimately, Embeddable brings together the level of personalization of a custom-built analytics solution with the straightforwardness and speed of embedded BI tools. This empowers you to deliver high-performing and tailored analytics experiences in a fast and cost-efficient manner.
This three-part developer toolkit comes with a:
- Front-end toolkit for building custom charting components
- Back-end engine that handles all the technicalities for you (this is where you define the data models)
- No-code builder for easy dashboard creation by non-technical team members
Embeddable provides a competitive, flat price—including unlimited access for builders, designers, and viewers. It’s also compatible with headless architectures and the fastest databases for real-time analytics.
If you want to learn more, request the developer docs or get in touch with us directly from our homepage.
In Summary: Headless BI vs semantic layer
We’ve explored the differences between headless BI and a semantic layer—and how they can take your data analytics to the next level. Here’s a quick recap:
- A headless BI is an architecture model that decouples the modeling from the reporting and visualizations
- A semantic layer is part of the headless BI architecture and standardizes business concepts
- Headless BI helps maintain data consistency and simplifies data modeling across tools
- Headless BI is used by many companies that have multiple tools connected to the same data sources
We also explained how going headless can be a good approach for embedded analytics and how to integrate this into Embeddable.
Embeddable is a toolkit for developing fully bespoke analytics in 10% of the time and at a much more affordable price. Plus, with Embeddable you make your visuals part of your code repo so you can control the UI/UX of your analytics experience.
Design, embed your analytics experience, and manage API calls from your headless BI with Embeddable.
Learn More.
Frequently asked questions about headless BI
What’s the difference between headless BI and a semantic layer?
The main difference between a headless BI and a semantic layer is that the former is an architecture model, while the latter is a process that can be extracted into this architecture type. A headless BI is where the front-end is decoupled from the back-end, whereas a semantic layer unifies the definitions of business concepts to simplify querying.
What are the advantages of headless BI?
One of the main advantages of headless BI is that it ensures data consistency and simplifies data modeling. This way, everyone querying the same data source will get the same results—despite the tool they’re querying from.