Semantic Layer for Embedded Analytics: One Model, Many Customers, Controlled Visibility

When you embed analytics into your own product, the semantic layer is what lets you serve every customer from one governed model while controlling exactly what each tenant sees. This guide explains why multi-tenant embedded analytics needs a semantic layer, how per-tenant visibility works, and what to look for.

TL;DR

• Embedded analytics = analytics built into your own product for your customers to use, not internal dashboards.
• The multi-tenant problem: every customer must see their own data and only their own data, computed with consistent definitions — at scale, across many tenants.
• The semantic layer solves both: one governed model defines the metrics once, and row-level security controls which tenant sees which rows — from a single place.
• The alternative — rebuilding metrics and security per customer — doesn’t scale and invites the leak you can least afford: one tenant seeing another’s data.

Building analytics for your own team is one thing. Embedding analytics into a product your customers use is another entirely. Now the numbers aren’t just internal — they’re a feature customers pay for, and a single mistake means one customer seeing another’s data. The semantic layer is what makes embedded, multi-tenant analytics both consistent and safe: one model, many customers, and precise control over what each one sees.

What is embedded analytics?

Embedded analytics is analytics delivered inside your own application — dashboards, reports, and data experiences your customers interact with as part of your product, rather than internal BI your staff uses. A SaaS platform showing each customer their usage and performance, a marketplace showing sellers their sales, a logistics product showing shippers their shipments: all embedded analytics. The defining trait is that your users are external, and each one should see a view scoped to just them.

The multi-tenant challenge

Embedded analytics is almost always multi-tenant: many customers served from the same product and, underneath, often the same data infrastructure. That creates two requirements that pull in opposite directions if you build them by hand.

First, consistency: every tenant’s numbers should be computed the same way, so “active users” or “revenue” means the same thing for customer A and customer Z. Second, isolation: each tenant must see only their own rows — never another customer’s. Do these per-customer, and you’re maintaining N copies of your metric logic and N security configurations, where every new tenant is another chance to introduce an inconsistency or, far worse, a data leak.

How the semantic layer solves both at once

A semantic layer collapses those N copies into one. The metrics are defined once in the model, so every tenant’s dashboard computes “active users” identically — consistency comes for free. And row-level security, applied at the semantic layer, filters the data each user is allowed to see, so the same dashboard shows customer A only customer A’s rows and customer Z only theirs. One model, one set of definitions, one place to control visibility — serving every tenant.

This is the difference between embedded analytics that scales and embedded analytics that becomes a liability. When definitions and security live in the model rather than in per-customer configuration, adding your hundredth tenant is the same low-risk operation as adding your second. And because the security is enforced in the governed layer rather than bolted on in the application, the isolation guarantee is structural, not something a developer has to remember to re-implement on every new screen.

Why warehouse-native matters for embedded

For embedded analytics, running the semantic layer natively on your warehouse pays off twice. There’s no extracted copy of customer data sitting in a separate BI engine — a smaller attack surface and one less place for tenant data to leak. And because a warehouse-native layer inherits row-level security straight from the warehouse, the same tenant-isolation rules that protect your data everywhere else automatically protect what customers see in the embedded product. Governance you already trust, extended to your customers, without a second system to keep in sync.

Embedded analytics in practice: Elbiil

Elbiil builds a customer-facing analytics product — analytics its own customers log in and use. Rather than maintain a legacy BI stack, Elbiil embeds Astrato as its analytics layer, running natively on its data (with Supabase in the architecture) so each of its customers gets a governed view of their own data. Multi-tenancy — making sure every customer sees only their own data — is handled through that one governed layer rather than rebuilt per customer, and much of the product is assembled through no-code configuration rather than bespoke engineering.

The shape of the Elbiil story is the shape of the argument: one data layer, many customers, and control over exactly what each one sees. That’s the semantic layer doing the load-bearing work — letting a lean team ship a customer-facing analytics product without standing up separate metric logic and separate security for every tenant they serve.

How Astrato supports embedded analytics

Astrato is a warehouse-native BI platform with a built-in semantic layer designed for exactly this. Metrics are defined once and shared across every embedded view; row-level security is inherited from the warehouse, so tenant isolation is enforced in the governed layer; the model runs natively on your warehouse with no extracted copy of customer data; and dashboards and data apps can be embedded into your product and largely built through no-code configuration. One governed model, many customers, controlled visibility. See the Astrato semantic layer or book a demo.

Key takeaways

• Embedded analytics puts analytics inside your product for external customers — each should see a view scoped to just them.
• Multi-tenant embedded analytics needs both consistency (same definitions for every tenant) and isolation (each tenant sees only their own data).
• A semantic layer delivers both from one place: metrics defined once, row-level security controlling visibility per tenant.
• Building metrics and security per customer doesn’t scale and risks the worst leak — one tenant seeing another’s data.
• Warehouse-native execution means no copy of customer data in a separate engine and tenant isolation inherited from the warehouse — as Elbiil’s customer-facing product shows.

Frequently asked questions

Why does embedded analytics need a semantic layer?

Because embedded analytics is multi-tenant: you need every customer’s numbers computed consistently and each customer isolated to their own data. A semantic layer provides both from one governed model instead of per-customer configuration.

How does a semantic layer handle multi-tenancy?

Metrics are defined once so every tenant’s view is consistent, and row-level security applied in the layer filters each user to only the rows they’re allowed to see — so the same dashboard shows each customer only their own data.

Is embedding analytics safe for customer data?

It’s safest when tenant isolation is enforced in the governed semantic layer rather than re-implemented per screen, and when the layer runs natively on the warehouse so there’s no extracted copy of customer data in a separate engine.

Do I need to build each customer’s dashboard separately?

No — that’s the point of the semantic layer. You build one governed model and one set of embedded views; row-level security scopes what each tenant sees, so you don’t rebuild per customer.