A Practical SOP for Data Analysis Prompts: Turn an LLM Into Your Data Analyst

Solo creators and small teams handle data every day. Why did yesterday's post tank? Which of three acquisition channels has the best ROI? Did last month's livestream GMV actually grow? A data analyst should answer these, but most small teams have no dedicated analyst, and nobody wants to learn SQL and pandas just to produce an ad-hoc report. So the workflow calcifies: an operator dumps data into Excel, drags out a pivot table, eyeballs a few numbers, and writes "up 2.3% MoM" on a hunch. The data is there; the conclusion is mush.

This piece does not teach you to build a complex data-analysis agent (that is the job of a separate ai-data-analysis-sop article, which uses Coze to spin up a 24/7 digital worker). It solves exactly one thing: handing you a copyable, variable-driven, ready-to-use data analysis prompt template. Fill in three variables--a dataset description (CSV header plus a few sample rows, or a database schema), a business goal, and your tool--and the LLM will reliably produce four deliverables: an analysis approach, executable SQL or pandas code, key insight directions, and visualization suggestions. It is not omniscient. But in a team without an analyst, it compresses the cost of "looking at the data" from two hours to twenty minutes.

Unlike other prompt templates on this site (such as cheatsheet-prompt-formula for general use, or prompt-code-review-debug-pack for code review), this one targets data analysis specifically. The core is a triple constraint--data context + analysis framework + output format--unpacked layer by layer below.

1. Scenario and Pain Points: No Analyst, But Data Every Day

See if these feel familiar:

• Solo creator doing content reviews: You export 30 days of article data from the official-account backend (reads/shares/completion/new followers) and want to know which topic type brings the most followers. Your pivot table shows the "workplace" tag gets reads but few followers, while "tools" is the opposite--but you cannot explain why, and you cannot decide what to publish more of next week.
• Small e-commerce checking ad spend: Three channels (Douyin Qianchuan, Xiaohongshu Juguang, WeChat Ads), and every weekend you merge spend, clicks, conversions, and ROI into one sheet. Manual stitching is slow, and you keep messing up the ROI denominator (spend divided by revenue, or by clicks?).
• Small SaaS team tracking retention: Login logs sit in the database. You want "Day-7 retention," but nobody can write that slightly tricky SQL, so the PM counts rows in Excel by hand and gets a number once a month.
• Livestream team reviewing sessions: After each stream the boss wants "why did this one pop / flop," but the data is scattered across the ops backend, script sheets, and product tables. Nobody can produce an attribution quickly.

The common thread: the problem is not hard, the data is right there, but nobody can translate data into conclusions. A dedicated analyst is expensive and hard to hire. In 2026, an LLM's code generation and statistical reasoning is enough to play "junior analyst"--if you know how to drive it.

Tossing data into ChatGPT and asking "analyze this" is usually a disaster: it invents numbers, writes code that will not run, and delivers platitudes that would fit any dataset. The problem is not the model; it is that your prompt gives it no constraints. That is what this SOP fixes.

One-line positioning: this is not "use AI to write SQL." It is a structured prompt that makes an LLM work like a data analyst who thinks before acting and keeps conclusions restrained.

2. The Principle: Why the Prompt Is Designed This Way

A good data-analysis prompt answers four questions: who the model plays, what context it gets, how it should think, and how it should deliver. Four design elements correspond.

2.1 Role: sets the professional tone and restraint

Giving the LLM a role "tunes" its output. Saying "you are a senior data analyst with 8 years of experience" makes the model invoke analyst norms from its training data: check the distribution before concluding, separate descriptive from diagnostic analysis, stay alert to outliers. Ask "analyze this table" with no role, and you get marketing-copy filler: "the data tells us..." with no substance.

The load-bearing sentence in the role is "conclusions must be backed by data; refuse to fabricate." This is not filler. It directly suppresses the LLM's worst habit--hallucinated statistics (covered in the pitfalls section).

2.2 Data Context: eliminates invented fields

When LLM-generated code will not run, nine times out of ten the model invented a field name. Given "a users table," it may write user_age or register_time--plausible columns that do not exist. The only real fix: paste the actual header (or schema) into the prompt verbatim.

Data context has three layers:

Many people paste only the header and skip the semantic layer, so the model treats order_status=3 as failed when 3 actually means "completed." The sample layer matters too: seeing created_at values like 2026-08-01 14:23:11 tells the model to parse dates; seeing blanks in amount tells it to handle missing values.

2.3 Framework: force it to think before doing

The beginner-prompt mistake is asking directly for "code" or "conclusions." A good analyst never types SQL first. They decompose the question: which metrics matter, which comparisons, where are the data traps? That "think first" step is the framework.

In this prompt the framework is explicitly split into four output sections: analysis approach -> code -> key insights -> visualization suggestions. The order is deliberate:

