"Embedded analytics" sounds like a feature toggle and is actually an architecture decision. This is a plain-language explainer for product and data leaders: what embedded analytics is, what makes it genuinely hard, how to think about build vs. buy, and why the AI-native version of it — an analyst living inside your product — only stays trustworthy over a governed semantic layer.
TL;DR
Embedded analytics is analytics delivered inside another product — dashboards, reports, or an AI analyst your customers use without leaving your application — rather than in a separate BI tool they log into. The hard part isn't the charts; it's multi-tenancy and performance: every customer must see only their own rows, with security enforced per tenant, and queries must stay fast under concurrent load. It's distinct from internal BI (which serves your own teams), but the strongest stacks serve both from one governed model. In 2026 the frontier is an AI analyst embedded in your product — which is trustworthy only over a semantic layer. Cube is the agentic analytics platform built on a semantic layer, with embedded analytics as one of its two equally-weighted use cases.
A working definition
Embedded analytics is the practice of delivering analytics inside another software product, instead of in a standalone BI tool users log into separately. The charts, dashboards, reports — or, increasingly, an AI analyst — appear in the host application, styled to match it, governed by its login and permissions, and used in the same workflow where the rest of the work happens.
For most companies the host application is their own product and the audience is their own customers. A logistics platform shows each shipper their delivery performance; a payments product shows each merchant their transaction trends; a SaaS tool shows each account how it's using the software. The defining trait is that the consumer is outside your company, looking at their slice of data, inside your product — which is what separates embedded analytics from internal business intelligence, where your own team analyzes your own data.
Embedded analytics is defined by where it runs and who it serves, not by a particular chart library. It is not a data warehouse: it sits on top of your warehouse — Snowflake, BigQuery, Redshift, Databricks — which stays your storage and compute. And it is not the same product as internal BI, even though, done well, both can run on the same governed foundation.
How embedded analytics works
Under the hood, shipping analytics inside a product comes down to a handful of jobs:
- Connect to the data. The analytics layer reads from your warehouse and operational sources — ideally without copying data into a separate silo, so what customers see is current and consistent with the rest of your system.
- Define metrics once. "Active users," "revenue," "on-time rate" get one definition, so the number a customer sees in an embedded chart matches the number elsewhere and across features.
- Scope every query to the tenant. Each request is filtered to the customer making it, with row- and column-level rules applied per tenant — the part that has to be airtight.
- Render in the host app. Dashboards, charts, or a chat interface are embedded via SDKs, APIs, or iframes and themed to match the surrounding product.
- Stay fast under load. Caching and pre-aggregation keep common queries returning in well under a second even when many customers hit the same feature at once.
The result is analytics that feels native to your product, returns consistent numbers, and keeps each customer's data isolated — without each feature re-implementing security and metric logic from scratch.
What makes embedded analytics hard
The dashboards are the easy part. Three things make embedded analytics a real engineering problem, and they're the reason most teams underestimate it.
Multi-tenancy. In internal BI, everyone who logs in is on your team. In embedded analytics, the viewers are your customers, and a single mistake means one customer sees another's data. You need row- and column-level security keyed to each tenant, and the robust pattern enforces it before the query is generated — the user's tenant and role are part of how the SQL is compiled, so the query already carries the right restrictions. Filtering results after the fact is easier to get subtly wrong, and "subtly wrong" here is a data breach.
Performance under concurrency. Internal dashboards are queried by tens of people. Embedded features are queried by all your customers, often at once, sometimes on every page load. Hitting the warehouse directly for each request gets slow and expensive fast, so you need caching and pre-aggregated rollups to keep latency low and warehouse cost sane under real load.
Consistency and maintenance. Metric definitions tend to drift when each feature computes its own. The number in the embedded chart should match the number in the export, the email digest, and your own internal dashboard. Without a shared definition that's a constant source of "why don't these agree?" — and a maintenance tax that grows with every new surface you ship.
These are exactly the problems a semantic layer is built to absorb: define metrics and access rules once, enforce tenancy at compile time, and cache aggressively — so every embedded surface inherits security, consistency, and speed instead of reinventing them.
Build vs. buy
Once the hard parts are visible, the real question is whether to build the embedded layer yourself or adopt a platform. Both are legitimate; the tradeoff is about where your engineering time goes.
| Build from scratch | Buy a platform | |
|---|---|---|
| Multi-tenant security | You design, enforce, and audit per-tenant access rules yourself | Row- and column-level security enforced per tenant out of the box |
| Performance | You build caching and pre-aggregation and tune them under load | Caching and pre-aggregation handled by the platform |
| Metric consistency | Each feature risks its own definitions unless you build a shared layer | One governed model; metrics defined once and reused |
| UI | Full control, but you own and maintain the analytics UI forever | Embeddable components plus the option to bring your own front end |
| Ongoing cost | A second product competing with your roadmap for engineers | Infrastructure you configure; effort goes to the customer experience |
| Your data | Stays in your systems | Stays in your warehouse — the platform sits on top |
Building gives you total control and makes sense when analytics is your product. For most teams, though, the multi-tenant security, performance engineering, and metric governance are undifferentiated infrastructure — necessary, hard, and not what customers are paying for. Buying that infrastructure, while keeping your data in your own warehouse, lets you spend engineering effort on the experience your customers actually see.
AI-native embedded analytics
The newest shift in embedded analytics is the interface. For two decades it meant charts and dashboards inside a product. In 2026 it increasingly means an AI analyst inside your product: your customers ask questions in plain language and an agent answers over their data, builds the calculation it needs, and returns a result — scoped to their tenant the whole time. This is agentic analytics pointed outward, at your customers, instead of inward at your own team.
This raises the stakes on trust. Pointed at raw tables, an LLM has to re-derive your business on every prompt — what "revenue" means, which joins are correct, and crucially which rows belong to which tenant. So the same question can return different numbers across sessions, and a bad query can cross a tenant boundary. That's not something one more prompt example fixes; it's a missing layer.
A semantic layer is that layer. The agent selects from certified metrics by name, with per-tenant security applied at compile time, so an embedded AI analyst answers consistently, stays inside the customer's data, and produces results you can trace to named metrics. Brex did exactly this: they evaluated approaches for grounding AI on their data — including the dbt Semantic Layer and LookML — chose Cube, and built Brex Spaces, an embedded AI financial analyst, on top of it. Their one-line summary is the cleanest case for the category: the semantic layer is what makes the AI useful.
Where Cube fits
Cube is the agentic analytics platform built on a semantic layer, and embedded analytics is one of its two equally-weighted use cases — alongside internal business intelligence, both running on the same governed model. Its open-source foundation, Cube Core (Apache 2.0), is the semantic layer: you model metrics, dimensions, joins, and access rules once, and serve them over SQL, REST, GraphQL, and an MCP server for AI agents. Row-level, multi-tenant security is applied at compile time, so each customer sees only their own rows; pre-aggregation caching keeps embedded queries fast under concurrent load; and you can embed Cube's components or bring your own front end. The same governed model can power an AI analyst inside your product, not just static dashboards — which is what Brex Spaces is, and why 400+ companies build on Cube across both use cases. Webflow is another company that ships embedded analytics on Cube.
Two clarifications that come up immediately. dbt is a partner, not something Cube replaces: dbt models the data; the platform governs the metrics and serves them to embedded apps, BI, and AI agents — model in dbt, serve via Cube, which reads dbt models. And embedded analytics does not replace your warehouse: it sits on top of Snowflake, BigQuery, Redshift, or Databricks, which stay your storage and compute. The foundation under all of it is the semantic layer — see what a semantic layer is for why defining metrics and access once is what makes embedded analytics trustworthy.
Our verdict
Embedded analytics is analytics delivered inside your own product — for your customers, in their workflow, scoped to their data. The charts are the easy part; the hard part is multi-tenant security, performance under concurrent load, and metric consistency across every surface. That's why build vs. buy usually tips toward buying the infrastructure and keeping your data in your own warehouse. And the AI-native version — an analyst inside your product — is trustworthy only over a semantic layer, which keeps answers consistent and tenants isolated. The strongest fit is a platform that's governed at compile time and serves internal BI and embedded analytics from one model — that's Cube, built on the open-source Cube Core.
Methodology
This explainer describes embedded analytics as the term is used in 2026, weighted toward the properties that matter when analytics ships inside a product for external customers: multi-tenant security enforced before query execution, query performance under concurrent load, metric consistency across surfaces, the build-vs-buy tradeoff, and the move toward an AI analyst embedded in the product. As the publisher, Cube builds a semantic layer and an agentic analytics platform that serves embedded analytics as one of two equally-weighted use cases, so we have an obvious interest here; we've tried to define the concept neutrally and be explicit about where Cube fits versus the broader category. Product-specific capabilities move quickly — treat them as version-dependent and confirm against current documentation.