What Is Embedded Analytics?

Your users log in. They see dashboards.

Not dashboards in a separate tab. Not dashboards behind another login. Dashboards inside your product, with your navigation, your branding, and your access controls. A customer opens your app and the data lives where the work happens.

That is embedded analytics. Not a product feature description. A user experience.

Most SaaS products ship with zero analytics. The ones that do ship analytics build something from scratch, burn six months of engineering time, and end up with ten static charts nobody uses. The alternative is a dedicated BI tool that requires a separate login. Your customers skip it. Churn follows.

Embedded analytics solves both problems. You get battle-tested charting, filtering, and drilling from a mature BI engine. Your users get dashboards that feel native. Same URL. Same session. Same product.

Think about the alternative. Your customer logs into your app to check performance. They need a revenue breakdown by region. They open a new tab, navigate to a separate BI tool, log in again, hunt for the right dashboard among every report your company built, and apply the same date filters they already set in your app. Half your users never make it past the second login. The other half get the wrong dashboard and email support.

Now imagine the opposite. Your customer opens your app. The dashboard loads on the landing page. Date range pre-filtered to their last session. Revenue split by their regions. Drill down to transactions with one click. Export to PDF for the board meeting. They never leave your product. They never think about analytics as a separate activity. The data just exists where they need it.

That gap between the two experiences determines whether your customers renew.

Build versus buy: the real numbers

C-levels love the build option. Engineering leadership always estimates three months. Actual delivery takes nine. Sometimes twelve. The spreadsheet misses maintenance, which runs two to four engineering hours per week per customer after launch. It misses feature requests. It misses the moment your largest customer asks for a chart type your custom renderer cannot produce.

Here is the arithmetic for a team of three engineers at $150,000 salary, with full overhead at $200,000 each. Nine months to ship equals $450,000. Add two years of maintenance at 25% of one engineer and you cross $550,000 before anyone asks for an export button, a PDF download, or a date-range filter that works across time zones.

Metabase Open Source costs zero dollars to license. You pay infrastructure and the engineer who wires it into your product. Most teams we work with ship an embedded Metabase integration with row-level security in four to six weeks. Two engineers, part-time. Under $60,000 in labor.

The build option wins when your requirements are static and trivial. Three charts. No filtering. No drilling. No exporting. If that describes your product, build. For everyone else, the time you spend on custom charting you do not spend on your core differentiator.

One more thing the spreadsheet misses: your engineers leave. The developer who built the charting system takes a job somewhere else. The next hire reads the codebase for two weeks, ships a bug fix, and introduces three new edge cases. Custom charting systems accumulate technical debt faster than any other component in a SaaS product because the requirements change with every enterprise customer who signs a six-figure contract.

We wrote a full breakdown in The True Cost of Building Analytics In-House.

Self-hosted BI versus SaaS BI for embedding

Three tools dominate the embedded analytics conversation: Metabase, Grafana, and Apache Superset. Each takes a different stance.

Metabase ships as a single JAR file. You run it on your infrastructure, point it at your database, and embed dashboards with signed URLs. The question interface lets non-technical users ask questions in plain English. The embedding API handles iframe signing, parameter passing, and appearance customization. Metabase Cloud exists but most teams self-host for data residency and cost reasons. Open Source edition covers embedding for free.

Grafana excels at time-series data and real-time monitoring. Its embedding support is solid but its mental model assumes an operator audience. Dashboards feel like dashboards, not product features. If your users monitor infrastructure or IoT telemetry, Grafana fits. If they analyze business metrics, the UX fights you.

Superset offers the most flexible charting library and a powerful SQL editor. It requires more setup and Python knowledge. The embedding story works but demands more configuration than Metabase. Teams that need custom visualization types and have data engineering resources often choose Superset.

We compared all three in detail in Metabase vs Grafana vs Superset.

The self-hosted-versus-SaaS question comes down to three factors. Data residency: does the data need to stay in your VPC? Latency: does the BI engine need direct database access? Cost: SaaS BI pricing scales with user count and query volume in ways that self-hosted infrastructure pricing does not. For most SaaS teams embedding analytics into a multi-tenant product, self-hosted wins on all three.

The security model that makes embedding work

Embedding a dashboard means your users load an iframe. That iframe must show each user their data and no one else’s. If Tenant A sees Tenant B’s revenue, you lose the customer and the business. The security model needs four layers.