1. Approach first: forces the model to state "here is how I plan to analyze," exposing logic gaps before code is written and preventing query-bending to fit a pre-chosen conclusion.
2. Code in the middle: once the approach is set, code follows naturally. Requirements: comments, real fields only, print intermediate results for verification.
3. Insights last, and restrained: the insight section asks for "expected directions," not fabricated numbers--"if X trends Y, then Z." Because the model has not actually run code (unless you are in a code-execution environment), any number it gives is invented; only directions can be informative.
4. Visualization to close: charts are the communication language, but people forget to ask for them. Requiring "chart type + fields + what it shows + tool function" means you can draw immediately.

2.4 Output Format: makes results reusable

Format constraints solve "can I use this directly?" This prompt requires: four sections separated by ## headings, code blocks with language tags (sql / python), numbers to two decimals, field names kept in English. These let you paste output straight into your editor or BI tool without rework.

There is also a "tool adaptation" design: {tool} is one of SQL / pandas / Excel, and the prompt carries different execution assumptions for each (SQL assumes MySQL 8.0, SELECT only; pandas assumes df is loaded; Excel outputs formulas or Power Query). One template covers the three most common no-programmer analysis scenarios.

Design philosophy in one line: the prompt's entire bag of tricks is four constraints--role for tone, data context for disambiguation, framework for thought, format for reusability--turning a braggy chatbot into a think-first, restrained, code-that-runs junior analyst.

3. Step-by-Step: Fill Variables, Run the Prompt, Iterate

Here is the core deliverable--the copyable data analysis prompt template. Three variables are wrapped in {}: {dataset_description}, {business_goal}, {tool}. Paste it into any LLM (ChatGPT / Claude / Kimi / DeepSeek / Qwen all work).

3.1 The Copyable Prompt Template

# Role
You are a senior data analyst with 8 years of experience, skilled at turning raw data into actionable business decisions. You are fluent in {tool} (SQL / pandas / Excel formulas), habitually clarify the analysis framework before writing code, and insist that conclusions be backed by data and never fabricated. When uncertain, say explicitly "needs to be confirmed by running code"; never invent numbers.

# Data Context
{dataset_description}
(Paste here: CSV header + 3-5 sample rows, or a database schema: table/field/type/comment, plus field meanings and business definitions. Sample rows should use real structure but can be masked. Note any known data-quality issues here too.)

# Business Goal
{business_goal}
(State in one sentence what business question this analysis must answer, e.g. "find the main cause of last week's GMV drop" or "decide which acquisition channel has the highest LTV." You may add industry, product type, or recent actions as context.)

# Tool and Execution Environment
- Analysis tool: {tool}
- If {tool}=SQL: assume MySQL 8.0 syntax, output SELECT queries only, no DDL/DML, do not alter schema.
- If {tool}=pandas: output code runnable in Python 3.11 + pandas 2.x, assume df is already loaded by table name (for multiple tables: df_orders / df_users, etc.).
- If {tool}=Excel: output formulas or Power Query steps, noting which function and which range.

# Analysis Framework (output strictly in these four sections, each under a ## heading)

## 1. Analysis Approach
1. In 3-5 sentences, decompose the business question: which metrics to examine, which comparisons to make (YoY/MoM/grouping/funnel/cohort).
2. List key assumptions and potential data-quality issues (missing values/outliers/definition drift) and how you will handle them.
3. Give 2-4 progressively deeper sub-questions, from descriptive statistics to diagnostic attribution.

## 2. Code ({tool})
- Output directly executable {tool} code with comments.
- Use only fields that exist in "Data Context"; never invent column names. For uncertain fields, mark "TBD" in a comment.
- End code with print (pandas) or SELECT to surface key intermediate results for verification.
- If long, split into "data prep / metric calculation / result output."
- For pandas, start with `print(df.dtypes)` and `print(df.describe())` for a structure check.

## 3. Key Insights (Expected Directions)
- Based on what the code "should produce," give 3-5 insight directions in the form: "if metric X trends Y, then Z."
- Clearly mark which can be directly verified by data and which require business judgment.
- Offer 1-2 counterintuitive anomaly hypotheses worth digging into.
- Never fabricate any specific number; mark all numbers as "needs to be confirmed by running code."

## 4. Visualization Suggestions
- Recommend 2-3 charts, each specifying: chart type / fields used / what it shows / suitable tool function (matplotlib plt.bar, or SQL-then-Excel, or pandas df.plot).
- Suggest axis labels, title, and legend naming.

# Discipline
- Never fabricate any specific number; when uncertain, say "needs to be confirmed by running code."
- Field names must match Data Context verbatim.
- Output entirely in English, keeping code and field names as-is.

3.2 Step 1: Prepare the Data Context (the hardest, highest-value step)

This step makes or breaks the analysis. How to fill {dataset_description} for three common sources:

