ChatGPT Prompts for Data Analysts

<context> I have a dataset [DATASET] with these columns and sample rows: [PASTE COLUMN NAMES + 10-20 SAMPLE ROWS, OR A DESCRIBE/PROFILE OUTPUT] </context> <task> 1. For each column, infer its likely type, role (id, dimension, measure, date), and expected value range. 2. Flag data-quality risks: missing values, mixed formats, outliers, inconsistent categories, duplicates, suspicious zeros. 3. Rank the issues by how badly they could distort [METRIC]. 4. Recommend a concrete cleaning step for each issue. 5. Give me a short checklist I can run before trusting this data in a report. </task>

<context> Dataset: [DATASET]. The issues I need to fix: [LIST ISSUES, e.g. dates in 3 formats, "N/A" used for nulls, trailing whitespace, duplicate ids] I want the cleaning done in [TOOL] (e.g. SQL, pandas, dbt). </context> <task> 1. Write [TOOL] code that fixes each listed issue, one clearly-labeled step per issue. 2. Standardize dates, trim/normalize text, coerce real nulls, and dedupe on the correct key. 3. Preserve a record count before and after each step so I can audit row loss. 4. Add comments explaining each transformation. 5. Warn me about any step that could silently drop or alter rows feeding [METRIC]. </task>

<context> The column [METRIC or DIMENSION] in [DATASET] has inconsistent free-text values, for example: [PASTE DISTINCT VALUES, e.g. "USA", "U.S.A.", "United States", "us"] </context> <task> 1. Propose a clean canonical set of categories. 2. Build a full mapping table from every raw value to its canonical value. 3. Write [TOOL] code (CASE statement or mapping join) to apply it. 4. Flag any raw values that are genuinely ambiguous and ask me how to map them. 5. Suggest a guardrail to catch new unmapped values in future loads. </task>

<context> My dataset [DATASET] is currently in [wide / long] format. Sample: [PASTE A FEW ROWS] I need it in [long / wide] format because [REASON, e.g. to chart a time series / to feed a model]. </context> <task> 1. Show the exact target structure (columns and one example row). 2. Write [TOOL] code (pivot/unpivot, melt/pivot_table, or SQL CASE) to reshape it. 3. Explain how each original field maps into the new shape. 4. Handle edge cases: missing combinations, duplicate keys, and aggregation when needed. 5. Verify the reshape didn't change the total of [METRIC]. </task>

<context> I load [DATASET] into [TOOL] on a [daily/hourly] schedule and feed it into reports that track [METRIC]. Key columns and expected rules: [DESCRIBE KEYS, RANGES, AND BUSINESS RULES] </context> <task> 1. Propose a set of automated data-quality tests (row counts, null thresholds, uniqueness, referential integrity, range checks, freshness). 2. Write each test as runnable [TOOL] code (or dbt tests / assertions). 3. Define a clear pass/fail threshold for each. 4. Recommend which failures should block the pipeline vs. just alert. 5. Suggest how to log results so I can track data quality over time. </task>

<context> [METRIC] [rose/fell] by [AMOUNT] over [TIME PERIOD] in [DATASET]. Available dimensions to slice by: [LIST DIMENSIONS, e.g. region, plan, channel, device, cohort] </context> <task> 1. Propose a structured approach to decompose the change (e.g. mix vs. rate, segment contribution, before/after). 2. List the specific slices and queries I should run, in priority order. 3. For each, state the hypothesis it would confirm or kill. 4. Tell me how to distinguish a real driver from a composition/Simpson's-paradox effect. 5. Give me a template sentence to report each finding to stakeholders. </task>

<context> I want to analyze [retention / repeat behavior / LTV] for [DATASET]. Relevant events and timestamps: [DESCRIBE EVENT TABLE: user id, event type, timestamp, value] We care most about [METRIC]. </context> <task> 1. Define the cohort grain (signup week, first-purchase month, etc.) and recommend the best one for my question. 2. Write the [TOOL] SQL to build the cohort/retention matrix. 3. Explain how to read the resulting table and what a healthy vs. concerning pattern looks like. 4. Suggest 2-3 segment breakdowns that usually reveal the most. 5. Note common pitfalls (survivorship bias, partial last period) and how to handle them. </task>

<context> Claim to test: "[STATE THE HYPOTHESIS, e.g. the new onboarding lifted activation]". Data available: [DESCRIBE GROUPS, SAMPLE SIZES, AND THE METRIC, e.g. [METRIC] for treatment vs. control]. </context> <task> 1. State the appropriate statistical test and why (t-test, chi-square, Mann-Whitney, etc.). 2. List the assumptions that test makes and how to check them with my data. 3. Tell me exactly what numbers to compute and provide [TOOL] code to do it. 4. Explain how to interpret the result, including effect size, not just the p-value. 5. Warn me about confounders, peeking, and multiple-comparison traps relevant to this claim. </task>

