Best Claude Prompts for Data Analysis: 20 Copy-Paste Templates (2026)

The best Claude prompts for data analysis are the ones that make Claude state its assumptions before it computes anything. These 20 templates are built around the real workflow: planning an exploration, writing and explaining SQL, profiling and cleaning a file, reading trends and cohorts, deciding whether a change is real, and summarizing for stakeholders. Each prompt gives Claude the analyst role and asks for reasoning and caveats, so you get analysis you can defend instead of confident numbers with hidden flaws.

That habit is worth forming on purpose. State the grain you want, the date range, and how nulls and duplicates should be treated, and most of the queries that would have quietly double-counted never get written.

Which prompt to use for which job

• You have a question but no plan yet: start with the exploratory analysis plan, or the vague-request translator if the question came from someone else.
• You have a warehouse and need SQL: the SQL query builder for a known table, the long-schema join prompt when you do not yet know where the data lives, and the metric definition prompt when the number has to match someone else's.
• You have a file: profile the CSV first, write the cleaning plan second, and only then ask for patterns. Skipping the profile is how a date column stored as text ends up sorted alphabetically in a chart.
• A number moved: the anomaly triage prompt before anything else, then the is-the-difference-real prompt, then the statistical sanity check.
• You need to explain it: the plain-English explainer for yourself, the stakeholder summary for the room.

If you only keep five

Twenty templates is a library; most weeks need five. If you are starting from nothing, save these first, in this order:

1. Profile an uploaded CSV before touching it. Row counts, types, nulls, duplicates, and date ranges before any question. It catches the date-stored-as-text and duplicated-export errors that make every later number wrong.
2. SQL query builder. The workhorse. The version on this page asks for assumptions, the query, and the ways it could still be wrong, which is what makes it reviewable.
3. Triage a metric that suddenly moved. The most common urgent request in any analytics job, and the one most often answered with a story instead of a check.
4. Decide whether the difference is real. Stops a two-point wobble from becoming a slide.
5. Stakeholder summary. The analysis is not finished until someone who did not do it can act on it.

The other fifteen cover the cases these five do not: long schemas, cohort tables, funnels, survey coding, metric definitions, and translating a vague request into a plan.

A weak data analysis prompt, and the same prompt fixed

Most bad Claude output in data work comes from the prompt, not the model. Here is a typical first attempt:

Analyze this sales data and tell me what's interesting.

Claude will answer, and the answer will read well, but it has to guess the question, the grain, the time range, what counts as a sale, and what "interesting" means to you. Every guess is a place the analysis can be confidently wrong. The same request, fixed:

<role>You are a senior analyst preparing a weekly sales review.</role>
<data>Attached: orders_2026q3.csv, one row per order line. Columns: order_id, order_date (UTC), customer_id, sku, qty, unit_price, refunded (bool).</data>
<question>Which product lines grew or shrank in September versus August, and is any change large enough to act on?</question>
<constraints>Revenue = qty x unit_price, excluding refunded lines. Compare full calendar months only. Treat each order_id as one order even when it has several lines.</constraints>
<output>Profile the file first and stop if anything looks wrong. Then a table of product lines with August revenue, September revenue, and change. Then the two changes you would investigate, and two ways this comparison could mislead.</output>

The second version is longer, and it takes about a minute to write. It removes five guesses, tells Claude to stop on bad data instead of working around it, and asks for the result in a shape you can check. Every template below follows the same pattern.

How to structure a Claude prompt for data analysis

Anthropic's own prompting guidance recommends XML tags to separate the parts of a long prompt, and it matters more for data work than for most tasks, because a schema, a data sample, and your instructions all look like text to the model. Tags keep Claude from treating a column comment as an instruction or a sample row as the question. A full prompt looks like this:

<role>You are a senior analyst reviewing a query before it goes into a board deck.</role>
<schema>[paste CREATE TABLE statements or column lists]</schema>
<question>Monthly active customers for Jan to Jun 2026, excluding test accounts, one row per month.</question>
<constraints>Grain is customer-month. Time zone is UTC. A customer is active if they placed at least one paid order in the month.</constraints>
<output>State your assumptions first, then the query, then two ways the result could still be wrong.</output>

The last tag does the most work. Asking for assumptions before the query forces Claude to commit to a reading of the question you can correct in one line, instead of burying that reading inside a join you would have to reverse-engineer.

Claude with a file versus Claude with a schema

