Embedded Analytics: Adding Dashboards to Your Product Without Building a BI Tool

Last updated: August 2025

What Embedded Analytics Actually Means

Your SaaS customers want to see their data. Usage analytics, performance trends, billing summaries - they don't want to export CSVs or log into a separate BI portal. They want charts inside your product, loading in under 3 seconds, showing only their data. That's embedded analytics: taking dashboards built in a BI tool and rendering them inside your application's UI as if they were native components.

The alternative is building your own charting from scratch with D3.js, Chart.js, or Recharts. That works for simple visualizations, but the moment customers want filtering, drill-down, date range comparisons, or export-to-PDF, you've accidentally started building a BI tool. Embedding an existing one saves 6-18 months of engineering.

When to Embed vs When to Link Out

• Embed when the dashboard is part of the core product experience. Customers should feel like they never left your app. The BI tool's chrome (toolbars, logos, navigation) should be invisible.
• Link out when analytics is a secondary feature and speed-to-ship matters more than UX polish. A "View your analytics in Tableau" button works for internal tools or early MVPs.

Most production SaaS products embed. The link-out approach signals "we didn't invest in this" to customers paying for your platform.

Tool Options for Embedded Analytics

Architecture Decisions

Iframe Embed vs API-Driven

Iframe embedding is the faster path. Your front-end renders an <iframe> pointing to the BI tool's embed URL. The BI tool handles all rendering inside the frame. Setup takes hours, not weeks. The downside: limited control over styling, event handling, and interaction between the embedded dashboard and your app's UI.

API-driven embedding uses the BI tool's JavaScript SDK to render visualizations directly in your DOM. You get full control: custom themes, programmatic filtering based on your app's state, event listeners for user interactions, and tighter visual integration. Power BI's JavaScript embed library and Looker's Embed SDK both support this pattern. The trade-off: more front-end code to write and maintain.

Start with iframes to prove the concept. Migrate to API-driven when customers ask for deeper integration.

Row-Level Security Per Tenant

This is the non-negotiable requirement. Tenant A must never see Tenant B's data. Implement RLS at two layers:

1. BI tool layer: Define RLS roles in the dataset/model. In Power BI, create roles with DAX filters like [tenant_id] = USERNAME(). In Looker, use access_filter in LookML.
2. Warehouse layer: Use Snowflake's row access policies or database views filtered by tenant_id. This is your safety net. Even if the BI tool's RLS is misconfigured, the warehouse won't return unauthorized rows.

Never rely solely on the BI tool's security. A single misconfigured embed token or a forgotten RLS role and you've got a data breach. Defense in depth. Always. For comprehensive approaches to securing analytics data, see our data access control strategies guide.

Caching Strategy

Embedded dashboards face a unique performance constraint: multiple tenants hit the same reports simultaneously, but each sees filtered data. Without caching, every page load triggers a fresh query against the warehouse.

• BI-layer caching: Power BI caches query results in memory within the capacity. Looker has a configurable caching layer per Explore.
• Pre-aggregation: Build summary tables per tenant in the warehouse. A pre-aggregated "monthly_usage_by_tenant" table loads in 200ms instead of scanning raw events for 8 seconds.
• CDN/edge caching: For dashboards with static or slowly-changing data, cache the rendered output at the CDN layer. This works for daily summary dashboards that don't need real-time data.

Power BI Embedded: Deep Dive

Pricing and Capacity SKUs

Power BI Embedded uses Azure capacity (A-SKUs) billed hourly:

• A1: 1 v-core, 3 GB RAM - ~$1/hour. Good for development and low-traffic dashboards (up to ~50 concurrent renders)
• A2: 2 v-cores, 5 GB RAM - ~$2/hour. Handles moderate traffic
• A4: 8 v-cores, 25 GB RAM - ~$8/hour. Production workloads with 200+ concurrent renders

You can pause A-SKU capacity during off-hours to save cost. For production, auto-scale between SKUs based on demand.

App Owns Data vs User Owns Data

Two authentication models for embedding:

• App Owns Data: Your application authenticates with a service principal (Azure AD app registration). End users don't need Power BI licenses. This is the model for customer-facing SaaS embedding.
• User Owns Data: Each end user authenticates with their own Power BI account. Used for internal embedding where employees already have Pro or PPU licenses.

For customer-facing products, App Owns Data is almost always the right choice. Your customers shouldn't need Power BI accounts to see dashboards in your product.

