tellaprompt

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

From stakeholder ask to analysis plan

"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.
SQL review (the silent-bug hunt)

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]

Why this works: The named bug taxonomy (fan-out, NULLs, date boundaries) points the review at where analytical SQL actually breaks — silently, with plausible output.

Context firstBrutal criticFact density

Chart choice with justification

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]

Why this works: Choosing by which-comparison-gets-easy is the actual theory of chart choice; takeaway-titles and written annotations move charts from decoration to argument.

Output formatContext firstFact density

Insight write-up that survives scrutiny

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]

Why this works: Denominator discipline and enforced correlation-vs-causation language are what let an insight memo survive the smartest skeptic in the room — and the doesn't-tell-us box preempts them.

Fact densityOutput formatBrutal critic

Result sanity check before it ships

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.

Why this works: Fermi-style magnitude checks plus a ranked wrongness taxonomy catches the classic false-insight causes in minutes — much cheaper than retracting a headline number.

Brutal criticFact densityTest & iterate

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.