These are two different jobs. When you attach a CSV or spreadsheet and code execution is on, Claude computes the numbers by running code, and you can ask to see that code and rerun it. When you paste a schema, Claude cannot touch your warehouse at all: it writes SQL you run yourself, and every number it quotes afterwards is one you pasted back. Mixing the two up is the most common source of confidently wrong answers, where Claude reasons about what the data probably says rather than what it does say. If you want a number, give it the data or run the query. If you want a plan, a query, or a critique, the schema is enough.

Excel workbooks need one extra step. Ask Claude to list the sheets, the header row of each, and any merged cells or multi-row headers before it computes anything, because a summary row at the bottom of a sheet or a header split across two rows will be read as data and quietly skew every total.

Claude prompts for data analysis in Claude Code

A third way to work is Claude Code, Anthropic's agent harness that runs in your terminal. It reads the files in a folder, writes and runs Python or SQL against them locally, and shows you each command before it runs. For data analysis this removes the upload step and the file size ceiling of a chat window: point it at a folder of exports, ask a question, and it profiles the files, writes a script, runs it, and reports the result with the script saved next to the data so the number can be reproduced.

The prompts on this page work there unchanged, with two additions that matter for agent runs. First, require it to save every script it runs, so the analysis is auditable rather than a transcript. Second, tell it which files are read-only, because an agent that cleans a CSV in place has destroyed your raw data.

If you run analyses often, define a reusable data-analyst subagent once. Claude Code reads subagents from markdown files in .claude/agents/, and the frontmatter limits which tools it can use:

---
name: data-analyst
description: Profiles data files, writes and runs analysis scripts, and reports findings with caveats. Use for any question about files in data/.
tools: Read, Glob, Grep, Bash, Write
---
You are a careful data analyst. Before answering any question:
1. Profile the relevant files: row counts, column types, nulls, duplicates, date ranges.
2. State the grain and the assumptions you are making, and stop to ask if one is ambiguous.
3. Write every analysis as a script in analysis/ and run it. Never edit files in data/raw/.
4. Report the answer first, then the script path, then two ways the result could be wrong.

The last step mirrors the XML prompt above: the answer arrives with its evidence and its weak points, which is what makes it safe to forward. Scientific data is getting its own environment as well: Claude Science bundles datasets, tools, and figure generation for researchers, and the same profile-first, assumptions-first prompts carry over to it. For a long session over many files, keep the definitions and decisions in a notes file as you go, since context compaction summarizes older turns once the window fills and the metric definition you agreed on early is exactly the kind of detail a summary drops.

Five mistakes that make an analysis wrong

1. Fan-out joins. Joining orders to order items and then summing order revenue counts each order once per item. Ask Claude to name the grain of every join.
2. Partial periods. Comparing this week, three days in, against last week's full seven. The weekly trend prompt asks for partial periods explicitly.
3. Time zone boundaries. Events logged in UTC and reported in local time shift a slice of every day into the neighbouring one, which is enough to move a daily metric by several percent.
4. Mix shift read as behaviour change. Conversion falls because a new channel sent lower-intent traffic, not because the product got worse. The cohort and funnel prompts both ask for the split that exposes this.
5. Tracking changes read as real changes. A new event name or a consent banner change can halve a metric overnight. That is why the triage prompt checks the pipeline before the product.

If the work is hands-on with a file and you would rather stay in one tool, the companion ChatGPT prompts for data analysis pack covers the same half of the job from the other side. When the data is survey answers or interview notes rather than events, the ChatGPT prompts for market research pack picks up the synthesis. When the analysis turns into a script somebody else has to maintain, the Claude prompts for coding pack takes over, and when the findings have to become a memo, the Claude prompts for writing pack has the edit passes that keep a readout honest. When a query or summary format works, turn it into a reusable template with Prompt Builder so your analyses stay consistent across the team.

You are a senior data analyst. I have a dataset about [describe data and columns] and this question: [your question]. Propose an exploratory analysis plan: what to check first, which relationships to test, what could mislead me, and the order to do it in. Do not write code yet, just the plan and your reasoning.

Write a SQL query for [database type] that answers: [describe precisely]. Here is the relevant schema: [paste tables and columns]. Show the query, explain each part, and note any assumptions about the data. Flag edge cases like nulls or duplicates that could change the result.

Here are my analysis results: [paste numbers or output]. Explain what they actually mean in plain language, what they do not mean, and how confident I should be. Point out any way these numbers could be misread.

Review this data sample and summary stats: [paste]. List likely data quality issues such as outliers, missing values, inconsistent formats, suspicious distributions, or duplicates. For each, explain the risk and how I would check it. Be skeptical.

