What Is Embedded Reporting? The Five Report Forms, the Layers Behind Them

What Is Embedded Reporting?

A customer asks for their monthly usage report, and the product team ships a dashboard with twelve filters. Teams have come to us after exactly that mismatch, and it usually means the wrong system was scoped before anyone wrote code.

Embedded reporting is customer-facing reporting delivered inside or from a software product. Each report answers a question that was asked in advance: its metrics, structure and audience are fixed before anyone opens it. What separates it from embedded analytics is purpose, not export format. Analytics lets the user ask a new question now. The two overlap, since a fixed KPI dashboard every tenant sees is both, and neither is a subset of the other. Embedded reporting shows up in several overlapping forms: scheduled subscriptions, paginated and exported documents, fixed in-product and operational report pages, narrative insight summaries, and interactive reports. Scheduled and exported forms render without a logged-in session, so per-tenant access has to be enforced below the presentation layer.

The boundary is clearest at the edges. An in-product "Monthly Usage Report" page is reporting even if nobody ever exports it, because the question was settled before the tenant logged in. An exploratory query builder (the kind Metabase Embedded does well) is analytics even when the user saves the view, because the user framed the question. A fixed KPI dashboard shown to every tenant sits in both. The delivery channel, whether in-product page, export, email or API, tells you how a report travels, not what it is.

"Embedded" means either one lives inside your own product rather than in a separate business intelligence (BI) tool. We cover the neighbouring definition of embedded analytics on its own page.

So the two overlap at the fixed dashboard and part on purpose. A report answers a question that was asked in advance; analytics is the reader asking now. That's why reporting reaches forms analytics never produces, and analytics reaches questions no report anticipated.

Why Embedded Reporting Got Folded Into Embedded Analytics, and What That Hides

The equivalence comes from who writes about the category. It isn't a fact about the work.

Most explainers are written by vendors that sell dashboards, so they describe dashboards and call the result reporting. That's understandable, but it quietly drops the forms enterprise customers actually ask for. The first is the scheduled Monday email with last week's numbers. The second is the PDF the finance team files, sometimes as PDF/A (the ISO 19005 archival format) because auditors want the document unchanged years later (PDF Association). The third is the usage summary a customer forwards to their boss before renewal. Nobody clicks a filter in any of them.

Teams have come to us with exactly these requests after they'd already shipped a dashboard.

This isn't an argument that reporting is the parent category, or that analytics is. They overlap, and neither contains the other.

It's an argument about scoping. The "reporting equals analytics" framing is inherited from the pages answering the question, not from the work itself. Accept it, and you'll scope a dashboard when the customer asked for a report. You'll find the difference when the first scheduled send has to run with nobody logged in.

The Five Common Forms of Customer-Facing Report

A customer success manager forwards a ticket: "Our biggest account wants a usage report." That sentence could mean five different builds. The account's finance lead might want a file in her inbox on the first of every month. Their ops team might want a page in your app they check every Monday. Their CEO might want three sentences explaining why seat usage dropped.

Same word. Different system.

We use the taxonomy below as a working guide. It isn't an exhaustive standard, and the forms overlap (a fixed in-product page often carries an export button), but in our experience most requests land mainly in one of them:

• Scheduled or subscription reports: the customer receives a report on a cadence, by email or another channel, without logging in. Signalled by "every week", "send it to", or "can our board get this monthly?"
• Paginated and exportable documents: a fixed-layout file in portable document format (PDF), Excel spreadsheet (XLSX) or comma-separated values (CSV), built to print, archive or hand to an auditor. Microsoft's paginated reports documentation captures the defining trait: layout that renders predictably across pages. Signalled by "download", "print-ready", or "for our auditors".
• Fixed in-product and operational reports: a page every tenant sees inside your product, such as a Monthly Usage Report, with the same metrics and structure for everyone and data scoped to each tenant. Signalled by "a reports tab" or "somewhere they can check".
• Narrative or written insight reports: prose instead of charts, including AI-generated summaries and alerts that explain what changed. Signalled by "just tell them what happened" or "flag it when".
• Interactive reports: a defined report the reader can filter, drill into or re-slice; this is where reporting and analytics meet. Signalled by "let them dig in" or "filter by region".

