Technology · July 21, 2026 · 8 min read

Prompt engineering for data analysts: precise definitions, then distrust the number

For analysts, a good prompt is a precise metric definition — and the skill is distrusting the result until it holds up. A practical guide to AI-assisted analysis that doesn't ship a wrong number, with a worked example and how it's assessed.

For a data analyst, the output of an AI session is a number — and a number gets pasted into a deck and turned into a decision. That raises the stakes on prompting in a specific way: the failure mode isn't ugly code, it's a plausible figure that quietly doesn't add up. This is the analyst entry in our per-role prompt engineering series, and it's one of the clearest things the AI Sandbox surfaces.

A good prompt is a precise definition

The research on reducing hallucination in analytical work all points the same way: specificity and boundaries beat clever wording. A vague ask — 'give me revenue by month' — invites the model to pick a definition for you, and it will pick a plausible wrong one. A strong analyst writes the metric, the exclusions and the source of truth into the prompt, and gives the model explicit permission to push back rather than guess. That's AI fluency in an analyst's seat: the prompt and the analytical rigor are the same act.

A worked example

Ask for net revenue by month. The weak version stops there. The strong version defines 'net,' names the exclusions, specifies which timestamp counts as the month, and tells the model to flag anything it can't find rather than inventing a column name. Then — the part that actually matters — the analyst sanity-checks the result against a figure they already trust before it leaves their screen.

## TASK
Write SQL: net revenue by calendar month for 2025.

## DEFINITIONS
- net revenue = gross - refunds
- Exclude internal test accounts (email domain @acme-internal.com)
- "Month" = orders.completed_at, not created_at

## RULES
- If a column I named doesn't exist, tell me — do not guess a name
- Return the query, then list every assumption you made

• Good: specifies the metric, the exclusions and the source of truth; sanity-checks the output; distrusts a number the data doesn't support.
• Weak: accepts a plausible query, reports a figure that quietly double-counts refunds, and never notices.

Best practices that actually move the needle

• Define before you ask. Put the metric definition, exclusions and time grain in the prompt — ambiguity is where wrong numbers are born.
• Give permission to say 'I don't know.' Tell the model to respond with 'not enough data' or 'that column doesn't exist' instead of guessing. It hallucinates far less when refusal is allowed.
• Ask for the assumptions. Have it list what it assumed — that's where you'll spot the misread definition.
• Sanity-check every output against a number you already trust. A figure that doesn't reconcile is the finding, not a rounding error.

Common failure modes

• Vague metric: 'revenue' with no definition, so the model quietly picks one.
• Trusting the number because the query looks clean — clean SQL on a wrong definition is still a wrong answer.
• Never reconciling against a known-good figure, so the mistake ships as a fact.

How we assess it

You can't test this with a prompt-trivia quiz, and you can't test it by taking AI away — that just measures a task nobody does that way anymore. You give the candidate a realistic analysis task with tools available and watch whether they define the metric, catch the misleading aggregate, and stand behind a number that actually holds up — which is what an AI Sandbox assessment does, and how AI fluency is scored as a pillar. See what a full data analyst assessment covers, why this is the honest test in AI-native hiring, or watch a role-tuned assessment get composed.

The best analysts treat the AI's answer the way they treat any surprising number: guilty until reconciled. That instinct — not prompt phrasing — is what keeps a wrong figure out of the boardroom.