What Is Verifiable Conversational Analytics?
Conversational analytics lets you ask questions about your data in ordinary language. A verifiable answer also shows the query and sources used, so you can check what the number measures.
By the Datarelix Team · Published · Updated · Last verified
Verifiable conversational analytics means asking a database a question in ordinary language and receiving the answer together with the evidence behind it: the executed query, the source tables, the returned row count and the runtime. That evidence lets a business user confirm the period and the definition, and lets an analyst check joins and filters, before a number is reused. This guide explains what to look for in that evidence, works through a monthly revenue example and lists what to ask a vendor before choosing a tool.
Start with a question you need answered
Suppose you want to know which customers bought the most last quarter. A conversational analytics tool can turn that question into a database query and return a table or chart. To use the answer, you still need to know what “bought the most” means: order count, gross sales, or sales after refunds.
Verifiable conversational analytics makes that interpretation inspectable. It helps people preparing reports, investigating changes, or checking numbers before sharing them. You can review dates and definitions without writing SQL. Detailed checks of joins or calculations may need someone who reads SQL.
What comes with an answer?
Datarelix shows four pieces of execution information:
| Information | What it helps you check | What it does not establish |
|---|---|---|
| Executed query | Filters, calculations and date boundaries | That the business definition is correct |
| Source tables | Whether the intended dataset was used | That the source is complete or current |
| Returned row count | The size and shape of the output | Rows scanned or whether a join inflated a total |
| Runtime | How long this execution took | Accuracy, scan volume or total cost |
Ten result rows may come from many more source records. A single revenue total can include duplicated amounts even though its output has one row. Check truncation warnings and query limits directly; row count alone does not prove that all matching results were returned.
An example: two revenue definitions
Take two customers:
| Customer | Completed sales | Refunds | Sales after refunds |
|---|---|---|---|
| North Shop | 1,200 | 200 | 1,000 |
| River Shop | 1,100 | 0 | 1,100 |
North Shop leads by completed sales; River Shop leads after refunds. Both rankings can come from valid SQL. Ask “Rank customers by completed sales less refunds for 1 April through 30 June 2026, in EUR” when that is the definition you need.
Check the source tables and date range. For an important figure, have a reviewer confirm that refunds were counted once and attached to the intended reporting period. The answer-verification guide separates business checks from technical checks.
A worked example: monthly revenue, checked in four looks
The example below uses a retailer’s customers, orders and order_items tables.
Question: “Show monthly completed order value for the last six complete calendar months, before refunds.”
Assume every line-item price is in EUR. Here is a PostgreSQL query for it:
SELECT
date_trunc('month', o.ordered_at) AS month,
SUM(oi.quantity * oi.unit_price) AS revenue
FROM orders AS o
JOIN order_items AS oi ON oi.order_id = o.order_id
WHERE o.status = 'completed'
AND o.ordered_at >= date_trunc('month', CURRENT_DATE) - INTERVAL '6 months'
AND o.ordered_at < date_trunc('month', CURRENT_DATE)
GROUP BY 1
ORDER BY 1;
Before saving the monthly chart, review these four choices:
- Which tables? Revenue was computed from
ordersjoined toorder_items— raw transactional tables. If your team’s revenue definition lives in a modeled mart, this answer used a different source, and the sources line says so before you present the number. - Gross or net? The query sums every line item on completed orders. Refunds are not subtracted —
status = 'completed'says nothing about later refunds. This is a gross figure, and only the query text tells you that. - Which window? “Last 6 months” was read as the last six complete calendar months, excluding the current partial month. Defensible — but if you meant “including this month so far,” the two
date_truncboundaries are where you would see the difference. - Which currency?
unit_priceis summed as-is. If the retailer sells in more than one currency, this silently adds euros to dollars — a problem to resolve with an explicit currency filter or an agreed conversion method.
Business users can confirm the reporting definition and source; analysts can inspect the filters, calculation and join. Work through the checks in how to verify AI data answers.
Reading the query as a business user or an analyst
The two readers contribute different knowledge. A sales manager may know that an order becomes reportable only after dispatch. An analyst can confirm whether status = 'completed' represents that event and whether one order can join to several invoice records. Neither the status name nor successful execution settles the definition on its own. Recording the agreed meaning as schema context and business definitions lets the next question start from it.
For an analyst investigating a change, the executed query is a starting point for further work: inspect a customer segment, reconcile a subtotal, or reproduce the calculation in a SQL editor. For a business user preparing a recurring report, a useful outcome is a checked table or chart that can be reopened with its question and source information.
If the number differs from an existing dashboard, compare definitions, refresh times and access permissions before deciding which answer is wrong. A live query reads what is available at execution time; it cannot make an upstream import complete or correct a stale source.
Requirements worth checking before choosing a tool
| Requirement | What to ask for in a demonstration |
|---|---|
| Database access | A connection using the permissions your database owner permits |
| Query review | The executed statement, including filters, limits and any revision after an error |
| Reuse | Reopening a result, saving a chart and understanding what refresh reruns |
| Collaboration | The actual export or sharing workflow available on the chosen plan |
| Data handling | What goes to the model, what is stored and how access is restricted; see read-only AI analytics controls |
| Fit for analysts | A realistic join, a time-zone boundary and an ambiguous metric from your schema |
Use the same questions across the products you evaluate. An SQL editor, a BI assistant and a conversational analytics service can overlap in natural-language querying while offering different reporting and administration workflows.
How do you evaluate a tool?
Ask the vendor to show an answer to a question you choose, with its executed query visible. Change a condition, such as excluding cancelled orders, and examine the result. Check whether you can reopen the original answer and identify its sources.
Compare access requirements, supported sources, query review, saved reporting and sharing. Other products can expose SQL too; assess the complete workflow. Text-to-SQL explained describes the underlying capability without assuming every product implements it the same way.
Using this workflow in Datarelix
Connect a database you are authorised to read, ask a question, and open its query and source information. Useful charts can be saved to a dashboard and refreshed on demand. Results and the run record are stored so you can return to them.
Connections, conversations and dashboards remain private to their creator’s account. Export results or charts for review; a saved dashboard is not a shared team workspace. See features and data handling before choosing a workflow.
Start with the quickstart and a question you can compare with an existing report. Review the interpretation before relying on the number.