Here's why the distinction pays off. A scheduled report needs a job runner and fires with no user session behind it. A paginated export needs deterministic layout and puts heavy reads on your data. A narrative summary is only as trustworthy as the metric definition underneath it. An interactive report needs scoping at query time, on every click. Scope any of these as "add a dashboard" and you've committed to the wrong infrastructure.

So before you scope anything, name which of the five forms you've actually been asked for. Each one is a different engineering problem wearing the same word.

How Embedded Reporting Works: The Layers Behind a Report

An embedded report sits on five layers: a data source and connection; a governed layer for metric definitions, permissions and query constraints (a role often played by the semantic layer); a rendering and report-definition layer; an embedding mechanism; and a delivery and export mechanism.

The embedding mechanism is usually an iframe, a software development kit (SDK) or web component, or an embed API. We've already compared the four ways to embed analytics into your app, so we won't repeat the trade-offs here. Dashboards as code isn't on that list. It's a development workflow for report definitions (version control, review, continuous integration (CI)), and it sits upstream of whichever mechanism you choose.

The layers matter because each form uses them differently. A scheduled subscription needs a job runner and delivery guarantees: retries, idempotency so nobody receives the same monthly summary twice, and a record of what was sent to whom. A paginated export needs deterministic layout, which is genuine engineering work: page breaks that don't split a table row, headers that repeat, and totals that land on the right page. When every tenant exports at month end, that read load hits your warehouse at the same time. A narrative report needs stable metric definitions, because a written summary saying active users rose is only as trustworthy as the definition of "active" behind it. Interactive reports need query-time scoping, because every filter and drill-down creates a new query that has to respect the viewer's tenant.

Reporting doesn't need to be real-time. A report answers a question decided in advance, so scheduled or batch delivery is legitimate and often the better choice. It lets you run heavy queries off-peak, and it gives the customer a number that won't change while they're reading it. We'd push back on any scope that treats freshness as the default requirement without asking which form it's for.

Take this point into scoping: the form of report you agree to ship determines the infrastructure you've committed to. None of that commitment is visible in the demo.

Where Per-Tenant Access Has to Be Enforced in Embedded Reporting

A common failure mode looks like this. A tenant's finance lead subscribes to the monthly usage report. At 6am a background job renders the PDF, queries the warehouse and emails it out. Nobody is logged in. The tenant filter lived in the front end, where it was read from the user's session, so the job's query ran without it and the PDF carried every customer's rows.

Nothing in the report looked broken. That's what makes it dangerous.

Interactive views hide this flaw because a person is always present. A session exists, the UI reads the tenant from it, and the filter gets applied. Asynchronous forms remove the person. Scheduled emails, bulk exports and PDF endpoints run as service processes, and a service process doesn't inherit the browser's idea of who's asking. The OWASP Application Security Verification Standard (ASVS) already requires access control to be enforced on a trusted server-side layer rather than the client. Reports simply make the consequence land in someone's inbox.

So in a multi-tenant architecture, we put tenant isolation below the presentation layer: at the data, semantic, query or governed runtime layer. Row-level security (RLS) and access policies do this when they're correctly applied to the relevant tables or views, because they constrain the query itself, whichever surface issued it. For isolation at the database level, environments can route each tenant to its own database connection: single-tenancy on your databases, not ones we host.

Identity still has to reach a render that has no session. Single sign-on (SSO) authenticates the human, but it can't vouch for a 6am job. The usual answer is a short-lived scoped embed token: a signed JSON Web Token (JWT), as defined in RFC 7519, that carries the tenant and role claims the governed layer enforces and expires quickly, which shrinks the window in which a captured token could be replayed; preventing reuse outright takes further controls — Transport Layer Security (TLS) in transit and, where it matters, single-use token identifiers the server remembers.

If the UI is your only tenant boundary, every asynchronous report form you ship leaks the first time a schedule fires — nothing below the presentation layer is checking.

Versioning and Promotion: What Makes Embedded Reporting a System Rather Than a Feature