CSV / Excel export: copy the header row, then pick 3-5 representative sample rows (do not pick only clean rows--deliberately keep one with a blank or an outlier). Explain the fields in a short paragraph below. Example:

CSV header: article_id,title,publish_date,channel,reads,shares,completes,new_followers
Sample (5 rows):
1001,"5 Free AI Tools",2026-07-28,wechat,12034,892,0.62,213
1002,"A Week Coding with Claude",2026-07-29,xiaohongshu,8421,,0.55,156
1003,"",2026-07-30,wechat,0,0,0,0
1004,"LLM Selection Review",2026-07-31,zhihu,5610,233,0.48,87
1005,"SOP: n8n Support Bot",2026-08-01,wechat,9877,611,0.59,198

Field notes:
- channel: publish channel (wechat official account / xiaohongshu / zhihu)
- completes: completion rate (0-1 decimal, official-account backend definition)
- new_followers: net new followers attributed to this article
Known issue: row 1003 has empty title and reads=0; it is dirty data from a failed scheduled post and should be excluded.

Database schema: paste the CREATE TABLE statement or a field list with types and comments. Example:

Table orders: order_id BIGINT, user_id BIGINT, channel VARCHAR(32) COMMENT 'acquisition channel', amount DECIMAL(10,2) COMMENT 'order amount', status TINYINT COMMENT '1 pending 2 paid 3 completed 4 refunded', created_at DATETIME
Table users: user_id BIGINT, reg_channel VARCHAR(32), registered_at DATETIME, last_login_at DATETIME
Business definition: ROI = monthly transaction amount for that channel / monthly spend for that channel (spend lives in a separate spend table, not used here; ROI shows only the numerator).

Paste header + sample only, never the full dataset. Tens of thousands of rows pasted into a prompt blow past the token limit and add nothing--the model analyzes structure and samples, not row-by-row values. Real heavy lifting goes to the code it generates, run on your machine.

3.3 Step 2: Write a Clear Business Goal

The more specific {business_goal} is, the sharper the analysis. Compare:

• Bad: "Analyze this data." (You get generic descriptive stats, useless.)
• Good: "Find which channel had the highest follower-acquisition efficiency (new_followers / reads) in the last 30 days, judge whether we should double down there, and flag clearly anomalous articles."

A good goal has three parts: the question + the decision criterion + the output granularity. Adding industry context ("we are an AI-tools creator") and recent actions ("we tried Xiaohongshu last week") makes insights far more relevant.

3.4 Step 3: Choose the Tool Variable

Pick {tool} from three options based on data size and your skill stack:

Once filled, paste the whole prompt into the LLM.

3.5 Step 4: Read the Output and Iterate

The model returns four sections. Do not blindly copy the code; do three things:

1. Verify fields: scan field names in the code against your header, verbatim. The model still occasionally writes create_time instead of created_at; catch it and have it fix it.
2. Run the code: paste into your environment (DB / Jupyter / Excel). Code-execution tools like ChatGPT Advanced Data Analysis or Claude's analysis tool can run it directly; feed the real results back to the model.
3. Probe deeper: the first round gives framework-level conclusions. Pick the most interesting sub-question and push. For example: "You mentioned Xiaohongshu completion is low in part 2; dig into whether it correlates with publish hour, and give me pandas code grouped by hour." Multi-round iteration is the norm; one round will not yield deep conclusions.

Iteration mantra: round one for the right direction, round two for detailed code, round three for actionable insight. No single prompt extracts every conclusion.

4. Pitfall Quick Reference: Each With a Fix

LLM data analysis has four common traps that trip anyone trying to cut corners. Each has a symptom, cause, and fix.

Trap 1: Fabricated Data and Hallucinated Statistics

Symptom: before you have run any code, the model declares "Xiaohongshu ROI is 3.2, up 18% MoM." Those numbers are invented.

Cause: an LLM predicts the next token and prefers "complete-looking" answers. Asked for "analysis results," it generates a conclusion paragraph complete with numbers it never computed.

Fix: hard-code into the prompt "never fabricate any specific number; mark all numbers as 'needs to be confirmed by running code.'" This template already includes it. On output, treat any specific number that appeared without you running code as a hallucination; ask the model to convert it to an "expected direction." Trustworthy numbers come only from executing code yourself.

Trap 2: Code That Will Not Run (Invented Fields + Stale APIs)

Symptom: paste the model's pandas into Jupyter, get KeyError: 'user_age'--no such column. Or SQL uses DATE_FORMAT but your DB is PostgreSQL and wants TO_CHAR.

Cause: the model invents plausible field names; training data mixes APIs across libraries and versions (pandas 1.x patterns break on 2.x).

