Best AI Prompts for Analysts

AI summary

Seven AI prompts for the analyst’s actual week: plain-English to SQL, query performance review, stakeholder-question translation, result-to-narrative drafting, cohort analysis design, dashboard triage, and A/B test reading. Built to protect the rigor of the analysis, not just speed it up.

Prompt 1

Plain-English to SQL

You know what question you want answered. Writing the SQL takes 20 minutes. This prompt gets you to the right query in under 2.

I want to answer this business question: [STATE THE QUESTION IN PLAIN ENGLISH].

Here is the relevant schema (table names, key columns, what each represents):

[PASTE SCHEMA OR TABLE DEFINITIONS]

The data warehouse / database is: [SNOWFLAKE / BIGQUERY / POSTGRES / DUCKDB / etc.]

Write the SQL with:

1. The query, formatted readably (CTEs over nested subqueries when it helps).
2. Comments above each CTE or major step explaining what it does in one sentence.
3. A note about any assumptions you made (date ranges, NULL handling, what counts as "active").
4. A note about anything in the schema that surprised you or that I should double-check.

Do not invent column names. If something is unclear in my schema, ask before writing the query.

When to use: Any time you have a question that needs an answer in under 30 minutes. · Best model: Claude with the Snowflake or Supabase connector is strongest. Without a connector, paste schema directly.

Prompt 2

Query Performance Review

Your query works but takes 4 minutes to run. This prompt finds the bottleneck.

Here is a SQL query that takes too long to run:

```sql
[PASTE QUERY]
```

The warehouse: [SNOWFLAKE / BIGQUERY / POSTGRES / etc.]
Approximate row counts of the main tables: [TABLE 1: N rows, TABLE 2: N rows, etc.]
Available indexes (if Postgres) or clustering keys (if Snowflake / BigQuery): [LIST OR "NONE KNOWN"]
Current runtime: [SECONDS / MINUTES]
Target runtime: [SECONDS]

Analyze:

1. The likely bottleneck and why.
2. The change with the highest expected impact (rewrite a join, add a clustering key, push down a filter, etc.).
3. The change with the second-highest impact.
4. Anything in the query that is dead code or redundant.
5. The rewritten query, ordered by expected impact.

Be direct. If the query has a fundamental design issue, name it rather than tuning around it.

When to use: When a query has been running for over 30 seconds and that is not OK. · Best model: Claude (most disciplined about not over-promising performance gains).

Prompt 3

Stakeholder-Question Translator

An exec asks you “what is going on with retention?” and you have to translate that into the 3 actual analyses they care about. This prompt does the translation.

A stakeholder asked me this question:

"[PASTE EXACT QUESTION]"

The stakeholder's role: [TITLE]
The likely underlying decision they are about to make: [YOUR BEST GUESS]
What I already know about this topic from past work: [BRIEF CONTEXT]

Translate the question:

1. The 2-3 specific, answerable questions hiding inside the vague one.
2. Which one is most likely the actual decision input they need.
3. The metric(s) that would answer it.
4. The cuts (by segment, by time, by cohort) most likely to be useful.
5. The one follow-up question I should ask the stakeholder before I start building.
6. A 90-second response I could send them right now if I cannot start the actual analysis yet.

Do not assume the stakeholder asked the right question. Most of the time they asked an adjacent one.

When to use: Within an hour of receiving a vague ask. · Best model: Claude (best at distinguishing real questions from adjacent ones).

Prompt 4

Result-to-Narrative Drafter

You have a chart and a finding. Now you have to write the story that goes around it. This prompt produces a narrative that holds up to executive scrutiny.

Here is the analytical finding I want to communicate:

[PASTE THE KEY METRIC / CHART DESCRIPTION / RESULT]

My audience is: [ROLE OR FUNCTION OF READERS]
The decision they are using this to make: [SPECIFIC DECISION OR DIRECTION]
My confidence level in this finding: [HIGH / MEDIUM / LOW, WITH ONE-LINE REASON]
What I do NOT know: [LIST CAVEATS]

Draft a narrative with:

1. THE HEADLINE in one sentence.
2. THE NUMBER, stated cleanly with the comparison that makes it meaningful (year-over-year, vs target, vs cohort, etc.).
3. THE WHY: 2-3 sentences on what we think is driving this, anchored in evidence.
4. THE CAVEAT: what we do not yet know and how it would change the picture.
5. THE SO-WHAT: what this means for the decision the audience is making.
6. ONE FOLLOW-UP ANALYSIS that would resolve the remaining uncertainty.