A report definition is never finished. It changes every time someone renames a metric, adds a column or tightens a filter.

A common failure mode looks like this. Someone fixes a label on the "Monthly Usage Report" directly in production, the underlying query changes shape, and every tenant's scheduled PDF goes out on the first of the month with a broken total. Nobody reviewed the change, because there was nothing to review. Nobody can say which version a given customer received last quarter, either. That second gap matters most to data leads: auditability means answering "what did this customer see, and under which definition?" long after the fact.

The fix comes from software engineering. Keep report definitions in Git, review them in pull requests, and promote them from staging to production the way you'd ship any other code. That needs a runtime that separates environments, so you can test a change against staging data before it reaches a live schedule or export. In Embeddable, you save dashboard versions and promote them through a staging environment before they reach production — environments (prod, staging, QA) map the same data models to different connections; versions let you pin what's live and roll back.

Here's our position. A reporting layer becomes a production system at the point where report definitions are versioned and promoted like code, not edited live in a customer's tenant. Before that point, you're running a feature that's one unreviewed edit away from its first bad schedule.

The Drawbacks of Embedded Reporting Nobody on This Topic Writes About

Embedded reporting has costs that don't show up in the demo. They arrive after launch, once real tenants start saving, scheduling and exporting.

The first is sprawl. Every customer who can save a report eventually will, and before long you're looking at "Usage v2 final", "Usage v2 final (Q3)" and a copy someone made because they couldn't find the original. Each one carries its own filters and, often, a slightly different idea of what an active user is. Versioning keeps your definitions clean; it doesn't stop customers cloning them. Someone still has to decide which saved reports are canonical, and that's ongoing product work, not a launch task.

The second is export load. A schedule that fires on the first of the month fires for every tenant at once, and each PDF or CSV (comma-separated values) file is a full query against your warehouse. On a platform like Google BigQuery, where on-demand queries are billed by bytes processed, that burst shows up on the bill and in query latency for everyone else. Staggering, caching and pre-aggregation all help, but somebody has to build them.

Then there's maintenance. A definition change has to be checked against every tenant's saved reports and schedules, not just the default. And because we think definitions belong in code, non-technical teams can't tweak a report themselves; they file a ticket.

We'd still ship it. Reporting gives customers a consistent answer, delivered where they already work. But a team that hasn't budgeted for sprawl and export load will meet those costs anyway, just later and less prepared.

An Evaluation Checklist for Customer-Facing Reporting

Every vendor can write a benefit list, so a benefit list tells you nothing. Put these questions to any vendor, or to your own build plan, and ask to see each answer working.

• Which report forms are native? Name the forms you actually need, then ask which ship out of the box and which you'd build on an endpoint. Partial native coverage is normal. Discovering the gap after signing isn't.
• Where is tenant scope enforced? Look for per-tenant access policies applied below the presentation layer. Check that a scheduled or exported report resolves scope without a logged-in session, typically through a short-lived, scoped JSON Web Token (JWT, RFC 7519).
• How are definitions versioned and promoted? You want environment promotion from staging to production, plus saved versions you can roll back to without breaking a customer's report.
• What happens to export load? Ask which queries a thousand PDFs trigger, and which database absorbs them.
• Is self-serve governed? A self-serve canvas should let users explore without redefining metrics or crossing permissions.
• How are theming and white-labelling handled? They should live in code, not in a settings screen you'll outgrow.

Here's how we answer the list ourselves. Interactive reports and on-demand, per-chart export to CSV, XLSX and PNG are native, and a dashboard export API (in beta) renders a published dashboard to PDF server-side. Scheduled delivery is your build around that endpoint; we don't schedule it for you, and we don't claim paginated or narrative reports. Underneath sit row-level security, access policies, saved dashboard versions and environments, which route each tenant to its own database connection — single-tenancy on your databases, not ones we host. Embeddable handles the infrastructure. You own the experience.

Evaluate on demonstrated capability against the forms you need, not on benefit lists. Our customer stories show what that looks like in production.

Related Reading

• Customer Facing Analytics
• Embedded Dashboards
• Dashboards as Code
• Financial Reporting Dashboard
• Semantic Layer for AI Agents