AI prompts for data analysts
Last updated
Analysts get the most from AI before and after the query — turning vague stakeholder asks into analysis plans, reviewing SQL for silent logic bugs, choosing charts on communication grounds, and writing insights where every claim carries its number. The model never touches your data warehouse; it sharpens everything around it.
The recurring discipline: schema and question in, assumptions surfaced, and "the data doesn't show that" as a legitimate — encouraged — output.
How to prompt as a data analyst
- Paste the schema (tables, columns, grain, known quirks) — SQL written against imagined schemas is the top failure mode.
- Translate the stakeholder ask first: "why did churn spike?" becomes hypotheses and cuts before it becomes queries.
- Aggregates over raw rows in consumer tools; row-level customer data stays in governed environments.
- Demand uncertainty language: "n=23 in this segment" changes what a difference means — make the model say so.
The five templates
"Can you look into why signups dropped?" — the ask is a feeling; the plan makes it answerable.
Turn this stakeholder ask into an analysis plan: "[PASTE THE ASK VERBATIM]". Context: [PRODUCT/BUSINESS, THE METRIC'S DEFINITION, WHAT CHANGED RECENTLY, DECISION THIS INFORMS]. Available data: [TABLES/SOURCES + GRAIN, ROUGHLY]. Deliver: 1) the decision-relevant question, restated precisely (what would we DO differently depending on the answer?); 2) 4–6 testable hypotheses, ranked by prior plausibility, each with: the cut/comparison that tests it, the data needed, what result would confirm vs. kill it; 3) known confounders to control (seasonality, mix shifts, tracking changes); 4) the order to test them (cheapest-informative first); 5) 3 clarifying questions for the stakeholder before I start. Do not write SQL yet.
The query runs and returns numbers. Whether they're the right numbers is a different question.
Review the SQL below against the schema and intent. Report everything suspicious with confidence labels — I filter, you don't. Hunt specifically: 1) join fan-out (grain changes that inflate counts/sums); 2) NULL handling in filters and aggregations; 3) date-boundary bugs (timezones, half-open vs. closed intervals, "last 30 days" definitions); 4) filters that silently drop rows (INNER JOIN as accidental filter); 5) window/aggregate mixing; 6) whether the query matches the stated intent at all. For each finding: the line, why it's wrong or risky, the concrete scenario where it produces a wrong number, and the fix. Intent: [WHAT THE NUMBER SHOULD MEAN, PRECISELY] Schema + grain: [TABLES, KEYS, ONE ROW = WHAT] SQL: [PASTE]
The finding is solid; the default bar chart isn't. Choose the visual on communication grounds.
Recommend the visualization. Finding: [THE INSIGHT IN ONE SENTENCE, WITH NUMBERS]. Audience: [EXEC / PM / TECHNICAL]. Medium: [SLIDE / DASHBOARD / DOC]. The action we want from the reader: [WHAT THEY SHOULD DECIDE/DO]. Deliver: 1) top recommendation with WHY (what comparison the chart type makes easy — that's the criterion); 2) runner-up and when it'd be better; 3) the trap chart people would default to here and why it misleads; 4) spec for the winner: axes, scale (zero-based? log?), sorting, annotation text (write the actual annotation), what to grey out, title as the takeaway sentence (not "Revenue by Month"); 5) accessibility: color choices safe for color-blind readers. Data shape: [PASTE AGGREGATED DATA OR DESCRIBE: DIMENSIONS × MEASURES]
Analysis done. Now the paragraphs — where precision usually dies of enthusiasm.
Write the findings section from my results below. Audience: [WHO]. Decision context: [WHAT THIS INFORMS].
Rules: every claim carries its number and comparison base; effect sizes with denominators ("+40 % = from 5 to 7 per week"); uncertainty stated where n is small or the window short — n in parentheses; correlation language unless the design supports causal language — if I wrote "drove/caused" without a causal design, downgrade it and tell me; anything the data does NOT show but readers will assume goes in a "What this doesn't tell us" box.
Format: 1) three-sentence summary (finding, size, recommended action); 2) findings, one paragraph each; 3) the doesn't-tell-us box; 4) next analysis worth doing.
Results (tables/aggregates):
[PASTE]
The number looks surprising. Surprising numbers are either insights or bugs — check before the CEO quotes it.
Sanity-check this result before I publish it. Result: [THE NUMBER + WHAT IT CLAIMS]. How it was computed: [QUERY LOGIC / STEPS IN PROSE]. Base rates and priors: [WHAT'S NORMAL FOR THIS METRIC, LAST PERIODS]. Work through: 1) magnitude check — is this plausible against the priors? Show the quick math; 2) the 5 most likely ways this number is wrong (definition drift, population change, tracking gaps, mix effect, denominator shifts) — rate each likely/unlikely HERE with reason; 3) the 3 fastest falsification checks I should run (queries described in words) before believing it; 4) if it survives: how to phrase the caveat that still applies. Be the skeptic, not the cheerleader — your job is to kill this number if it can be killed.
Frequently asked questions
Can I let AI write my SQL from scratch?
With the real schema pasted, first drafts are decent — but the review template matters more than the writing one: fan-out, NULL and date-boundary bugs return plausible wrong numbers, and models commit them too. Draft with AI if you like; review with AI always; validate against known totals regardless.
Is it safe to paste query results into AI tools?
Aggregates and anonymized cuts: generally yes under company policy. Row-level personal data: no — that belongs in governed environments (some warehouses now embed assistants inside the governance boundary). All five templates work on aggregates by design.
Can AI find insights in my data automatically?
It can suggest hypotheses and patterns when you describe or paste aggregates — but "insight" means decision-relevant, verified, and caveated, which is the analyst's chain. The plan → check → write-up templates keep AI in that chain instead of replacing it with confident pattern-matching.
Which template pays off first?
SQL review — silent logic bugs are the profession's most expensive failure and the review takes two minutes per important query. Close second: the sanity check, the first time it stops a wrong number from reaching a slide.