Embed Live Dashboards in Your SaaS Product (Without the $70/Viewer Bill)

Your customers want dashboards inside your product. They're asking for usage reports, spend breakdowns, performance metrics — data they know you have but can't see without exporting a CSV and building their own spreadsheet.

So you start scoping the feature. A charting library (Recharts? D3?). A data aggregation API. A caching layer so you don't melt your production database. A permission model so Customer A doesn't see Customer B's data. PDF export because someone always asks. Date range pickers. Drill-down filters. Loading states.

You've just described 3-6 months of engineering work. And you haven't shipped a single feature on your actual roadmap.

The build-from-scratch trap

I've watched teams fall into this. They start with "let's add a simple analytics tab" and end up building a BI tool. The first bar chart takes a week. Then someone asks for line charts. Then filtering by dimension. Then "can we export this?" Then "can we schedule this to email?"

Every one of those requests is individually reasonable. Together, they're a product — a product you never intended to build and one that will demand ongoing maintenance, bug fixes, and feature requests for as long as it exists.

The actual cost isn't the initial build. It's the opportunity cost of your engineers working on embedded charts instead of the features that differentiate your product. At a $150k fully loaded eng salary, a 3-month project is $37.5k per engineer before you factor in the ongoing maintenance tail.

What the market charges for embedded analytics

If building from scratch is too slow, you can buy. But the pricing on most embedded analytics vendors is designed for enterprises, not growing SaaS companies.

Tableau Embedded charges ~$70/viewer/month. If you have 200 customers with analytics access, that's $14,000/month — probably more than your entire MRR if you're pre-Series A. The product is powerful, but the unit economics work against you as your customer base grows.

Looker Embedded starts at $5,000+/month as a platform fee, plus per-user costs. Google has been rolling Looker into their cloud platform, which adds complexity to the licensing picture. Looker's modeling layer (LookML) is genuinely good, but it's an investment in a new abstraction layer your team has to learn and maintain.

Luzmo (formerly Cumul.io) is purpose-built for embedded analytics and does it well — clean SDK, reasonable white-labeling, good customization. Pricing runs $250-1,000+/month depending on data volume and users. More aligned with the embedded use case than Tableau or Looker, but still a meaningful line item for early-stage SaaS.

Metabase has a free open-source tier with basic embedding. You can iframe dashboards with signed URLs, which gets you running fast. The limitation is theming — it looks like Metabase inside your product, and customization options are narrow. Fine for an internal tool. Less convincing when customers are paying for your analytics feature.

Retool is excellent for internal tools but isn't designed for customer-facing analytics. Your end users don't get Retool accounts — it's for your ops team building admin panels. Wrong tool for this job.

The pattern across all of these: either the pricing scales against you (per-viewer models that grow with your customer base), or the product wasn't designed for external embedding (limited theming, visible third-party branding, constraints on multi-tenancy).

The middle path: build dashboards, embed the output

Here's what actually makes sense for a SaaS company with 50-500 customers that wants to ship embedded analytics without a six-figure vendor contract or a six-month eng project.

The approach: build your dashboards in a tool that supports embedding, then expose them to your customers via iframe or API. You get full control over the data and presentation without owning the charting infrastructure.

Fastero's embedded analytics supports both paths. You can build dashboards using SQL queries (or generate them from natural language), then embed them in your product through shareable iframe links or pull the data programmatically through the REST API.

Iframe embedding

The fastest path. Build a dashboard in Fastero, generate a share link with an auth token scoped to a specific customer's data, and embed it in your product.

<!-- Embed a customer-scoped dashboard -->
<iframe
  src="https://app.fastero.com/share/dash_abc123?token=cust_token_xyz"
  width="100%"
  height="600"
  frameborder="0"
  style="border: none; border-radius: 8px;"
></iframe>

The token controls which rows the viewer sees. Customer A gets a token that filters to their org's data. Customer B gets a different token. Same dashboard definition, different data — you don't need to create a separate dashboard per customer.

You can control theming to match your product's look: background color, font, accent colors, chart palette. The result doesn't scream "third-party embed" the way a raw Metabase or Tableau iframe does.