<context> Here is a time series (or table) of [METRIC] from [DATASET]: [PASTE THE DATA OR UPLOAD THE FILE] Context about the business: [ANY EVENTS, LAUNCHES, SEASONALITY, OUTAGES] </context> <task> 1. Identify points that deviate meaningfully from the trend or seasonal pattern. 2. For each anomaly, give the magnitude and the date/segment. 3. Propose the most plausible explanations, separating likely real signal from likely data issues. 4. Recommend the follow-up query or slice that would confirm each explanation. 5. Tell me which anomalies are worth escalating now vs. monitoring. </task>

<context> A stakeholder asked me: "[PASTE THE VAGUE REQUEST, e.g. why are sales down]". Data I have access to: [LIST DATASETS / TABLES]. Audience for the answer: [WHO + WHAT THEY DECIDE]. </context> <task> 1. Restate the underlying decision this analysis should inform. 2. List the 3-5 sharpest questions I should actually answer. 3. For each, specify the [METRIC], the slice, and the data source. 4. Define what "done" looks like and what would change the stakeholder's decision. 5. Draft 3 clarifying questions I should ask the stakeholder before I start. </task>

<context> I need to visualize [METRIC] from [DATASET]. The point I want the audience to take away is: "[STATE THE MESSAGE]". Audience: [WHO]. The data looks like: [DESCRIBE DIMENSIONS, GRAIN, NUMBER OF SERIES]. </context> <task> 1. Recommend the single best chart type for this message and explain why. 2. Name 1-2 alternatives and when they'd be better. 3. Specify the encodings: x, y, color, sort order, and aggregation. 4. List what to leave OUT to avoid clutter or misleading the viewer. 5. Suggest a clear title and annotation that states the takeaway, not just the data. </task>

<context> I'm building a [TOOL] dashboard (e.g. Tableau, Looker, Power BI, Metabase) for [AUDIENCE] to monitor [GOAL]. Available metrics/dimensions: [LIST KEY METRICS AND DIMENSIONS] </context> <task> 1. Define the 3-5 headline KPIs that belong at the top and why. 2. Propose a layout in reading order: what goes top-left, what supports it below. 3. For each section, specify the chart, the [METRIC], and the default filters/time grain. 4. Recommend which filters belong as global controls. 5. Flag metrics that look useful but would create noise or vanity-metric distraction. </task>

<context> I want to build a [CHART TYPE] of [METRIC] by [DIMENSION] from [DATASET] using [TOOL/LIBRARY, e.g. Plotly, matplotlib, Vega-Lite, ECharts]. Data columns: [LIST COLUMNS + TYPES]. </context> <task> 1. Write the full chart code/config for [TOOL/LIBRARY], ready to run. 2. Set sensible defaults: sorted axis, readable number formatting, clear labels, accessible colors. 3. Add the takeaway as a title and annotate the key data point. 4. Make it reusable: pull field names into variables at the top. 5. Note one tweak for a presentation version vs. an exploratory version. </task>

<context> Here is a chart I made [PASTE IMAGE OR DESCRIBE IT FULLY: type, axes, colors, what it shows]. It visualizes [METRIC] from [DATASET]. Intended message: "[MESSAGE]". </context> <task> 1. Judge whether this chart actually communicates the intended message. 2. List specific problems: misleading scales, too many series, weak labels, bad color choices, chartjunk. 3. Recommend concrete fixes, ordered by impact. 4. Suggest whether a different chart type would serve the message better. 5. Rewrite the title and key annotation to make the takeaway unmissable. </task>

<context> Different reports built on [DATASET] show different numbers for [METRIC] and stakeholders don't trust the dashboard. Relevant tables/logic: [DESCRIBE HOW THE METRIC IS CURRENTLY COMPUTED IN DIFFERENT PLACES] </context> <task> 1. Propose one canonical definition of [METRIC]: numerator, denominator, filters, grain, and timezone. 2. List the edge cases the definition must settle (refunds, test accounts, late events, nulls). 3. Write the single source-of-truth [TOOL] query/measure that implements it. 4. Explain how to document this so every report references the same logic. 5. Suggest a reconciliation check to prove old reports now agree. </task>

<context> Here are my analysis findings about [METRIC] from [DATASET]: [PASTE KEY NUMBERS, TABLES, OR BULLET FINDINGS] Audience: [WHO]. Decision they need to make: [DECISION]. </context> <task> 1. Open with the single most important takeaway in one sentence. 2. Structure the rest as: what happened, why it happened, what it means, what to do. 3. Translate every statistic into business impact, not jargon. 4. Cut findings that don't change the decision. 5. End with a clear, specific recommendation and the confidence level behind it. </task>

