Back to Blog
Article

A practical guide for SaaS founders on how to add customer-facing embedded analytics without months of engineering — covering build vs. buy, multi-tenancy, knowledge base layers, and a working JWT + QuerypanelEmbedded implementation.

Csaba Ivancza
10 min read
embedded analyticsSaaSmulti-tenantdashboardsengineeringnatural language to SQLSDK

There's a moment every SaaS founder recognizes.

You're on a customer call. Things are going well. Then they ask: "Can you add a chart showing our monthly active users broken down by region?"

You say yes, because of course you do. Then another customer asks for revenue trends. Then someone wants a funnel. Then a cohort table. Then filters. Then exports.

Six months later, you have a junior engineer whose entire job is building dashboards that have nothing to do with your core product. Your roadmap has been quietly hijacked by analytics requests.

This is the embedded analytics trap — and almost every B2B SaaS product falls into it.

This guide is about how to get out of it, or better yet, never fall in.

Why embedded analytics is harder than it looks

When most teams first face the dashboard problem, they think it's a frontend task. Grab Chart.js, write a few queries, render some bars and lines. Done in a sprint.

The reality is messier.

The real problem isn't the chart. It's everything underneath it.

To ship one honest, production-ready embedded dashboard, you need:

  1. A query layer that translates customer requests into SQL
  2. An auth layer that ensures Tenant A can never see Tenant B's data
  3. An API layer to serve results to your frontend
  4. A chart library with enough flexibility to handle every visualization type
  5. A dashboard builder so customers can arrange and save views
  6. An ongoing maintenance contract with yourself every time your schema changes

That's not a sprint. That's a quarter — minimum. And it compounds: every new chart is another surface to maintain, another thing to break when you migrate databases, another ticket in your backlog forever.

The three approaches (and who each is for)

Option 1: Build it yourself

Best for: Teams where analytics is the product, or where you have very specific data requirements that no tool can meet.

Building your own analytics stack gives you total control. You own the schema, the query patterns, the UI. Nothing is abstracted away.

The cost: it's slow, expensive, and pulls engineers off your core product. Expect 3–6 months for a solid v1, and ongoing maintenance forever. If analytics is a secondary feature (a support tool for your customers, not your core value prop), this is almost never the right call.

Option 2: Embedded BI tools (Sisense, ThoughtSpot, GoodData)

Best for: Enterprise companies with large data teams, dedicated BI engineers, and compliance requirements.

These are powerful platforms. They handle visualization, governance, semantic layers, and scale. They also cost $50–200k/year, require months of implementation, and are designed for internal BI teams — not for embedding cleanly into a SaaS product that serves thousands of tenants.

If you're a growing SaaS company trying to ship customer-facing analytics, these tools are like buying a cargo ship to cross a river.

Option 3: Developer-first embedded analytics SDKs

Best for: SaaS teams who want to ship customer-facing analytics in days, not months, without the operational overhead of enterprise BI.

This is the emerging category — tools built specifically for the SaaS embedded analytics problem. They handle the hard parts (multi-tenancy, query generation, chart rendering) while keeping your data in your own infrastructure.

This is where most modern SaaS teams should start.

What good embedded analytics actually looks like in 2026

The bar has risen. Customers don't just want a static dashboard anymore. They want to explore their data — ask questions, apply filters, drill down. The tools that are winning in this space share a few properties:

Natural language to SQL. Customers shouldn't need to know SQL to answer their own questions. Modern embedded analytics tools let users ask in plain English — "What was our churn rate last quarter by plan type?" — and generate the correct, tenant-scoped SQL automatically.

Zero credential exposure. Your database credentials should never leave your infrastructure. The right architecture generates SQL on your behalf, and you execute it in your environment. Your customer data never passes through a third-party server.

Tenant isolation by default. Every query must be automatically scoped to the right tenant. This isn't optional — it's a hard requirement. One misconfigured query that leaks data between customers is a catastrophic trust breach.

Dashboard forking. You should be able to create one dashboard template and automatically generate tenant-specific versions. Customers can customize their dashboards without affecting other tenants, and without you writing any code.

QueryPanel's core: a layered knowledge base

Dashboards and React embeds are what customers see. QueryPanel's core value is the knowledge base — the accumulated context that turns natural language into your metrics, joins, and vocabulary instead of generic SQL guesses.

You build and refine that knowledge across four layers:

  1. Gold queries — Curated question → SQL (and chart) pairs that encode how your team already answers recurring asks, so the model learns your patterns, not just your schema.
  2. Glossary — Business terms, synonyms, and definitions so phrases like "MRR," "active seat," or "expansion" resolve the way finance and product intend.
  3. Database annotation — Table and column descriptions, relationships, and guardrails layered on top of automatic schema introspection.
  4. Dynamic tenant-level definitions at runtime — Per-tenant context supplied when a user asks a question. A concrete example: data retention may vary by tenant—regulation, contract tier, or region—so a question like “show me the full history” or “last quarter” resolves against the correct window for that account, without cloning an entire workspace per customer. The same mechanism applies when that tenant names plans, regions, or product lines differently from everyone else.

Those layers are what separate technically correct SQL from answers your tenants actually trust.

A practical implementation path

If you're starting fresh, here's the sequence that works:

Step 1: Define your tenant model

Before writing any code, get clear on how your multi-tenancy works. Is tenant isolation done via separate schemas, a tenant_id column, or separate databases? This determines how queries need to be scoped.

Step 2: Choose your architecture

