Embedded analytics: dashboards inside your own product

What is embedded analytics?

Embedded analytics is a BI platform’s dashboards delivered inside another application, under that application’s branding, showing each user only their own data. The customer never sees the BI tool; they see a "Reports" or "Insights" section of the product they already pay for.

Three levels exist, and it helps to know which one you are asking for:

1. A shared link or PDF — the dashboard lives in the BI tool and customers receive a link or a scheduled file. Quick, but visibly separate from your product.
2. Dashboards inside your product — the pages render within your application, styled to match, filtered to the logged-in customer. This is what most people mean by embedded analytics.
3. Self-serve inside your product — customers can also change filters, build their own charts and schedule their own reports, still within your interface.

Most companies start at level two and add level three for their larger customers.

When does a SaaS company need embedded analytics?

The signals are usually in the support queue and the sales pipeline before anyone calls it a product requirement:

• Customers export CSVs from your product to build their own charts. Each export is a report you could have shown them.
• "Can you send me a breakdown of…" is a recurring ticket type, and someone on your team runs a query by hand to answer it.
• Larger prospects ask "what reporting do you have?" during evaluation, and the honest answer is a table with a date filter.
• Your product generates data customers pay other tools to analyse — a logistics platform whose customers chart deliveries elsewhere, an HR system whose customers rebuild headcount in a spreadsheet.
• A competitor’s "analytics" tab has come up in a lost-deal review.

A worked example: a field-service platform with 300 customers was handling about 40 report requests a month by hand, roughly 25 hours of engineering time. An embedded reporting tab with six dashboards took most of that to zero and became a line on the pricing page. See Klayara for SaaS companies.

What do customers expect from embedded dashboards?

Customers judge an embedded dashboard by the standard of your product, not by the standard of BI tools. In practice they expect:

• It looks like your product. Same fonts, colours and spacing. No visible third-party logo or "powered by".
• It loads as fast as the rest of the app. A reporting tab that takes ten seconds gets used once.
• It shows only their data, including in downloads and anything scheduled to their inbox.
• They can filter by date, location, team — whatever their world is divided into — and click a number to see the rows behind it.
• They can export a chart or table as PDF, image or CSV without asking you.
• They can receive it on a schedule: a weekly summary by email or a daily one to a Slack or WhatsApp group.
• It works on a phone, because their manager will open it on one.

Anything missing from this list becomes the next support ticket, so it is worth choosing a platform that covers all seven from the start rather than the first three.

How do you keep every customer’s data separate?

This is the part that keeps product managers awake, and the plain-words version is straightforward: you build one dashboard, and a rule attached to the data says "show only rows belonging to the customer who is logged in". Customer A opens the reports tab and sees Customer A’s deliveries; Customer B sees Customer B’s. There is no dashboard per customer to maintain, and no way to reach another customer’s rows by changing a filter.

What to check in any platform you evaluate:

1. The rule is set once on the data, not repeated per chart — otherwise a new chart can forget it.
2. It holds in every path: the dashboard, the CSV download, the scheduled email, and any AI answer given inside your product.
3. You can log in as a test customer and confirm they cannot see anyone else, and that the check is repeatable before each release.
4. Column rules exist too, so a field visible to your staff (cost price, internal notes) is hidden from customers on the same page.

Klayara applies row- and column-level permissions to the data itself, so embedded views, downloads, scheduled reports and AI answers all inherit them. Row-level security explained covers the idea in more depth.

What does white-labelling mean in plain words?

White-labelling means the analytics carry your brand and nobody else’s. Concretely, it means you can set:

• your logo, colours and fonts, so charts match the rest of your screens;
• your own names for things — "Sites" not "Dimensions", "Jobs" not "Records";
• your own domain for any links or scheduled emails, so nothing arrives from a vendor’s address;
• no vendor name, badge or link anywhere a customer can see.

Ask to see a live white-labelled example rather than a screenshot, and check the scheduled email and the exported PDF — those are the places a vendor name most often survives.

What should you think about on pricing?

Without quoting figures, the shape of embedded analytics pricing matters more than the level, because your customer count will change and your price to them is fixed.

• Per-viewer pricing can be unpredictable: if every user of your product becomes a viewer, your analytics cost grows with adoption, which is the opposite of what you want.
• Usage or query-based pricing punishes the customers who use the feature most.
• A flat platform price for embedded use is easiest to build into your own pricing page. Ask what the cap is and what happens when you pass it.
• Build versus buy: building your own charts is cheap for the first two and expensive from the fifth, once filters, permissions, exports and scheduling are needed. Cost that honestly in months of engineering, not licence fees.

A reasonable test: can you write the analytics line of your own pricing page without knowing how many customers will adopt it? If not, the vendor’s model is too variable for embedding.

How to start in four steps

1. Pick the three reports customers most often ask you for. Those are the first three dashboards.
2. Build them once, under your branding, with the customer rule applied to the data.
3. Put them behind a "Reports" tab for five friendly customers and watch what they click, download and ignore for a month.
4. Add scheduled delivery and self-serve filters, then put reporting on the pricing page.