Reading an Answer

Every answer ships with its own evidence. Reading that evidence takes about ten seconds and is the difference between a number you can present and a number you are hoping is right.

What arrives with an answer

The prose. One or two sentences answering the question you asked.

The queries. Every SQL statement it ran, in order, expandable. A question often takes more than one: look at the schema, sample a table, then answer.

The rows. The actual result set of the final query, as a table, with real column names. Not a summary — the rows themselves.

A chart, where the shape of the data supports one. Drawn from those rows.

Follow-up prompts — the next questions this answer raises.

How to sanity-check in ten seconds

1. Read the WHERE clause. This catches the most common problem by far: a time window or a campaign filter that is not the one you meant.
2. Check the row count against the prose. “Three keywords fell” should sit above three rows. A mismatch is the clearest possible signal.
3. Look at what it grouped by. An average across campaigns and an average within one campaign are different numbers with the same name.

Confidence is not accuracy

A model will describe a wrong result as fluently as a right one. The prose cannot tell you which you have; the query can. When a figure is going into a client report, read the SQL.

When an answer looks wrong

Usually the question was ambiguous rather than the data being bad. In order of likelihood:

What you see	Usual cause
Numbers lower than expected	The window excluded runs you had in mind
Numbers higher than expected	Several campaigns were included, not one
“No results”	Nothing was tracked for that keyword, or in that window
A column you did not expect	Your phrasing matched a different table

Ask the follow-up rather than rewriting from scratch — “only campaign X” or “since 1 August instead”. The context is kept, so a correction is one line.

Empty answers

If the query genuinely returns nothing, you get told that rather than given an invented summary. An empty result is a real answer: it usually means the data was never collected, not that the number is zero.

The same data, through an agent

Data Chat reads exactly the same catalogue the MCP server exposes to external agents, under the same read-only role and the same row-level security. If you would rather ask from Claude or Cursor than from the app, query_sql reaches the same tables with the same guarantees.

What it costsBilling follows the real cost of the question.