There are two valid paths:

  • Headless SDK: You embed query generation in your backend. The SDK takes a natural language question, generates safe tenant-scoped SQL, and returns results. You render charts with your own UI or the SDK's chart output.
  • Drop-in dashboard component: A full React component that gives your customers an analytics workspace — dashboards, filters, saved views, chart exploration — without you building any of it.

Many teams start with QuerypanelEmbedded on a dedicated analytics route for the fastest path to a full workspace, then add headless ask() from the backend only where they need a fully bespoke UI.

Step 3: Connect your database

A good tool will inspect your schema automatically — tables, columns, relationships, data types — without you having to manually configure everything. You then teach it your domain: glossaries, gold queries, annotations, and (for multi-tenant SaaS) runtime tenant definitions so each customer's language and segmentation still maps to safe, scoped SQL.

That is the same knowledge base idea as above: introspection gets you structure; the four layers get you meaning.

Step 4: Define your tenant scoping rules

This is the critical security step. You configure which column or schema identifies a tenant, and the tool guarantees that every generated query includes the appropriate filter. No query should be executable without tenant context.

Step 5: Embed and ship

With the full embedded dashboard from @querypanel/react-sdk, you render one component in your product and hand it a tenant-scoped JWT your server mints with @querypanel/node-sdk. The workspace private key never goes to the browser — only the short-lived token does.

Server — mint a JWT (e.g. Next.js route handler or your API):

import { QueryPanelSdkAPI } from "@querypanel/node-sdk";

const qp = new QueryPanelSdkAPI(
  process.env.QUERYPANEL_API_BASE_URL!,
  process.env.QUERYPANEL_PRIVATE_KEY_PEM!,
  process.env.QUERYPANEL_WORKSPACE_ID!,
);

export async function POST() {
  const user = await getUserFromSession(); // your auth
  const jwt = await qp.createJwt({
    tenantId: user.organizationId,
    userId: user.id,
    scopes: ["dashboards:read", "charts:read"],
  });
  return Response.json({ jwt });
}

Client — drop in the embedded workspace:

import { QuerypanelEmbedded } from "@querypanel/react-sdk";

export function CustomerAnalytics({ dashboardId, jwt }: { dashboardId: string; jwt: string }) {
  return (
    <QuerypanelEmbedded
      dashboardId={dashboardId}
      apiBaseUrl={process.env.NEXT_PUBLIC_QUERYPANEL_API_BASE_URL!}
      jwt={jwt}
      allowCustomization
    />
  );
}

That single component covers dashboards, natural language exploration, filters, and saved views — the same surface your team builds in QueryPanel, now embedded in your app. Optional props like darkMode, colorPreset, theme, and branding handle look-and-feel; allowCustomization enables safe per-tenant forks without touching your codebase.

If you later need a fully custom NL-to-chart UI, you can compose QueryPanelProvider with QueryInput / QueryResult and your own /api/ask routes — but most teams ship faster by starting with QuerypanelEmbedded.

The questions to ask any embedded analytics vendor

Before committing to a tool, get clear answers on:

  • Does my data ever leave my infrastructure? It shouldn't. If the vendor executes SQL on your database directly, that's a red flag.
  • How is multi-tenancy enforced? It should be automatic and guaranteed — not something you configure manually per query.
  • What happens when my schema changes? Good tools re-inspect automatically or have a lightweight re-annotation flow.
  • What's the pricing model? Per-tenant pricing scales naturally with your SaaS growth. Per-seat or per-query models can get painful fast.
  • Can my customers customize their dashboards without engineering involvement? This is the ultimate test of whether the tool actually removes work from your plate.

The build vs. buy math

Let's be blunt about the numbers.

A mid-level engineer costs roughly $150–200k/year fully loaded. A solid embedded analytics v1 takes 3–4 months to build. That's $40–65k of engineering time — before ongoing maintenance, bug fixes, and feature requests.

A developer-first embedded analytics platform typically runs $50–999/month depending on scale.

Even at the highest tier, you're paying for the tool for 8+ years before you'd break even versus building it yourself — and that's ignoring the opportunity cost of what your engineers could have built instead.

The math almost always favors buying. The only exception is when analytics truly is your core product.

What to do today

If you're currently drowning in dashboard requests, here's the immediate action plan:

  1. Stop saying yes to individual chart requests. Each one is technical debt. Bundle them into an analytics initiative instead.
  2. Audit what you've already built. How much engineering time has gone into dashboards in the last 6 months? That's your real cost baseline.
  3. Prototype with an SDK. Most tools have a free tier. Spend an afternoon connecting your database and running a few natural language queries against it. The gap between "this is a toy" and "this could actually ship" is smaller than you think.
  4. Get one analytics feature in front of customers fast. The feedback you get in week one will reshape your entire analytics roadmap — and you'll learn it for almost no engineering cost.

The real unlock

Embedded analytics isn't a feature. It's a leverage point.

When your customers can explore their own data, answer their own questions, and build their own views — without filing tickets with you — the support burden drops, NPS goes up, and churn goes down. Analytics becomes a retention mechanism, not a cost center.

The teams that figure this out early don't just save engineering time. They ship a product that's genuinely stickier, because customers who live in your analytics are customers who can't easily leave.

That's the real reason to solve this properly — not just to stop the dashboard requests, but to turn them into a competitive advantage.

QueryPanel is an AI-native embedded analytics SDK built for multi-tenant SaaS. It handles natural language to SQL, tenant isolation, and chart generation so your team can ship customer-facing analytics in days instead of months. Start building for free →