The short answer: define the customer decision before the dashboard
Embedded analytics requirements should define the customer question, metric meaning, tenant and role scope, freshness, permitted exploration, product action, export behavior, performance target, and proof that the answer is correct and isolated. Choosing an iframe, SDK, chart library, or BI vendor comes after that contract.
Start with one decision a customer already makes from exports, support requests, or a separate reporting tool. Name the actor, question, action, minimum useful dimensions, and costly wrong answer. Then test the same view for a permitted user, a forbidden user, stale data, an empty state, a partial failure, and an export.
This guide scopes customer-facing analytics inside a product. Use the dashboard data-readiness checklist when source meaning and access are still uncertain, and the BI versus custom dashboard guide when the main decision is delivery model rather than product requirements.
Write a tenant metric contract for every first-release view
A metric name is not a specification. “Active users” still needs an actor, event or state definition, time zone, time window, inclusion and exclusion rules, grain, dimensions, late-data treatment, tenant boundary, role scope, freshness, display precision, and owner. Record examples that should count and should not count.
Add the product behavior: which filters persist, where drill-down ends, whether the user can compare periods, what an export contains, which in-product action follows, and how empty, loading, stale, restricted, and error states appear. The contract should remain understandable without seeing the chart.
Version the metric when a source, formula, dimension, default filter, access rule, or material display behavior changes. Decide whether historical values are recalculated, annotated, or preserved. Customers need to know whether a changed number reflects business activity, fresher data, or a definition change.
Define eight embedded analytics requirement lanes
| Lane | Decision to specify | Acceptance evidence |
|---|---|---|
| Decision and audience | Customer job, actor, frequency, next action, harmful wrong answer | A named user can complete one decision loop |
| Metric semantics | Formula, grain, dimensions, exclusions, time zone, owner | Examples reconcile to approved source records |
| Identity and isolation | Tenant, membership, role, entitlement, field restrictions, admin path | Allowed and forbidden cases hold across every surface |
| Data delivery | Sources, transformations, freshness, late data, lineage, backfill | As-of time and reconciliation are visible and testable |
| Interaction | Filters, drill-down, comparison, save, share, product action | State survives navigation and respects permissions |
| Presentation | Chart, table alternative, units, labels, responsive and accessible behavior | Users can understand the answer without color alone |
| Performance and scale | Load, query, concurrency, cache, rate, timeout, degradation | Representative tenants meet agreed service targets |
| Operations and exit | Monitoring, audit, content release, support, export, deletion, vendor exit | Failures and ownership are observable and recoverable |
Define freshness as a customer promise
“Real time” is not a useful default. Name the source event, expected ingestion delay, transformation schedule, cache age, displayed as-of time, late-arriving-data rule, backfill behavior, and what the product shows when the promise is missed. Some decisions need seconds; others are safer and cheaper with a verified daily snapshot.
Make tables, labels, and states first-class
A chart should not be the only way to obtain its meaning. Provide a clear title, units, date range, metric definition, accessible table or equivalent, keyboard path, focus behavior, and explanation of empty or unavailable data. W3C guidance says color must not be the only visual means of conveying information, and non-text content needs an appropriate text alternative when it conveys information.
Carry tenant and role context into every data path
Define what a tenant represents, how a user selects or changes tenant context, which membership and role authorize each view, and whether entitlements restrict metrics or history. Authorization must be enforced by the trusted server and data boundary—not by a visible filter, hidden navigation item, or browser-supplied tenant identifier.
Embedded platforms offer different controls. Microsoft documents row-level, object-level, and workspace-based approaches in its Power BI Embedded security guidance. Google’s Looker embedded security guidance warns that signed embed secrets should be protected like administrator credentials and that server-side session tokens should not be exposed to the browser. Treat these as implementation-specific controls behind your product requirement, not substitutes for an explicit authorization model.
Test charts, underlying tables, drill targets, search, caches, downloadable files, scheduled delivery, shared links, APIs, browser events, support impersonation, and administrator tools. A forbidden user must not infer restricted records through totals, labels, error messages, timing, metadata, or stale cached output. Pair the plan with the SaaS permissions requirements checklist when product authorization itself needs definition.
Draw the delivery boundary beyond the embed
Map product identity and tenant context, source systems, transformations, semantic model, query or embed service, caches, the product shell, exports, scheduled jobs, audit events, monitoring, and support access. For each boundary, name the identifier, credential, policy enforcement point, data classification, timeout, retry, observability, owner, and safe recovery.
Define the failure experience. If the analytics service is slow, the product might keep navigation available, show the last verified as-of time, preserve filters, offer a retry, and avoid claiming a partial result is complete. Monitor freshness lag, authorization failures, query latency, timeouts, cache errors, export failures, and schema changes by tenant and release without logging sensitive result data unnecessarily.
Choose buy, build, or hybrid by ownership
| Model | Best fit | Ownership you retain |
|---|---|---|
| Embedded platform | Broad governed exploration, dashboards, export, authoring, or scheduling | Product identity, tenant mapping, semantics, experience, testing, support, and vendor risk |
| Native product views | A few stable questions and actions tightly coupled to workflow | Data model, queries, visualization, accessibility, performance, operations, and evolution |
| Hybrid | Governed vendor analytics plus native high-value actions or summaries | A coherent semantic, authorization, navigation, and support contract across both |
Prototype the hardest slice before choosing. Use a representative large tenant, multi-membership user, restricted field, high-cardinality dimension, export, mobile viewport, slow query, and permission change. Evaluate licensing and capacity against actual viewer, author, tenant, concurrency, and data-volume assumptions; do not copy a generic cost estimate into the brief.
Leeonex’s analytics dashboard development service can help define metric and delivery boundaries, while portal and admin development is relevant when the analytics experience sits inside a broader customer or partner workflow.
Use this one-view release worksheet
- Decision: actor, question, frequency, next action, and harmful wrong answer.
- Contract: metric formula, grain, dimensions, exclusions, owner, and examples.
- Scope: tenant, membership, role, entitlement, fields, support, and administrator paths.
- Delivery: sources, transformations, freshness, cache, query limits, and failure state.
- Experience: filters, drill-down, table alternative, export, responsive behavior, and accessibility.
- Scenario pack: allowed, forbidden, multi-tenant, stale, empty, slow, partial, changed-permission, and deleted-data cases.
- Operations: dashboards, alerts, owner, runbook, content release, audit, rollback, and vendor exit.
Release when the view is trustworthy enough to influence the named decision and the team can detect and repair failure. A beautiful dashboard with unsettled meaning, porous scope, or no operational owner is not ready to embed.
Embedded analytics requirements FAQ
What should embedded analytics requirements include?
Include the customer decisions the analytics supports, metric and dimension definitions, source and transformation ownership, tenant and role isolation, authentication, freshness, latency and concurrency targets, filters and drill-downs, exports and sharing, accessibility, responsive behavior, product events, failure states, monitoring, support, content change control, data deletion, vendor exit, and acceptance scenarios.
Should a SaaS product buy or build embedded analytics?
Buy an embedded platform when governed exploration, dashboards, exports, and analytics administration are substantial product capabilities you do not want to recreate. Build focused native views when the questions and interactions are narrow and tightly coupled to product workflow. Use a hybrid when a vendor supplies governed analytics while native components handle the highest-value actions and context.
How do you test tenant isolation in embedded analytics?
Use automated and manual negative cases across dashboards, drill-downs, cached results, exports, scheduled deliveries, shared links, APIs, support impersonation, and administrator tools. Test a user with multiple memberships, changed permissions, removed access, guessed identifiers, and stale sessions. A forbidden record, aggregate, field, or metadata value must not appear in content or side channels.