Embedded Analytics: Delivering BI Inside Your Product

Embedded analytics is the practice of delivering analytical capabilities — dashboards, charts, data exploration — inside another application rather than in a standalone BI tool. A SaaS platform that shows each customer their usage metrics. An ERP that has financial dashboards built in. A marketplace that shows sellers their performance data. The analytics is part of the product experience, not a separate tool users have to navigate to.

Embedded analytics has become a significant differentiator in B2B SaaS. Products with strong in-product analytics see higher engagement, lower churn, and higher expansion revenue than products where analytics is an afterthought. Understanding the architectural options — and the tradeoffs between them — is essential for product teams and data architects making the build vs buy decision.

Why Embedded Analytics Is Different from Internal BI

Internal BI is built for a known audience of trained users who accept a learning curve, work within the organisation's security model, and have relatively homogeneous analytical needs. The governance challenges are real but bounded — you are deploying to hundreds or thousands of internal users with known roles.

Embedded analytics serves a fundamentally different context:

- **External users**: customers or partners who have no tolerance for learning a BI tool — the analytics must be immediately understandable

- **Multi-tenant data isolation**: each customer sees only their own data, with zero leakage risk between tenants

- **Scale**: potentially tens of thousands of external users across hundreds or thousands of customer tenants

- **Brand alignment**: the analytics should look like your product, not like a BI vendor's product

- **Performance SLAs**: slow dashboards in your product are a product failure, not an analytics team problem

These differences make internal BI tools (Tableau, Power BI, Looker deployed as standalone) a poor fit for customer-facing embedded analytics. They are designed for the wrong audience, with the wrong security model, at the wrong price point for per-user external deployment.

Architecture Option 1: White-Label BI Platform Embedding

Several BI platforms offer embedding capabilities — rendering their dashboards inside a host application via iframe or SDK, with the host application controlling authentication and data access.

**Tableau Embedded Analytics**: Tableau workbooks can be embedded via the Tableau Embedding API v3. The host application authenticates users using Connected Apps or trusted tokens, applies user-specific data filters (row-level security via user attributes or Tableau Server's permission model), and renders the workbook in an iframe or via the Embedding API JavaScript framework.

**Sigma**: a cloud BI tool with a strong embedding SDK, popular for SaaS embedded analytics because of its low learning curve for end users and API-first architecture.

**Looker**: strong API and embedding capabilities; Looker's embedding is particularly powerful for organisations that want to expose Looker Explore as a self-service analytics experience to end users.

**Metabase**: open-source BI tool with iframe and signed embedding for public embedding without authentication.

Tradeoffs of white-label BI embedding:

- Faster to deploy than building from scratch

- Analytics capabilities are rich (complex charts, drill-down, data exploration)

- Customisation is limited to what the vendor allows (colours, fonts, hide certain UI elements)

- Pricing is per user or per embed — can be expensive at scale

- The underlying platform's limitations become your limitations

Architecture Option 2: Custom Visualisation with a Headless BI Backend

A headless BI backend (Cube.dev, Metriql, dbt Semantic Layer, or a custom implementation) exposes metrics and dimensions as an API. A custom frontend uses visualisation libraries (Chart.js, D3.js, Recharts, Highcharts, Observable Plot) to render charts from API responses.

This approach gives complete control over the visual output and removes dependency on a BI vendor's embedding limitations. The cost is development effort — building and maintaining chart components, data exploration interfaces, and filter logic.

When to choose this approach:

- You need pixel-perfect control over the analytics UI to match your product design system

- The analytics UI is complex enough that off-the-shelf components would require more work to customise than building from scratch

- You have frontend engineering capacity and want to own the full stack

- You are building a product where analytics is deeply integrated with the core application logic (not just dashboards in a modal)

**Headless BI with Cube.dev**: Cube.dev is a semantic layer that sits between your data warehouse and your frontend. You define data models (measures, dimensions, relationships) in Cube, and Cube exposes a GraphQL/REST API that your frontend queries. Cube handles query generation, caching, multi-tenant data isolation, and pre-aggregation for performance.

Architecture Option 3: Direct Warehouse Query with Component Library

The simplest embedded analytics architecture: the frontend queries the data warehouse directly (or through a thin API layer), and visualisation components render the results. No semantic layer, no BI platform.

This works for simple cases — a handful of pre-defined charts that show the customer their own data. It breaks down quickly at scale: warehouse query performance is inconsistent, multi-tenant security must be implemented entirely in the query layer, and each new chart requires a custom query.

For early-stage products where embedded analytics is limited to a few summary metrics, this is a reasonable starting point. Plan to evolve toward a semantic layer or BI embedding platform as the analytics requirements grow.

Multi-Tenant Data Isolation

The most critical security requirement in embedded analytics is ensuring that each customer sees only their own data. A data leak — customer A seeing customer B's data — is a catastrophic product failure.

Multi-tenant isolation implementation depends on the architecture:

**Row-level security in the warehouse**: a security policy on the data model filters rows by tenant ID, and the tenant ID is injected from the application session. Every query runs through the security policy regardless of how it is constructed.

**Separate schemas or databases per tenant**: each tenant's data is physically isolated in a separate schema or database. Simpler to reason about but operationally expensive for large numbers of tenants.

**Application-layer filtering**: the API layer enforces tenant isolation by injecting tenant filters into every query. Reliable only if there is no way for users to submit arbitrary queries.

**JWT-embedded tenant context**: the BI platform's embedding mechanism injects the tenant ID into the dashboard's data context via a signed token, and the data model enforces the tenant filter.

For production embedded analytics, row-level security in the warehouse or equivalent is the safest pattern — it ensures isolation even if there are bugs in the application layer.

Performance Architecture

Embedded analytics serves end users with low patience. A chart that loads in 5 seconds fails the product experience. Performance architecture for embedded analytics:

**Pre-aggregation**: compute and cache common aggregations (daily/weekly/monthly rollups by tenant) rather than aggregating at query time. Cube.dev's pre-aggregation feature, Snowflake's materialized views, and custom materialization in dbt all support this.

**Tenant-specific caching**: cache query results per tenant. Most tenants will make the same queries (their own dashboard); caching avoids redundant warehouse queries.

**Connection pooling**: warehouse connections have startup cost. Pool connections for the analytics API to avoid cold-start latency on each query.

**Progressive loading**: render partial results immediately and fill in details progressively. A dashboard that shows summary metrics instantly and loads drill-down detail on demand feels faster than one that blocks until all data is loaded.

For product teams building embedded analytics and data architects designing the supporting infrastructure, our Tableau consulting and data architecture consulting practices cover embedded analytics design — contact us to discuss your requirements.

A former Microsoft data architect audits your data foundation, identifies your top priorities, and sends you a written plan. Free. No pitch.