Do not over-claim. If the finding is correlational not causal, say so directly. Do not bury the caveat.

When to use: Any time you are about to present a finding to a stakeholder. · Best model: Claude. It is more disciplined about confidence calibration than other models.

Prompt 5

Cohort-Analysis Designer

Most cohort analyses get the cohort definition wrong, then everything downstream is wrong. This prompt designs the cohort cuts before you write the SQL.

I want to do a cohort analysis to understand [QUESTION OR HYPOTHESIS].

The entity being analyzed: [USERS / ACCOUNTS / ORDERS / EVENTS / etc.]
Available signup or first-event timestamp: [WHAT YOU HAVE]
Relevant dimensions I have: [LIST: e.g., signup source, plan tier, geography, customer size]
Time window I care about: [e.g., 6 months post-signup]

Design the analysis:

1. THE COHORT DEFINITION: how to define a cohort for this question (signup month, signup source, first product touched). Justify the choice.
2. THE METRIC TO TRACK: what we measure across cohorts and at what cadence.
3. THE 2-3 CUTS WORTH SEPARATING: which dimensions to cross-cut by (and which to ignore as noise).
4. THE CONFOUNDS: what could make this analysis misleading.
5. THE SQL SKELETON: pseudo-SQL or CTE structure for what the query would look like.
6. THE FIRST CHART: what visualization would answer the question fastest.

Do not skip the confounds. They are the difference between a useful and a misleading cohort analysis.

When to use: Before you write a single line of cohort SQL. · Best model: Claude is well-suited because it will actually name the confounds rather than skip them.

Prompt 6

Dashboard Triage

Your team has 47 dashboards. 5 of them are actually used. This prompt helps you decide what to keep, kill, or merge.

Here is an inventory of our team's dashboards:

[FOR EACH: name, purpose in one sentence, owner, rough viewer count over past 30 days if known, last meaningfully edited date]

Produce a triage:

1. KEEP: the dashboards that are clearly earning their maintenance cost. Note why.
2. MERGE: pairs or groups of dashboards that overlap and should be combined.
3. KILL: dashboards no one is using, with the reason they probably stopped being relevant.
4. ORPHANED: dashboards with no clear owner, who they should be reassigned to.
5. MISSING: based on the topics covered, what dashboards SHOULD exist that do not.

If the inventory is incomplete (low usage signal, no last-edit date), say so and ask for the missing info rather than guess.

When to use: Quarterly. Or any time you find yourself spending more time maintaining dashboards than answering questions. · Best model: Claude or Grok (both willingly recommend killing things).

Prompt 7

A/B Test Reading

Your experiment ended. The headline result looks good. This prompt forces you to check whether the result actually holds up before you ship the change.

Here are the results of an A/B test I just ran:

Treatment vs Control on metric: [METRIC NAME]
Control: [VALUE, SAMPLE SIZE]
Treatment: [VALUE, SAMPLE SIZE]
Test duration: [DAYS]
P-value or confidence interval: [IF AVAILABLE]
Guardrail metrics: [LIST WITH VALUES FOR EACH ARM]

The change being tested: [DESCRIBE]

Read the result:

1. STATISTICAL READ: do the numbers actually support the conclusion the team wants to draw.
2. PRACTICAL READ: is the effect size large enough to justify shipping the change.
3. GUARDRAIL CHECK: did anything bad happen on the secondary metrics, even if non-significant.
4. NOVELTY EFFECTS: is the test long enough to rule out novelty or weekday effects.
5. SEGMENT CHECK: should we look at the effect by segment before concluding (suggest 2-3 segments to check).
6. SHIP OR HOLD: your recommendation, with the one reason that drove it.

Be direct. If the team is over-reading the data, say so.

When to use: Within 24 hours of the test reaching the planned sample size. · Best model: Claude. It pushes back on over-claiming more reliably than ChatGPT.

Connectors are now standard

Claude, ChatGPT, and Grok all support connectors that let your AI read live data from your work tools (Gmail, Notion, GitHub, Asana, HubSpot, Stripe, and many more) instead of relying on you to paste context. For analysts this means the AI can query Snowflake directly with the schema visible, read Supabase Postgres tables, pull dashboards from Notion, or fetch the relevant Slack thread where the stakeholder originally asked the question.

For data analysts, the connectors worth pairing with these prompts:

Get Smarter About AI Every Morning

Free daily newsletter. Built for people who want to use AI well, not chase every model.

Free forever. Unsubscribe anytime.

Two ways to go further