Your B2B customers want to see their data. Usage metrics, billing summaries, conversion funnels, performance dashboards. Every customer expects analytics inside your product. They shouldn't have to ask your support team for a CSV export.
The question isn't whether to ship customer-facing analytics. It's how.
Most teams start with one of two approaches. They embed a BI tool (Metabase, Looker, Power BI) and fight with multi-tenancy, iframe styling, and paid embedding licenses. Or they build custom charts from scratch and spend months maintaining SQL queries, API endpoints, and frontend components that nobody asked for.
Both approaches burn engineering time on the wrong problem. You end up building analytics infrastructure instead of your product.
And there's a surface most of these tools miss entirely: the AI agent. Customers increasingly want to ask questions about their data inside Claude or ChatGPT and get a chart back. That's a different problem from embedding a dashboard, and it's covered later in this post.
Why embedded BI tools fall short
Embedding a BI tool sounds fast. Drop in an iframe, connect to your database, ship it. In practice, the friction shows up quickly.
Multi-tenancy is an afterthought
Most BI tools were built for internal teams, not B2B products serving hundreds of tenants. Multi-tenancy is either missing, manual, or gated behind an enterprise license.
Metabase requires the Enterprise license ($500+/month) for row-level permissions and sandboxed embedding. The open-source version has basic embedding but no tenant isolation. You end up writing middleware to filter queries by tenant, which is exactly the custom infrastructure you were trying to avoid.
Looker's embedded analytics requires an enterprise contract. Power BI Embedded uses capacity-based pricing that gets expensive at scale. Tableau's embedding story is Salesforce-priced.
Even when multi-tenancy is available, it's usually dashboard-level or role-based, not per-query structural enforcement. You're trusting the BI tool to filter correctly on every query. One misconfiguration and Customer A sees Customer B's data.
Styling and UX limitations
An iframe is a foreign element in your product. It looks like a foreign element. Matching your brand's fonts, colors, spacing, and interaction patterns inside an embedded BI tool ranges from difficult to impossible. Your customers notice.
White-label analytics means your customers shouldn't know they're using a third-party tool. Most embedded BI solutions make this hard. The ones that make it easy charge for it.
You're locked to dashboards
Embedded BI gives you dashboards. That's one surface. But your customers might also want:
- An API to pull metrics into their own tools
- AI agents that answer questions about their data
- Scheduled email reports
- Webhook alerts when metrics cross thresholds
- CSV/Excel exports for their finance team
Each of these requires a different integration, often with different tools and different metric definitions. The dashboard shows one number. The API returns a different one. The export uses yet another query. The metrics drift.
Why building from scratch is worse
The alternative: skip the BI tool and build it yourself. Custom SQL queries, custom API endpoints, custom React charts.
This works for the first dashboard. Then the second. By the tenth, you're maintaining a bespoke analytics platform. Every new metric means a new SQL query, a new API endpoint, a new frontend component, and a new set of tests. Your data engineers are writing API handlers instead of defining metrics. Your frontend engineers are debugging chart edge cases instead of building product features.
The real cost isn't the initial build. It's the ongoing maintenance:
- Metric drift. Revenue is calculated differently in the dashboard, the API, and the export. Nobody notices until a customer complains.
- No caching layer. Every API call hits the warehouse. Response times grow with data volume. Your customers experience slow dashboards at month-end when they need them most.
- Security is DIY. You build tenant filtering yourself. You test it yourself. You hope you didn't miss an edge case.
- No schema evolution. Adding a new dimension means updating every query, endpoint, and component that touches the affected metric. A one-line change in business logic cascades into a multi-day project.
The teams on Reddit asking "Is embedded analytics for SaaS actually worth it vs building your own charts?" are wrestling with exactly this tradeoff. There's no single right answer. The decision depends on how many surfaces you serve and whether your customers want charts in a dashboard, an API, or an AI agent.
The AI agent surface: analytics inside the client
The sections above cover the two classic customer-facing analytics options: embed a BI tool or build dashboards from scratch. There's a third surface that neither covers well: the AI agent. When your customer asks a question in Claude or ChatGPT and wants a chart back, an embedded dashboard doesn't help.
Serving this surface takes four things:
- A governed query path. The agent asks a question; something turns it into a query against your database or semantic layer, with the metric definitions your finance team would recognise. Leaving the model to write arbitrary SQL gives you the same drift problem as building from scratch, only faster.
- Per-tenant isolation that follows the sign-in. The customer authenticates with their identity provider, and that identity decides which rows a query can see. Row-level security, schema routing, a dataset per tenant, or one app per customer all work; what matters is that the isolation is structural rather than a filter you remember to add.
- Rendering in the host. MCP lets a server return a chart or table that the AI client renders in the conversation. The customer never leaves the chat.
- An audit log. Every call recorded with who ran it, when, and what it touched, so you can answer "who saw which data" without reconstructing it from warehouse logs.
None of this is exotic. It is the same governance you would want behind an embedded dashboard, delivered through a different front door.
Build vs. embed vs. governed BI in the agent
| Build from scratch | Embed BI tool | Governed BI in the agent (Bonnard) | |
|---|---|---|---|
| Surface | In your product UI | In your product UI | Inside Claude, ChatGPT, Gemini, Copilot |
| Time to first chart | 2-4 months | 1-2 weeks | Four setup steps, no engineering |
| What renders the chart | Your frontend code | The BI tool | The AI client |
| Where the query runs | Your code | The BI tool | Bonnard, against your database or semantic layer |
| Tenant isolation | DIY | Enterprise tier | Four models, decided by the customer's sign-in |
| Maintenance burden | High (you own everything) | Medium (tool updates, iframes) | Low (publish an app, choose the audience) |
| AI agent support | Build from scratch | None | Native (MCP) |
These are not competing for the same slot. Embedded BI and a from-scratch build put charts in your product UI. Governed BI in the agent puts them inside the AI client. Many teams will do both.
What makes the AI agent surface different
Embedded analytics tools (Metabase Embedded, Holistics, Explo, Luzmo, Reveal) give you dashboards inside your product. That's their scope. They're good at it. None of them render a chart inside an AI agent.
The agent surface differs in two ways. The chart lives in the conversation: a customer asks a question in Claude or ChatGPT and the answer arrives as a chart or table there, with no tab switch. And the customer's identity does the scoping: the sign-in decides which tenant's rows a query can see, so per-customer isolation is a property of access rather than a filter added per dashboard.
The tradeoff: embedded BI tools render charts in your product UI, which is where many customers expect them. If your customers want both a dashboard and an answer in the agent, use an embedded BI tool for the dashboard and a governed agent surface for the rest.
Where Bonnard fits
Bonnard serves the AI agent surface as governed BI inside the clients your customers already use: Claude, ChatGPT, Gemini, Copilot. Connect PostgreSQL, BigQuery, Redshift, ClickHouse, DuckDB or MotherDuck, or MySQL or MariaDB, or point it at a dbt, Cube, MetricFlow, or custom semantic layer. Create an app, choose the audience, publish. Access is role-based per app, tenant isolation comes in four models, and every call is logged with who ran it and what it touched. Bonnard is pre-launch. Join the waitlist.
Frequently asked questions
What is customer-facing analytics?
Customer-facing analytics is analytics embedded in your product for your customers to use. Instead of internal dashboards for your team, the analytics are exposed to end users: your B2B customers, their teams, and their tools. The key challenges are multi-tenancy (each customer sees only their data), performance (customers expect fast load times), and consistency (the numbers should match across every surface).
What is embedded analytics?
Embedded analytics means integrating analytics capabilities directly into another application. This can be as simple as an iframe embedding a dashboard or as sophisticated as native React components querying a governed API. The term covers a range of approaches from basic chart embedding to full white-label analytics platforms.
How is this different from Metabase embedding?
Metabase offers embedded dashboards via iframe or full-app embedding. The open-source version has basic embedding but no tenant isolation. The Enterprise version ($500+/month) adds row-level permissions and sandboxed embedding. Metabase renders charts in your product UI. Bonnard is a different surface: governed charts and tables inside an AI client. They are not substitutes. Use Metabase for an in-product dashboard, and Bonnard for analytics in the agent.
What is white-label analytics?
White-label analytics means your customers see your brand, not a third-party tool's brand. No "Powered by Metabase" footer. No foreign-looking iframe. The analytics feel native to your product. Most embedded BI tools charge for white-labeling, and the harder it is to match your design, the more obvious the third-party tool becomes. This is a property of in-product embedding, not of charts rendered inside an AI agent.
What is customer-facing analytics for AI agents?
It is letting your customers ask questions about their data inside an AI agent (Claude, ChatGPT, Gemini, Copilot) and get a chart or table back in the conversation. The requirements are the same as in-product analytics, with one addition: the result has to render inside a host you do not control. Bonnard covers this surface as governed BI published into those clients.
Can my customers get charts inside an AI agent?
Yes. The agent connects to a governed data source over MCP, runs the query against your database or semantic layer with the customer's access applied, and the host renders the chart in the conversation. Bonnard packages this as an app you publish to a chosen audience.
Top comments (0)