Signed embedding tokens. The BI engine generates a cryptographic token that authorizes one dashboard view. The token embeds parameters: which dashboard, which tenant, which role. It expires. The engine verifies the signature on every request. No valid token, no dashboard. You generate these tokens server-side, never in the browser.

Row-level filtering. The token passes a tenant ID or user attribute to the BI engine. The engine applies that filter to every query. A dashboard showing “revenue by region” runs as SELECT ... WHERE tenant_id = ?. The filter lives in the data layer, not the UI. No JavaScript manipulation can bypass it.

Tenant isolation through database design. Multi-tenant SaaS products should enforce isolation at the database level. Separate schemas per tenant. Separate databases per tenant at larger scale. The BI engine connects with credentials scoped to each tenant’s data. Shared-table architectures require the BI engine to enforce isolation through query rewriting. More moving parts. More risk.

Network boundaries. Run the BI engine inside your VPC. Do not expose it to the public internet. Your application server proxies requests and attaches tokens. The BI engine talks to the database over private subnets. Every component stays behind the same firewall.

For a step-by-step walkthrough, see How to Embed a Metabase Dashboard.

When embedded analytics is the wrong answer

Some teams should not embed analytics. You might be one of them.

Your customers do not ask for dashboards. Shipping features nobody requested wastes engineering time and clutters your product. If your support queue contains zero requests for reporting, reports are not the problem.

Your data lives in twenty silos with no warehouse. Embedding analytics on top of operational databases works for moderate query loads. It fails at scale when complex joins hit production tables during peak traffic. You need a read replica at minimum. A data warehouse with modeled tables is better.

Your product has fewer than ten customers. At this stage you need usage data to guide product decisions. You do not need customer-facing analytics. Wait until customers ask for it. Build it when churn risk ties to reporting gaps.

Your team cannot maintain a BI instance. Self-hosted BI requires someone who understands the database, the BI tool’s upgrade path, and the embedding API. That person needs maybe four hours per week after the initial setup. If your team runs at full capacity with no operational slack, SaaS BI with a managed hosting layer costs more but demands less from your engineers.

You need pixel-perfect control of every chart. Embedded BI gives you functional dashboards with branding customization. It does not give you a designer’s canvas. If your product requires custom visualization types that no BI tool supports, build a rendering layer on top. Just know that choice costs six figures and nine months.

How we ship embedded analytics at Cloud Intelligence

We deploy self-hosted Metabase inside the client’s infrastructure. No data leaves the VPC. The Metabase instance connects to existing PostgreSQL databases through read replicas. We configure row-level permissions that map to the client’s tenant model. The dashboards embed into the client’s web application via signed iframe URLs. Users authenticate through the client’s existing auth system and never see a Metabase login screen.

The Crossroads Health engagement illustrates the model. CRH processes healthcare credit balance transactions across hundreds of hospital clients. Each client needed real-time visibility into their data inside a HIPAA-compliant portal. We deployed Metabase on CRH’s infrastructure, configured row-level security by tenant, and embedded the dashboards into a white-labeled Provider Portal. Status inquiry calls dropped 90% in the first month. Account managers reclaimed half their working time. Client retention hit 100% since launch.

The pattern repeats across industries. Subscription retail. Logistics. Fintech. The technology stack stays consistent: PostgreSQL for the source, Metabase for the BI layer, signed JWT tokens for the embedding handshake, and the client’s auth system for session management. The business outcomes vary by domain but the architecture does not.

What ships in month one

A typical embedded analytics deployment follows a tight timeline.

Week one: Schema audit. We map the client’s database, identify the tables that drive key metrics, and design the query layer. Read replicas go up if they do not exist.

Week two: Metabase deployment. Docker container inside the VPC. Database connections configured. Initial dashboards built against the query layer. Row-level filters wired to tenant attributes.

Week three: Embedding integration. Your application server generates signed tokens. The frontend renders iframes with passed parameters. We match your branding: colors, fonts, logo. The dashboard looks like a native page.

Week four: Security hardening. Token expiry tuned. Network boundaries verified. Load testing against production query patterns. Documentation for your engineering team.

By week five, your customers log in and see dashboards. No separate tab. No separate login. Just data, inside your product, right where the work happens.

Dig deeper:

• Metabase vs Grafana vs Superset — which open source BI tool fits your embedding use case
• How to Embed a Metabase Dashboard — JWT signing, RBAC, and iframe hardening
• The True Cost of Building Analytics In-House — why building from scratch costs 3-5x what teams budget