How to Add Customer-Facing Analytics to Your SaaS

Every B2B SaaS product eventually gets the same feature request: "Can we see our data in a dashboard?" It starts as a one-off ask from your biggest customer. Then three more ask. Then your sales team starts losing deals because the competitor demo had charts.

You open a ticket. "Add analytics." Estimated effort: two sprints. Actual effort: five months, a burned-out frontend engineer, and a dashboard that breaks every time someone has more than 10,000 rows.

I've watched this play out at four different companies. The pattern is always the same — underestimate the scope, overcommit on custom code, and end up with something that's either too slow or too expensive to maintain.

The real scope of "just add dashboards"

When a PM says "customer-facing analytics," here's what they actually mean:

• Charts and tables that render inside your app, not a separate login.
• Multi-tenancy — Customer A never sees Customer B's data. Ever.
• Row-level security that maps to your existing auth model.
• White-labeling — your brand, your colors, no "Powered by X" footer.
• Performance — sub-second queries on datasets that grow monthly.
• Permissions — admins see everything, viewers see their team's slice.

That's not a dashboard. That's a product. And building it from scratch means you're now maintaining two products.

Build vs. buy — the honest math

Building from scratch looks cheap on paper. You pick a charting library (Recharts, Chart.js, D3), write some API endpoints, add a few SQL views. Two weeks, maybe.

Except then you need:

-- Row-level security view per tenant
CREATE VIEW tenant_orders AS
SELECT o.*
FROM orders o
JOIN tenant_mappings tm ON o.account_id = tm.account_id
WHERE tm.tenant_id = current_setting('app.current_tenant')::uuid;

And a caching layer because that query takes 4 seconds on 500k rows. And a permissions system. And date range filters. And CSV export. And drill-down. And your customers want to customize which metrics they see.

Six months in, you've built a half-featured BI tool and your core product roadmap is stalled.

Buying Looker or Tableau embeds solves the feature problem but creates a pricing problem. Looker embedded starts around $50k/year. Tableau Embedded runs $30–100k depending on users. For a SaaS doing $500k ARR, that's 10–20% of revenue going to your analytics vendor. The per-seat model gets worse as your customer base grows — exactly when it should get better.

The middle path is an embedded analytics platform built for SaaS teams. You get pre-built dashboards, API access, and multi-tenant isolation without the six-month build or the enterprise contract.

What to evaluate

I've done this evaluation three times. Here's what actually matters, ranked by how much pain it causes when you get it wrong:

1. Multi-tenancy and row-level security

This is the dealbreaker. If your embedded analytics vendor doesn't isolate tenant data at the query level, you're one bug away from a data breach. Ask specifically: does isolation happen at the database level, the application level, or both?

2. Auth integration

Your customers already log into your app. They should not log in again to see analytics. The embed solution needs to accept your JWT or session token and map it to the right tenant with the right permissions.

// JWT-based auth for embedded dashboards
const embedToken = jwt.sign(
  {
    tenantId: req.user.organizationId,
    role: req.user.analyticsRole, // 'admin' | 'viewer'
    filters: {
      region: req.user.allowedRegions   // row-level filtering
    }
  },
  process.env.EMBED_SECRET,
  { expiresIn: '1h' }
);

3. White-labeling

Your customers should never know there's a third-party tool behind the dashboard. That means: custom CSS, your logo, your domain (or at least a subdomain), and no vendor branding. Some platforms charge extra for this. Some don't offer it at all on lower tiers.

4. API access alongside embeds

Iframes are great for shipping fast. But eventually you'll want to pull data programmatically — populate a summary card on your homepage, send a weekly digest email, trigger alerts when a metric crosses a threshold. If the platform only offers iframes and no API, you'll hit a wall within a quarter.

5. Performance on real data

Ask for a demo with a million rows. Most embedded analytics tools demo with 500 records. Your customers will have 500,000. If the vendor can't show you sub-second queries on realistic volumes, move on.

How it works with Fastero

Fastero's embedded analytics takes the API-first approach — you get both iframe embeds for fast shipping and a full REST API for programmatic access.

Iframe embed

The fastest path to production. Create a dashboard in Fastero, grab the embed URL, and drop it into your app:

<!-- Embed a Fastero dashboard with tenant isolation -->
<iframe
  src="https://app.fastero.com/embed/dashboard/abc123
       ?token=YOUR_SIGNED_JWT
       &theme=light
       &hide_header=true"
  width="100%"
  height="600"
  frameborder="0"
  style="border-radius: 8px;"
></iframe>

The JWT token carries the tenant context. Fastero validates it server-side and filters every query to that tenant's data. No additional auth flow.

API-served data

When you need data outside of a dashboard — summary widgets, email reports, Slack alerts — use the query API:

# Fetch MRR by month for a specific tenant
curl -X POST https://api.fastero.com/v1/query \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "query": "SELECT date_trunc('\''month'\'', created_at) AS month, SUM(amount) AS mrr FROM subscriptions GROUP BY 1 ORDER BY 1",
    "tenant_id": "org_abc123",
    "cache_ttl": 300
  }'

Same row-level security. Same tenant isolation. The cache_ttl parameter lets you control freshness — 300 seconds is fine for a dashboard widget, 0 for a real-time alert.

Auth configuration

Map your existing user model to Fastero's tenant system. One API call during your app's auth flow:

// In your login/session middleware
const fasteroSession = await fetch('https://api.fastero.com/v1/auth/embed-session', {
  method: 'POST',
  headers: {
    'Authorization': `Bearer ${process.env.FASTERO_API_KEY}`,
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({
    external_user_id: user.id,
    tenant_id: user.organizationId,
    permissions: {
      dashboards: user.role === 'admin' ? ['*'] : ['overview', 'team-metrics'],
      can_export: user.plan === 'pro',
      row_filters: { region: user.region }
    },
    session_duration: 3600
  })
});
 
const { embed_token } = await fasteroSession.json();
// Pass embed_token to your frontend

The permissions object controls what each user sees. Admins get all dashboards. Viewers get a subset. Row filters narrow the data further — a regional manager sees only their region's numbers.

The migration question

If you've already built something custom, switching feels risky. Here's the approach that works:

1. Run both in parallel. Embed Fastero dashboards next to your existing ones. Let customers use either.
2. Compare load times and accuracy. Your custom solution probably has edge cases you've been ignoring. This surfaces them.
3. Cut over dashboard by dashboard. Not all at once. Start with the one that breaks most often.

Most teams I've talked to complete the migration in 2–4 weeks. The hardest part isn't technical — it's getting internal buy-in to stop maintaining the custom solution.

What this looks like in production

A typical setup: your app has a /analytics route that loads an iframe for the main dashboard, plus API calls that populate summary cards on the home screen. The SQL query layer runs against your existing database — Postgres, MySQL, or a warehouse — so there's no data pipeline to maintain.

Your customers see dashboards that look native to your product. Your engineering team stops fielding "the chart is wrong" tickets. And you didn't spend five months building a BI tool.

That's the pitch for embedded analytics at SaaS scale — not that it's easier than building (it is), but that it frees your team to work on the product your customers actually pay for.

For a deeper look at the specific embedding patterns — iframes vs. SDKs vs. API-first — see our implementation guide.

Try Fastero free — ship customer-facing dashboards this week, not next quarter. No credit card required.