Asking your data in plain English

The pitch for natural-language analytics is that anyone can ask a question and get an answer. The reality, after a couple of years of these tools existing, is more specific and more useful than that: a language model is very good at translating a question into a query, and it has no idea whether the answer means anything.

That distinction is the whole thing. Once you hold it clearly, you can tell which questions to ask a model and which to answer yourself.

What the model is actually doing

It is not reading your data. It is reading your schema — event names, property names, types, a handful of sample values — and writing a query, which a query engine then runs. The answer you see is the output of that query, not of the model.

Question   "how many teams that connected a data source last
            month ran a query in their first week?"

Resolves   data_source_connected   → event
           first_query_run         → event
           workspace_id            → grouping unit
           last month              → 2026-07-01 .. 2026-07-31

Query      funnel(
             steps: [data_source_connected, first_query_run],
             unit: workspace_id,
             window: 7d,
             cohort: signup_month = 2026-07
           )

Answer     612 of 1,004 workspaces (61.0%)

Every hard part of that translation depends on your instrumentation being legible. If your events are named onboarding_step_3 and evt_a, no model can resolve "connected a data source" to the right one, and it will pick something plausible and wrong. Natural-language analytics is downstream of a good event taxonomy, not a substitute for one.

Where it genuinely helps

• The question you would not have bothered to ask. Most analytical value is lost to friction: the question that would have taken twenty minutes to build gets dropped. Getting it in fifteen seconds changes how often people check rather than assume.
• Remembering the schema for you. Nobody holds two hundred event names in their head. Resolving a description to the right event is exactly the sort of fuzzy matching models are good at.
• Getting the shape of a query right. Funnel windows, cohort anchoring and unit selection are fiddly and error-prone. A tool that assembles them consistently makes fewer mistakes than a person in a hurry.
• The first ninety per cent of an investigation. Ask five variations quickly, find the one that looks interesting, then slow down and check it properly.

Where it does not

• Deciding whether the number is meaningful. A model will happily report a 40% lift computed on eleven users. Statistical judgement is not in the question you asked.
• Knowing what your data does not contain. If a release broke an event three weeks ago, the query returns a confident, wrong number, and nothing in the answer says so.
• Causal claims. "Why did signups drop?" is not a query. It is a hypothesis-generation problem, and the honest output is a list of things that also changed, not an explanation.
• Anything where the definition is contested. If your team has not agreed what activation means, a model picking one meaning per question is worse than no answer, because the inconsistency is invisible.

Show your work, or do not ship it

The single feature that separates a useful natural-language analytics tool from a plausible-sounding one is whether it shows the query it ran. Not a paraphrase — the actual events, filters, window and unit, in a form you can read and edit.

Without that, three things become impossible:

1. Checking. You cannot tell whether the model resolved "active users" to the definition you use.
2. Correcting. Rephrasing a question is a bad interface for fixing a window that should have been 14 days instead of 7.
3. Reusing. An answer you cannot save as a query is a one-off. The value compounds only when a good ad-hoc question becomes a scheduled report.

A visible query also changes the failure mode from "wrong answer" to "wrong question, obviously". That is a much cheaper kind of mistake.

How to ask a better question

Models are literal. Precision in the question does more for answer quality than any amount of prompt technique:

The pattern in the right-hand column: name the metric definition, name the period, name the segmentation. Those are the three things a query needs and a question usually omits.

A working habit

The practice that gets the most out of these tools is unglamorous. Ask the question in plain English. Read the generated query before reading the answer. If the query is wrong, edit it rather than rephrasing. If the answer is surprising, check the event volumes for the period before you believe it — most surprises are instrumentation, not behaviour. And when a question turns out to matter, save it as a report so it stops being a question.

Used that way, plain-English analysis does not replace anyone's judgement. It removes the twenty minutes of query-building that used to stand between having a question and having something to think about.