Fix: three moves together. First, paste the real header in data context and write "field names must match verbatim" in discipline. Second, specify library versions in the tool section ("pandas 2.x," "MySQL 8.0," "PostgreSQL 14") so the model adapts. Third, require the code to start with print(df.dtypes) for a structure check, so failures point immediately to fields or APIs. On error, paste the full traceback back to the model; it is good at fixing its own code.

Trap 3: Ignoring the Distribution, Averaging Outliers into Nonsense

Symptom: the model reports "average order value $256," but a single $9,900 enterprise order skewed it; the median is $89. The model never checked for outliers.

Cause: the LLM takes the shortest path--compute mean() and move on. It does not "look" at your data, only at field names.

Fix: force "descriptive statistics and outlier check first" in the framework. This template's code section requires print(df.describe()), and the insight section requires "flag counterintuitive anomalies." You can also add a line to the business goal--"exclude abnormally large orders"--and the model will switch to median/quantiles or filter first.

Trap 4: Long Data Exceeds Tokens, Forcing Truncation or Amnesia

Symptom: you try to paste a 50,000-row sales CSV into the chat. Either it exceeds the limit, or the model "remembers" only the first few thousand rows and ignores the rest.

Cause: LLMs have a finite context window (models range from 8K to over a million tokens, but more is slower, costlier, and attention degrades in long contexts). Pasting raw rows burns tokens for no gain.

Fix: always paste header + 3-5 sample rows only, never the full dataset. Have the model produce code; run that code on full data locally or in a sandbox. If the data is in a database, paste the schema and let the model write SQL for the DB to execute. This is the single most important principle of LLM data analysis: the model thinks and writes; your machine computes. With code-execution tools (ChatGPT's data analysis, Claude's analysis tool) you can upload the full file for the model to read via code, but skip hundred-megabyte monsters--sample or aggregate first.

Trap 5 (Bonus): Definition Drift--Right Number, Wrong Question

Symptom: the model reports "12,000 active users," the boss says it should be 8,000. The model counted "app opened"; the company defines active as "logged in and performed an action."

Fix: nail the business definition in the semantic layer of {dataset_description} ("active = user with >=1 behavior log that day"). Definitions are an analyst's lifeline; if the prompt does not pin them, the model guesses.

5. FAQ

Q1: I only have Excel and do not know SQL or Python. Is this prompt useful to me? Yes. Set {tool} to Excel and the model outputs formulas and Power Query steps with the target ranges noted. You just fill formulas into cells. For WPS or new Excel, paste the header plus a few sample rows into the data context; no coding required.

Q2: The model gave me conclusions with specific numbers, but I never had it run code. Can I trust them? No. Any specific number the model produces without real code execution is a hallucination. The correct approach is to ask only for "directions" ("if X trends Y then Z") and fill in the numbers yourself after running code. If you use a code-execution tool (ChatGPT's data analysis, Claude's analysis tool), have it run code first and report numbers from the actual output.

Q3: I have hundreds of thousands of rows. Can I feed it all to the LLM? No. Pasting raw data into the prompt exceeds tokens and adds nothing. Paste header + 3-5 sample rows + field semantics, let the model generate code, and run that code on full data in your environment. If the data is in a database, paste the schema and let the model write SQL for the DB to execute. Remember: the model produces approach and code; your machine runs the data.

Q4: The model generated MySQL syntax, but I use PostgreSQL. What now? Write "PostgreSQL 14" directly in the {tool} variable and the model will switch dialects (e.g. TO_CHAR instead of DATE_FORMAT; LIMIT stays but window-function syntax may differ). Same for "ClickHouse." Dialect drift is a common SQL-generation pitfall; declaring it up front saves a round of rework.

Q5: How do I make the insights fit my business instead of generic filler? Two levers. First, add business context in {business_goal} (industry, product type, recent actions, e.g. "AI-tools creator, started testing Xiaohongshu last week"). Second, write clear business definitions and known anomalies in the semantic layer of the data context. The more specific the input, the less room the model has for filler that fits any dataset.

6. References

• OpenAI data analysis official guide (ChatGPT data analysis features and code execution): https://platform.openai.com/docs/guides/data-analysis
• OpenAI Code Interpreter (Advanced Data Analysis) announcement: https://openai.com/index/new-tools-for-data-analysis/
• Anthropic prompt engineering guide (role, context, output format techniques): https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview
• Anthropic code execution tool docs (Claude's analysis / code execution capability): https://docs.anthropic.com/en/docs/build-with-claude/tool-use/code-execution-tool
• DAIR.AI Prompting Guide (a systematic prompt-engineering toolkit): https://www.promptingguide.ai/
• Google Gemini code execution official docs: https://ai.google.dev/gemini-api/docs/code-execution

Note: LLM data-analysis and code-execution capabilities evolve quickly. Context windows, available library versions, and sandbox limits vary by model--check the official docs. The prompt template and pitfalls here are based on general LLM behavior and do not depend on any specific model version.