Feature · Embedded Dashboards

Embedded dashboards your customers see, without a BI license per viewer.

An embedded dashboard shows analytics inside a surface the end user already uses: a customer portal, a partner page, a client-facing project workspace. The hard parts are not the charts; the hard parts are the authorization (the viewer sees only their data), the scoping (the embed knows which record it is on), the branding (the embed looks like the host product), and the pricing (no per-embed-user BI tax). Strkr ships embedded dashboards with record-scoping, permission-aware aggregation, white-label branding, and flat seat pricing on the internal user base.

Start free trial See pricing
What an embed has to cover

The seven things an embedded dashboard must get right.

Embedding a dashboard is 20% rendering and 80% getting the authorization, scoping, and branding right. The capabilities below are the ones that fail quietly in competitors and cause the project to roll back three months after launch.

Authorization

Viewer sees only their data.

The embed authorizes against the viewer's identity (customer, partner, employee). The dashboard aggregates data scoped to the viewer's record access. The common failure where "we hide the chart in CSS but the API returns everyone's data" does not happen because authorization is server-side.

Record scoping

Embed knows which record it is on.

The embed is parameterized on the record ID (customer ID, partner ID, project ID). The dashboard materializes with that record as the implicit filter. The same embed on 500 customer portals shows 500 different views without 500 copies of the dashboard.

Branding

Embed matches the host surface.

The embed renders with the host product's colors, fonts, and layout tokens. White-label mode strips any Strkr branding. The embed looks like a native part of the host product, not an iframe someone glued in. The common failure where "the dashboard looks like a Tableau widget inside our Nike-branded portal" does not happen.

Performance

Sub-second load inside the host.

The embed loads sub-second on first paint. Caching happens per-viewer with cache invalidation on the underlying data write. The common failure where "the dashboard takes 8 seconds to load and customers bounce" does not happen because the embed is designed for the viewer's latency budget.

Mobile

Embed renders on phone and tablet.

The embed renders responsively on phone, tablet, and desktop. Panels reflow, drill-through works on touch, and the mobile layout is not an afterthought. The common failure where "the dashboard looks fine on desktop but is unusable on an iPhone" does not happen because mobile is a first-class target.

Interactivity

Filters, drill, export inside the host.

Viewers can filter, drill to the underlying rows, and export to CSV from inside the embed. Interactivity does not require a redirect back to a Strkr product surface. The embed is a complete analytics experience, not a glorified screenshot.

Pricing

No per-embed-viewer meter.

Embeds do not meter per viewer. A portal with 10,000 customers viewing their own dashboard does not land on a per-viewer BI tax that makes the project uneconomical. Strkr embeds are included in the flat $50 per seat on the internal user base.

Where embeds differ

Six axes that predict embed project survival.

Embedded dashboard projects fail at a famously high rate. The axes below are the common failure modes. A buyer who evaluates on these axes avoids the "we built the embed and shipped it and three months later we rolled it back" outcome.

Auth model

Row-level vs app-level.

Row-level authorization lets the embed show one customer their data without any custom code. App-level authorization requires the host app to filter the data before passing it to the embed, which is custom work per embed. Row-level is the only sustainable model at portal scale.

Scoping

Parameterized vs one-per-customer.

Parameterized embeds take a record ID at load time. One-per-customer embeds require the admin to create 500 dashboards for 500 customers. The parameterized model is what makes portal scale work.

Branding depth

Theme tokens vs iframe wrapper.

Theme-token embeds render with the host product's design system. Iframe wrapper embeds show the vendor's UI inside a frame. The branding depth is what customers actually notice.

Interactivity

Filter and drill vs read-only PNG.

Interactive embeds let the viewer filter and drill without leaving the host. Read-only embeds are PNG-grade and viewers churn. The interactivity level predicts how often the embed gets used.

Caching

Per-viewer vs global.

Per-viewer caching keeps the embed fast for repeat views without leaking data between viewers. Global caching leaks data (or disables caching, which kills performance). The caching model matters at scale.

Pricing shape

Internal-seat vs per-embed-viewer.

Internal-seat pricing lets the ops lead ship embeds to 10,000 end viewers without a per-viewer BI tax. Per-embed-viewer pricing kills the economics of any customer-facing embed. The pricing shape is the single biggest driver of whether the project ships at all.

What Strkr ships for embedded dashboards

The embed surface, in detail.

Parameterized record-scoped embeds. Row-level authorization against the viewer's identity. White-label theming via design tokens. Interactive filtering, drill-through, and CSV export inside the embed. Per-viewer caching. Mobile-first layout. Flat $50 per seat on the internal user base with no per-embed-viewer meter.

Embed SDK

Drop-in JavaScript or iframe.