<context> I have a detailed analysis on [TOPIC] using [METRIC] from [DATASET]. Full findings: [PASTE OR SUMMARIZE THE FULL ANALYSIS] This summary is for [EXEC AUDIENCE] who has 60 seconds. </context> <task> 1. Write a 4-6 sentence executive summary. 2. Lead with the result and the recommended action. 3. Include only the 2-3 numbers that matter most, with context (vs. target, vs. last period). 4. State the main risk or caveat in one line. 5. Keep it free of methodology and SQL — pure signal. </task>

<context> I send a [weekly/monthly] report on [METRIC] for [DATASET] to [AUDIENCE]. Today it's ad hoc and inconsistent. Metrics I usually include: [LIST METRICS AND DIMENSIONS] </context> <task> 1. Design a reusable report template with clear sections (headline, KPI movers, deep-dive, watchlist, actions). 2. For each KPI, specify the comparison (WoW, MoM, vs. target) and the format. 3. Write fill-in-the-blank sentence templates so the narrative is fast to produce each cycle. 4. Recommend what to automate vs. write by hand each time. 5. Suggest a length/format that fits how [AUDIENCE] actually reads. </task>

<context> I need to explain this technical finding to [NON-TECHNICAL AUDIENCE]: [PASTE THE FINDING, e.g. a statistical result, model output, or complex metric about [METRIC]]. </context> <task> 1. Restate the finding in one plain sentence with zero jargon. 2. Use one concrete analogy or example to make it intuitive. 3. Explain why it matters to this audience specifically. 4. State clearly what is certain vs. uncertain, without false precision. 5. End with the one action or decision it should inform. </task>

<context> I'm presenting an analysis of [METRIC] from [DATASET] to [AUDIENCE] who needs to decide [DECISION]. Key findings: [LIST FINDINGS] </context> <task> 1. Structure the deck as a story: setup (what we expected), tension (what we found), resolution (what to do). 2. Propose a slide-by-slide outline with the single message of each slide as its title. 3. For each slide, name the one chart or number that proves the message. 4. Identify the emotional/logical turning point that should land the recommendation. 5. Anticipate the 3 toughest questions and draft a one-line answer for each. </task>

<context> A stakeholder asked for "[PASTE REQUEST]" by [DEADLINE] using [DATASET]. Realistically it would take [YOUR ESTIMATE] to do well, and parts of it are unclear or low-value. </context> <task> 1. Draft a reply that acknowledges the request and the underlying goal. 2. Offer a faster phase-1 answer (the 80/20) and a fuller phase-2 if needed. 3. Ask the 2-3 clarifying questions that most affect scope. 4. Surface any data limitation that could change expectations, diplomatically. 5. Keep the tone collaborative, not defensive — assume good intent. </task>

<context> My analysis of [METRIC] in [DATASET] contradicts what [STAKEHOLDER] expected or hoped for. The finding: [STATE IT]. I have [confidence level] in it. </context> <task> 1. Draft a message that leads with respect for their hypothesis, then states the finding clearly. 2. Show the evidence concisely so it's hard to dismiss but easy to follow. 3. Acknowledge uncertainty and what could still change the picture. 4. Reframe toward "what this means we can do now" rather than "you were wrong". 5. Invite a working session to dig in together. </task>

<context> I'm sharing analysis of [METRIC] from [DATASET] but it has limitations: [LIST THEM: missing data, short time window, proxy metrics, sampling, known data issues] Audience: [WHO]. </context> <task> 1. Write a short "what to keep in mind" section in plain language. 2. For each limitation, state the issue and how much it could affect the conclusion. 3. Distinguish "this might be slightly off" from "do not make this decision on this data". 4. Avoid undermining the whole analysis — be precise about scope, not apologetic. 5. Recommend what would be needed to remove each limitation. </task>

<context> A stakeholder says my reported [METRIC] for [DATASET] "looks wrong" or disagrees with another source. Their number: [THEIRS]. Mine: [MINE]. How I computed mine: [BRIEF METHOD]. </context> <task> 1. Draft a calm reply that treats the discrepancy as a definition/scope question, not a fight. 2. List the most likely reasons two correct sources disagree (filters, timezone, dedup, date grain, refunds). 3. Propose a quick reconciliation: which slices to compare to isolate the gap. 4. Commit to a clear next step and timeline. 5. Keep it confident but open to being wrong. </task>

<context> Stakeholders keep dropping ad-hoc data requests on me with no priority or context. Common requests involve [DATASET] and metrics like [METRIC]. </context> <task> 1. Draft a lightweight intake template they should fill out (question, decision, deadline, priority). 2. Propose response-time expectations by request type (quick lookup vs. deep analysis). 3. Write a short, friendly message introducing this process without sounding bureaucratic. 4. Suggest how to handle "urgent" requests so the word doesn't lose meaning. 5. Recommend where to surface the queue so priorities are visible. </task>