Prompts for data analysis that show their working

Three customers pay £20, £30 and £50 a month. The £50 one cancels. What's your churn rate?

It's 33% if you count customers and 50% if you count revenue (ChartMogul's worked example). Both are correct. Ask ChatGPT or Claude "what's our churn?" over that data and you'll get one of them, stated with confidence, usually without a word about the other. Stripe's own Billing formula adds new subscribers to the denominator, which gives a third figure (Stripe Support).

That is the commonest way AI data analysis goes wrong, and it isn't a hallucination in the usual sense. The arithmetic can be perfect. The model has simply chosen a definition, a filter or a time window on your behalf and not told you.

The other failures are better known. Language models doing maths in their heads are unreliable: GPT-4 got 59% of three-digit-by-three-digit multiplications right without tools (Dziri et al., 2023). They're also easily thrown: adding one irrelevant clause to a maths problem cut accuracy by up to 65% in Apple's tests (Mirzadeh et al., GSM-Symbolic, 2024), and real exports are full of irrelevant columns.

So the prompts below share five rules:

• Profile first. Make the model describe the data before it analyses it.
• Define before calculating. One line per metric, saying which definition.
• Compute in code, from totals. Both OpenAI and Anthropic offer a code tool for exactly this.
• Label data versus assumption. Every statement says which it is.
• Name what's missing. A gap reported is better than a gap filled.

They're written for ChatGPT's data analysis or Claude with code execution switched on, but they work in any assistant that can run code.

Before answering any question about the attached file, profile it using code. Report:
- row count, column names and the type you inferred for each
- the date range covered, and any gaps in it
- columns with missing values, and how many
- duplicate rows, and whether there's a column that looks like a unique ID
- any values that look like totals or subtotals mixed in with the data rows
- currencies or units, if you can tell

Then list anything about the data that would change how a question should be answered. Don't analyse anything yet.

Why each line is there: the row count is the number you'll check every later answer against. Date gaps catch the month that didn't export. The subtotal line catches the most expensive mistake in spreadsheet analysis: a "Total" row summed into the total. "Don't analyse anything yet" stops the model racing ahead to a chart before you've seen what it's working with.

Read the profile. It takes thirty seconds, and it's the only point at which you see the data the way the model sees it.

Profiling shows you the data. It doesn't show what the model does with it later. Count connects to Claude and shows the query or calculation behind every number in the analysis that follows.

I want [metric] for [period], from the attached data.

Before calculating, state in one line each:
1. The definition you will use, and the formula.
2. Any other common definition that would give a different number, and roughly how.
3. The exact filters: which rows, which dates, which statuses are included or excluded.
4. Which columns in the file you'll use for each part of the formula.
If anything in 1–4 is a guess because the data doesn't say, mark it [ASSUMPTION].

Then stop and wait for me to confirm before calculating.

Line 2 is the one doing the work. It forces the model to admit that the metric is ambiguous before it commits. The pause at the end turns a silent choice into a question you answer.

Metrics where this matters most:

The bounce-rate row is a classic trap for AI: ask "is our bounce rate good?" and a model may compare a GA4 figure with benchmarks written in the Universal Analytics era, which measured something else.

Calculate [metric] using the definition we agreed. Use code, not mental arithmetic.

Show:
- the code you ran
- the numerator and denominator as totals, with the row count behind each
- the result

If the metric is a ratio (ROAS, conversion rate, margin, churn), compute it from summed totals for the whole period. Do not average daily, weekly or per-segment ratios. If you also show a breakdown, check that the segments sum to the total and say if they don't.

The averaging line exists because it's an easy error to make and a hard one to see. An illustrative example: on Monday you spend £100 and earn £500 (ROAS 5.0); on Tuesday you spend £900 and earn £900 (ROAS 1.0). The average of the daily ROAS figures is 3.0. The real ROAS for the two days is £1,400 / £1,000 = 1.4. Same data, an answer more than twice as good as the truth.

Showing numerator and denominator separately is what makes the result checkable: you can compare each with the profile from prompt 1 in seconds. OpenAI's docs recommend explicitly asking for "the python tool" when you want code used (OpenAI, Code Interpreter); Claude's code execution tool exists for the same reason, to "perform complex calculations" in a sandbox (Anthropic).

The riskiest prompt in analysis is "why did X go down?", because the data rarely contains the answer and the model will offer one anyway.

[Metric] moved from [A] to [B] between [period 1] and [period 2]. Using only the attached data, explain what changed.

Tag every sentence:
[DATA] stated directly by the data, with the figure and the filter
[CALC] calculated from the data, with the calculation
[ASSUMPTION] a plausible explanation the data doesn't confirm
[MISSING] something we'd need to know that isn't in the file

Break the change down by the segments available (region, channel, product, plan) and say which segment accounts for most of it. Don't give a reason for the change unless the data shows it; otherwise list it as an [ASSUMPTION] and say what data would test it.

The tags turn one persuasive paragraph into four lists of different strength. In practice, the [ASSUMPTION] list is where the interesting work starts, and the [MISSING] list tells you what to pull next. If an answer comes back with no assumptions at all, be suspicious rather than pleased.

Text-to-SQL looks solved on academic benchmarks and isn't on real schemas. On Spider 2.0, built from enterprise databases, the best agent in the original paper solved 21.3% of tasks against 91.2% on the older Spider 1.0 (Lei et al., arXiv version). Tuned agent systems have since scored far higher on parts of it, but an audit found annotation errors in 62.8% of Spider 2.0-Snow items and 52.8% of BIRD Mini-Dev items (Jin et al., 2026). Even the benchmark answers pick one reading of an ambiguous question.

Write SQL to answer: [question].

Schema: [paste table definitions, with a one-line description of each table and any column whose meaning isn't obvious]

Before the query, list: the tables and joins you'll use and why; the grain of the result (one row per what?); every filter, including dates and statuses; anything in the question that could be read two ways, and which reading you chose.
After the query, add a check query that returns the row count and the unfiltered total, so I can compare.

The grain line prevents the double-counting that a bad join produces. The check query gives you a number to compare with what you already know. If the model can't say the grain, the query is a guess.

Prompts like these make errors rarer and much easier to see. They don't make the model reliable on hard data work. On SpreadsheetBench V2, 321 end-to-end business spreadsheet workflows, the top score on the official board is 34.89% (SpreadsheetBench, checked October 2026). Most of the work still needs a human to check it.

The check

1. Compare the row count in the answer with the profile. If they differ, find out why.
2. Read the definition line. Is it the one your team and your dashboard use?
3. Recompute one figure from totals in a spreadsheet. For a ratio, check it wasn't averaged.
4. Read the [ASSUMPTION] list, and ask: "What else did you assume that you didn't tag?"
5. Check one segment adds up to its share of the total.

Step four is the hardest to do by eye, because untagged assumptions look like data. That's what Count is for: connect it to Claude or ChatGPT and it splits the answer into claims, labels each as a citation, an assumption, model knowledge or a hallucination, and shows the query or calculation each one rests on. More on choosing a tool in Claude vs ChatGPT for data analysis and Claude data analysis.

What are good ChatGPT prompts for data analysis?

Can ChatGPT analyse a spreadsheet accurately?

How do I stop ChatGPT making up numbers in an analysis?

Should I give the AI raw data or a summary?