Embed via a drop-in JavaScript SDK (recommended, lets the embed share the host's layout flow) or iframe (fallback for low-trust surfaces). The SDK handles authorization, scoping, and theming via one init call. First embed ships in a day of integration work.

Row-level auth

Viewer sees their records only.

Authorization runs server-side against the viewer's identity. A customer sees their invoices. A partner sees their deals. An employee sees their quota. The host app passes a signed viewer context; Strkr enforces row-level access on the aggregation.

White-label

Colors, fonts, logo via tokens.

The embed accepts a theme token object: primary color, text color, font family, border radius, logo URL. The embed renders with the host's design system. White-label mode removes all Strkr marks. The embed looks native.

Record scoping

Record ID as implicit filter.

The embed is parameterized on a record ID. One embed on 500 customer portals shows 500 different views. The template is one dashboard, the materialization is per-viewer. No per-customer dashboard copy sprawl.

Interactivity

Filter, drill, export inside the embed.

Viewers filter by date, segment, or custom dimension inside the embed. Drill-through opens the underlying rows in a drawer. CSV export is one click. The embed is a complete analytics experience; the viewer never leaves the host product.

Mobile

Phone-first, touch-friendly.

The embed renders mobile-first with responsive panel reflow. Touch targets are sized for finger taps. Drill-through works on touch. The embed is designed for the end-viewer's device, which is usually a phone.

Where teams actually land

Three deployment patterns from real customers.

A SaaS with a customer portal, a services firm with a client workspace, and a healthcare company with patient-facing dashboards each run embedded dashboards. The embed engine is shared; the scoping and branding flex to the business.

SaaS pattern

Customer portal shows usage, invoices.

A 90-seat SaaS runs embedded dashboards in the customer portal. Each customer sees usage trends, open invoices, support tickets, and the account health score. The portal has 8,000 end viewers; the dashboard embed cost is $0 marginal (flat seat on internal users).

Services firm

Client workspace, project status.

A 200-seat services firm embeds project dashboards in a client workspace. Each client sees their project burndown, deliverables, open issues, and budget vs actual. The dashboard matches the client's portal branding and the data is scoped to the client's projects only.

Healthcare pattern

Patient portal, PHI-safe aggregation.

A 300-seat healthcare company embeds patient dashboards in the patient portal. Each patient sees their appointments, test results trend, and care plan progress. The aggregation respects HIPAA; a patient sees only their records, enforced server-side with a signed BAA.

Partner pattern

Partner portal, deal registration.

A SaaS with a partner channel embeds partner-facing dashboards in the partner portal. Each partner sees their registered deals, closed revenue, and commission earned. The partner cannot see other partners' data; row-level auth enforces the boundary.

Multi-tenant pattern

Reseller sees aggregate, end customer sees self.

A reseller sells to end customers. The reseller sees aggregate usage across all their end customers. Each end customer sees only their own usage. One embed, two authorization contexts (reseller and end customer), zero code at the host.

Exit posture

Embed templates portable via API.

The embed template, the theme tokens, and the auth configuration are accessible via the open API. A team that migrates can export the full embed schema and reinstate it elsewhere. The exit cost is measurable.

Embed dashboards without the per-viewer BI tax.

Strkr embedded dashboards ship with row-level auth, record scoping, white-label theming, and interactive drill-through. Flat $50 per seat on your internal users; no per-embed-viewer meter.

Start free See pricing
Common questions

What buyers ask about this feature.

How do embedded dashboards differ from regular dashboards?

Regular dashboards render inside the vendor's product surface for the vendor's users. Embedded dashboards render inside the host product (a customer portal, a partner page, a client workspace) for the host product's end viewers. The hard parts of an embed are authorization (the viewer sees only their data), scoping (the embed is parameterized to the right record), branding (the embed matches the host surface), and pricing (no per-embed-viewer meter). Strkr covers all four so an embed to 10,000 end viewers is economically sensible.

How does row-level authorization work?

The host app passes a signed viewer context (viewer ID, scopes, record access rights) to the embed on load. Strkr enforces row-level access server-side on the aggregation: a customer sees only their records, a partner sees only their deals, an employee sees only their team. The common failure where "we hid the chart in CSS but the API still returned everyone's data" does not happen because the enforcement is on the server, not the UI.

Can we white-label the embed to match our product?

Yes. The embed accepts a theme token object (primary color, text color, font family, border radius, logo URL) that overrides the default Strkr theme. White-label mode removes all Strkr marks from the embed surface. Customers see the embed as a native part of your product, not as a Strkr widget inside your product. Theme tokens are the first-class white-label mechanism, not an iframe wrapper.

What about performance on a portal with thousands of viewers?

The embed uses per-viewer caching with cache invalidation on the underlying data write. First-paint is sub-second for the typical dashboard. A portal with 10,000 end viewers gets the same embed performance as a portal with 10, because the caching tier scales linearly. If the embed sits behind a CDN, cache hit rates typically run above 85% on viewer-stable panels.

How is this priced if we embed for 10,000 end viewers?

Strkr pricing is flat $50 per seat on the internal user base (your employees who build and manage the dashboards). End viewers are not seats and are not metered. A portal with 10,000 end viewers viewing their own data costs the same as a portal with 10 end viewers. This pricing shape makes customer-facing embed projects economically sensible, which is the opposite of per-embed-viewer BI pricing that kills the project before launch.

Is the embed HIPAA-compliant for patient-facing dashboards?

Yes. Strkr is HIPAA-compliant with Business Associate Agreements available for regulated tenants. Patient portal embeds route through the compliant audit path. The row-level authorization ensures a patient sees only their own data; the aggregation respects HIPAA permissions server-side. SOC 2 Type II audit is in progress; Type I report is available on request. GDPR and CCPA compliance are also in place.

Related features

Pair this with...

Dynamic Dashboards CRM Dashboard Dashboard Platform Dashboard Apps Dashboard Software Dashboard Reporting Software Business Performance Dashboard

Try it free. Bring your team next week.

No sales call, no migration consultant, no four-month implementation. Enter your card, get 14 days of the full Pro tier, cancel any time before day 14 with zero charge. Spin up a workspace, import your CSV, and have something useful before lunch.

Start free trial See pricing