Embedded analytics:governed insight inside the product your users already open.
Put pinboards, charts and plain-language questions into your own application, resolved per user against one certified metric layer. Your customers never sign in to a second tool, and your data never leaves your warehouse.
- Queries run in your warehouse
- One certified definition per metric
- Cloud, on-premise or hybrid
Embedded analytics, defined.Analytics your users meet inside your product, not beside it.
Embedded analytics is reporting and question answering that lives inside another application, so the person who needs a number sees it where they are already working instead of signing in to a separate BI tool. For a software company that usually means analytics shipped to customers as part of the product. For an internal platform team it means the same thing, pointed at colleagues.
In practice the term covers everything from a single chart pasted into a page to a full governed workspace. What separates them is how much of the stack below the chart comes with it.
Every embedded deployment has three parts
- The surface
What the user sees
The board, chart, question box or narrative that appears in your product. It carries your layout and your theme, and it is the only part your users ever think about.
- The engine
What answers the question
The query layer that resolves what was asked against your data and the certified definition of each metric, so two surfaces asking the same question cannot come back with two numbers.
- The handoff
What makes it safe to expose
Your application tells the engine who is asking, and access is resolved for that identity at query time. This is the part that lets you put analytics in front of customers rather than only staff.
What it is not
Not a chart library
A charting package draws whatever you hand it. It has no opinion about where the numbers came from, whether they are the agreed ones, or who is allowed to see them.
Not a shared dashboard in a frame
Dropping one dashboard into a page gives every viewer the same dashboard. Embedded analytics resolves the view for the person looking at it, which is the part that takes real work.
Not a BI licence resold
Per-seat pricing collapses the moment your user count becomes your customers' user counts. Embedding is a different commercial shape, not a reseller agreement.
What you can put in your product.Four shapes, one engine behind all of them.
Each of these is a live governed surface rather than a picture of one. A user can filter it, ask it a follow-up, and see which certified metric the number came from.
Dynamic pinboards
Boards that move with the business instead of a dashboard somebody rebuilds each quarter. Users pin what they care about and arrange it themselves.
Replaces the standing report request
A single chart or KPI
One visual or one number, placed in a page your users already visit. The smallest useful unit of embedding, and usually the first thing worth shipping.
Fastest to first value
The ask bar
A plain-language question box. Users ask in their own words and get an answer traced back to a certified metric, with no query language to learn first.
No training required of your users
Stories and storybooks
Curated narratives pairing visuals and KPIs with written commentary, which refresh when someone opens them rather than when someone re-exports them.
One-click updates, no manual exports
Three ways in,depending on how much you want to own.
The routes differ in how much interface you build, not in what governs the answer. All three resolve against the same semantic layer under the same access rules.
A governed view inside your page
The quickest route. A QuaerisAI surface sits in your application and your application tells it who is looking. Your layout and theme wrap it, and keeping the surface working is our job rather than yours.
Least engineering, fastest to ship
The REST API, for an interface you build
Query the governed layer directly and draw the result yourself. You own every pixel, while the metric definitions and the access rules still come from the layer rather than from your code.
Total design control
MCP tools, for an assistant in your product
If your product has an assistant, hand it the metric layer as tools instead of a database connection. It asks the questions your charts ask and gets the answers your charts get.
Same governance as every other consumer
Your warehouse stays the system of record.Nothing is copied to us to make this work.
The question most security reviews open with, answered before it is asked. This is also why the numbers in your product are current rather than as of the last sync.
Queries run where your data lives
Execution is warehouse native. A question is compiled and run against your warehouse, so the answer reflects what is there now and the data never needs a second home.
No copy on our infrastructure
There is no extract step and no mirror to keep in sync. That removes a whole class of question from your security review, and a whole class of job from your schedule.
Runs where you need it to
Fully containerized and Kubernetes native, so the same deployment serves cloud, on-premise or hybrid without a different product for each one.
Every answer carries its trace
Lineage from the number back to the source table, and an audit trail of what was asked. When a customer disputes a figure, answering is a lookup rather than an investigation.
The chart is a weekend.Everything underneath it is the project.
Teams rarely underestimate the chart. They underestimate these, and these are the parts that keep asking for attention long after launch.
Per-customer isolation
Working out what each customer may see, on every query, and being able to prove it. The part that turns a demo into a signed deal, and the part a home-built embed gets wrong first.
One definition of each metric
Keeping the number in your product identical to the number in the finance report, including after somebody changes how it is calculated.
Performance at your customer count
A query that is quick for ten users and a query that is quick for ten thousand across hundreds of tenants are not the same query.
Export, scheduling and alerts
The features nobody asks for during the first demo and everybody asks for in the second month of production use.
Small screens and assistive tech
A chart that holds up on a phone, and a table a screen reader can navigate. Both are real work and both tend to be discovered late.
The upgrades after launch
A new warehouse, a new chart type, a new permission model. Every one of them lands on whoever owns the embed.
Tech is a cost.Insight is revenue.
What changes on your side of the contract once analytics is part of the product rather than a queue of requests.
Fewer support requests
Self-service answers replace the tickets asking your team to pull a number. The question gets answered sooner and costs nobody a morning.
Growth without a per-seat ceiling
Expand your user base without a fixed licence cost for each new person, which is what makes embedding viable when your users are your customers' whole company.
An analytics tier worth paying for
Advanced analytics becomes a package you can price, with enough substance behind it that the upgrade still looks fair at the first renewal.
Embedded, white label, headless.The difference is who owns the interface.
You are on the embedded page, so this is the comparison against the other two rather than a reason this one always wins. All three run on the same engine, the same semantic layer and the same governance.
Our whole product, carrying your brand.
Our engine, none of our interface.
| Attribute | Embedded | White label | Headless |
|---|---|---|---|
| What you get | Views you drop into your app | A branded analytics product | Governed query interfaces |
| Who builds the interface | We do | We do | You do |
| Whose brand shows | Yours, around our views | Yours, everywhere | Only yours, there is nothing else to see |
| Time to first value | Fastest | Fast | Depends on your build |
| Engineering required | Integration work | Configuration | Front-end build, then maintenance |
| Design control | Themeable | Themeable | Total |
| Who asks the questions | Your users, in your product | Your clients, in their own workspace | Whatever you point at the layer |
| Non-visual consumers | Not the purpose | Not the purpose | First-class: agents, jobs, services |
| Semantic layer | Shared | Shared | Shared |
| Governance and lineage | Enforced at query time | Enforced at query time | Enforced at query time |
| Typical buyer | Product teams | Agencies, consultancies, vertical SaaS | Platform and data engineering teams |
Most teams end up mixing them
Embedded for the surfaces you would rather not build twice, headless for the one screen you care enough about to build yourself. The engine underneath does not change, so the numbers agree whichever route a given team took.
When embedded is the right choice,and when one of the other two is.
All three are our own products, so there is nothing to lose by saying which one you came for.
Choose embedded if
- You have a product with users in it today, and analytics is the gap
- You want analytics shipped in weeks rather than built over quarters
- Each of your customers needs their own data, isolated, without you writing that logic
- Our views, themed to match your product, are close enough to what you want
- You would rather spend your engineers on your product than on charts
Look at one of the others if
- Every pixel has to match a design system you already maintain
- The main consumer is not a person but an agent, a job or another service
- You are selling an analytics product in your own name, at your own prices
- There must be no trace of another vendor anywhere in the experience