API-first embedding

If you want full control over the frontend — your own React components, your own chart library, your own layout — pull the data via API and render it yourself.

// Fetch dashboard widget data for a specific customer
const response = await fetch(
  'https://api.fastero.com/v1/queries/qry_monthly_usage/results',
  {
    headers: {
      'Authorization': 'Bearer sk_live_your_api_key',
      'X-Customer-Id': 'cust_12345'
    }
  }
);
 
const { data, columns, metadata } = await response.json();
 
// data is an array of row objects — render with Recharts,
// a plain HTML table, or whatever fits your product

This gives you the query infrastructure, caching, and row-level security without the charting opinions. You own the UI entirely. The API and webhooks documentation covers the full endpoint surface — pagination, filtering, scheduled refresh, webhook subscriptions for when underlying data changes.

Row-level security

This is the part that takes weeks to build from scratch and minutes to configure in Fastero. Each API key or share token is scoped to a customer context. The query runs with that context applied, so SELECT * FROM usage_metrics automatically returns only that customer's rows.

No application-level filtering. No risk of one customer seeing another's data because someone forgot a WHERE clause. The security boundary is in the platform, not in your code.

Use cases that actually ship

These are the patterns I see SaaS companies implement with embedded dashboards:

Customer analytics tabs. The most common. Your customer logs into your product, clicks "Analytics" or "Reports," and sees their usage, spend, or performance data in charts and tables. This is the feature that reduces "can you pull me a report?" support tickets to near zero.

White-labeled reporting. Agencies and service providers who need to show clients their results — ad performance, campaign metrics, operational KPIs — branded with the agency's logo and colors. The client sees the agency's product, not a third-party tool.

Partner portals. Marketplace operators or platform companies giving partners visibility into their performance — transaction volumes, conversion rates, payout summaries. Each partner sees only their data through the same dashboard definition.

Premium analytics tiers. Gate the analytics feature behind a paid plan. Your free tier shows basic metrics in-app. Your Pro tier unlocks full dashboards with filtering, drill-down, and export. This is a real revenue lever — you're monetizing data your product already collects.

The pricing math that matters

Here's why per-viewer pricing models break down for growing SaaS companies.

Say you're charging $99/month per customer and you add an analytics feature. With Tableau Embedded at $70/viewer/month, your analytics feature costs you 70% of the customer's subscription before you factor in your own infrastructure. Every new customer makes the economics worse.

With a flat-rate platform like Fastero, the cost doesn't scale per viewer. You pay for the platform, build your dashboards, and embed them for 50 or 500 customers at the same price. The more customers who use the analytics feature, the better your unit economics get — which is how pricing should work when you're building a SaaS product, not buying enterprise software.

This matters even more if you plan to monetize the analytics feature. If your Pro plan charges $30/month extra for dashboards but costs you $70/month per viewer in embedded analytics fees, you're losing money on every upgrade. With flat pricing, that $30/month is margin from day one.

The path from here

If you're evaluating embedded analytics for your SaaS product, here's the sequence that actually works:

1. Build 3-5 dashboards that cover the metrics your customers ask about most. Use SQL if you know the queries, or generate them with natural language if you want to move faster.
2. Start with iframe embeds. Fastest path to "analytics is live in the product." You can always migrate to API-first later if you want more UI control.
3. Set up row-level security so each customer's token scopes to their data. This is table stakes — don't ship embedded analytics without tenant isolation.
4. Ship it behind a feature flag and test with 10 customers. Measure support ticket reduction and engagement before rolling it out to everyone.
5. Monetize it. Add an Analytics or Pro tier. Charge for the feature. Your customers are already asking for this data — they'll pay for it if the presentation is clean.

If you want the deeper technical comparison of embedded approaches — iframe vs. API-first vs. white-label SDK — we wrote a full breakdown in How to Embed Analytics in Your SaaS Product. For the API-side architecture specifically, Building Embedded Analytics APIs from SQL walks through the query-to-endpoint pattern.

Try Fastero free — embed dashboards in your SaaS product without building a BI tool or paying per viewer. No credit card required.