Generating Embed Tokens

The embed flow works like this:

1. Your backend authenticates with Azure AD
   using a service principal (client_id + secret)

2. Backend calls Power BI REST API:
   POST /reports/{reportId}/GenerateToken
   Body: {
     "accessLevel": "View",
     "identities": [{
       "username": "tenant_123",
       "roles": ["TenantFilter"],
       "datasets": ["dataset-guid"]
     }]
   }

3. API returns an embed token (JWT, valid ~1 hour)

4. Backend passes embed token + embed URL to frontend

5. Frontend renders using Power BI JavaScript SDK:
   powerbi.embed(container, {
     type: 'report',
     embedUrl: embedUrl,
     accessToken: embedToken,
     tokenType: models.TokenType.Embed
   })

The identity object in step 2 is where RLS enforcement happens. The username and roles parameters tell Power BI which RLS filters to apply. If you skip this, every user sees all data.

Performance for Multi-Tenant Deployments

Multi-tenant embedded analytics has a unique scaling challenge: 500 tenants might load the same report in the same 10-minute window (e.g., Monday morning). Here's how to handle it:

• Pre-aggregate per tenant: Build warehouse tables that pre-compute common metrics at the tenant level. A report querying a pre-aggregated table renders in 1-2 seconds. The same report scanning raw event logs takes 8-15 seconds.
• Use parameterized datasets: In Power BI, use RLS with USERNAME() or CUSTOMDATA() to dynamically filter at query time rather than creating separate datasets per tenant. One dataset, many tenants.
• Cache common queries: If every tenant's dashboard shows "usage over the last 30 days," the query plan is identical - only the filter value changes. BI tools with smart caching can reuse compiled query plans across tenants.
• Stagger refresh schedules: If your data refreshes hourly, don't refresh all tenants at :00. Spread them across the hour to avoid capacity spikes.

For deeper guidance on making dashboards fast, see our Power BI performance optimization guide. Many of the same principles apply to embedded scenarios.

Cost Modeling: What You'll Actually Spend

Power BI Embedded's capacity model means cost scales with concurrency, not user count. If your 1,000 users never have more than 50 active at once, an A2 capacity handles it fine. Tableau's per-user model means you pay for all 1,000 regardless of activity. Metabase is free but you own the infrastructure, security patches, and upgrade cycle.

Real Scenario: SaaS Usage Analytics

A B2B SaaS platform wants to show customers their usage analytics: API call volume, error rates, feature adoption, and billing breakdowns. Here's how the architecture works:

1. Data pipeline: Event data flows from the application into Snowflake via a streaming pipeline. A dbt transformation layer aggregates raw events into tenant-level summary tables.
2. Data model: Power BI connects to Snowflake via DirectQuery (for real-time data) or Import with incremental refresh (for cost control). RLS filters every query by tenant_id.
3. Embedding: The SaaS backend generates an embed token with the logged-in customer's tenant_id baked into the RLS identity. The frontend renders the dashboard using Power BI's JavaScript SDK.
4. Caching: Pre-aggregated daily summary tables in Snowflake handle 90% of dashboard queries. Only drill-down interactions hit the raw event tables.
5. Scaling: An A2 capacity handles weekday traffic. Auto-scale to A4 during monthly billing cycle peaks when every customer checks their usage.

Total cost: ~$2,000/month for Power BI Embedded capacity plus Snowflake compute. Building equivalent functionality in-house would've taken 4 engineers 6 months. Understanding how to design dashboards that scale is essential for making this architecture sustainable.

The Gotcha: Capacity Sizing Is Not Optional

Power BI Embedded capacity must match your peak concurrent renders. Undersizing doesn't cause slow dashboards - it causes failed dashboards. Users see a "Capacity is exceeded" error and get a blank screen. There's no graceful degradation. An A1 capacity that handles 40 concurrent renders will hard-fail at 50.

Monitor your capacity utilization through the Azure portal and the Power BI Premium Capacity Metrics app. Set up auto-scaling rules to upsize during known traffic peaks (Monday mornings, end-of-month, after email campaigns that link to dashboards). Over-provisioning by one SKU is cheaper than losing customer trust with error screens.

Key Takeaways

CelestInfo Engineering Team

Data engineering and cloud consulting that ships. We build production data platforms on Snowflake, Azure, AWS, and Power BI from Sagar Nagar, Vizag 530045.

Frequently Asked Questions