Summarize this analysis for a non-technical stakeholder: [paste findings]. Lead with the single most important takeaway, give 2 to 3 supporting points in plain language, state the main caveat, and recommend a next step. No jargon, no charts described in detail.

I want to measure [goal, e.g. user engagement]. Suggest 3 candidate metrics, explain what each captures and misses, warn me about ways each could be gamed or misleading, and recommend one with your reasoning. Context: [paste].

I am about to conclude [claim] based on [describe the analysis and data]. Play skeptic. What assumptions am I making, what could explain this result besides my hypothesis, is the sample adequate, and what would change your mind? Be direct.

Here is a data table: [paste]. Identify the 3 most interesting patterns, the most surprising thing in it, and one finding that is probably noise rather than signal. Explain how you would verify each before trusting it.

A stakeholder asked: '[their vague question]'. Help me turn this into a concrete analysis: clarify what they likely want to know, list the questions I should ask them, define the metrics and data needed, and outline the steps to answer it.

Explain what this analysis code does at three levels: a one-sentence summary, a paragraph for a colleague, and a walkthrough of the tricky transformations. Note any assumptions or steps that could introduce bias. Code: [paste].

Here is the schema of our warehouse: [paste table and column definitions]. I need to answer: [question]. Tell me which tables hold the answer, the join path between them, which keys are safe to join on and which will fan out rows, and what grain the result will be at. Name every place this join could silently double-count, then write the query.

Metric [name] moved from [before] to [after] between [period A] and [period B], on [sample sizes]. Is that difference meaningful or is it within normal variation? Show the calculation. Then list what else changed in that window that could explain it (seasonality, a mix shift, a release, a tracking change), and tell me what to check before I put this number in front of anyone.

I have attached [file name]. Before any analysis, profile it and change nothing. Report the row count, every column with its inferred type, the share of nulls per column, distinct counts, min and max for numeric and date columns, and the five most frequent values for text columns. Flag any column whose type looks wrong (dates stored as text, IDs parsed as numbers, currency with symbols), any column that is constant, and any pair of columns that look like duplicates of each other.

Based on this profile of my data: [paste profile or attach file], write a cleaning plan as a numbered list. For each step give the transformation, the rows or values it affects with a count, and what information is lost if I apply it. Do not apply anything. Mark every step where a reasonable analyst could choose differently, and tell me the choice you would make and why.

Here is a weekly series of [metric] for the last [N] weeks: [paste date, value]. Separate the long-run trend from seasonality and one-off spikes. Tell me the normal week-to-week range, whether the latest week falls outside it, and whether any week in the series is partial or affected by a holiday. End with one sentence I could say in a meeting without overstating it.

Here is a cohort retention table, rows are signup [week or month], columns are periods since signup: [paste]. Identify cohorts that retain meaningfully better or worse than their neighbours, say whether the difference shows up in the first period or later, and list the explanations to test in order: acquisition channel mix, a product release, pricing, seasonality, or a tracking change. For each, name the column or table I would need to confirm it.

Here are step counts for our [funnel name] funnel over [period], split by [device, channel, country]: [paste]. Compute step-to-step conversion for each split, point to the step and segment with the biggest loss versus the overall rate, and tell me whether that loss is large enough in absolute users to matter. Then list what would have to be true in the product for that pattern to appear, so I know what to go and look at.

[Metric] moved from [usual level] to [new level] on [date]. Give me a triage list in the order I should check it, starting with the causes that are most common and cheapest to rule out: tracking or pipeline change, a late or duplicated data load, a time zone or date boundary shift, a filter change in the dashboard, a bot or test traffic spike, then real behaviour change. For each, write the query or check that would confirm or rule it out against this schema: [paste relevant tables].

Write a precise definition for the metric [name], as we use it to answer [decision it supports]. Include the numerator and denominator, the grain, every filter and exclusion (test accounts, refunds, internal users), how nulls and late-arriving data are treated, the time zone, and three edge cases with the correct handling for each. Then write the SQL for it against this schema: [paste]. Flag any part of the definition I have not given you enough information to settle.

Here are [N] open-ended answers to the question '[survey question]': [paste]. First read the first 50 and propose a codebook of 6 to 10 themes, each with a one-line definition and an example quote. Then apply it to every answer, allowing up to two codes per answer. Report the count and share for each theme, list the answers you could not code confidently, and quote the three answers that best represent the largest theme.