Asking well · for data analysts
Asking well in data analysis
A stakeholder asks why signups fell. An analyst who types that question into a chat gets a list of generic reasons signups fall. The model has no way to know which metric you mean, which period you are comparing, or what data you have.
Asking well in analysis means stating the decisions a careful analyst makes before writing a query. Which metric, defined how? At what grain? Over which dates, in which time zone? What form should the answer take, and what should the model do when it is unsure?
Where it comes up
A query for weekly active users
State the definition of "active" your team uses, the event table, the week boundary, and the time zone. Ask for the query and a short note on any assumption it makes, so you can check each one.
Explaining an inherited query
Paste the query and ask for a step-by-step account of what each CTE does and what one output row represents. Ask the model to flag joins that could duplicate rows.
Options for a cohort chart
Describe the audience, the decision the chart supports, and the cohort definition. Ask for three chart designs with the trade-off of each, rather than one finished chart.
What it looks like at each band
E1 · Foundational
Gets working queries for familiar, simple questions. Requests name the table and the goal but leave out definitions, grain, and date logic. Fixes problems by editing the query by hand rather than by restating the request.
E2 · Proficient
States the metric definition, the grain, the time window, and the expected output shape. Asks the model to list its assumptions. When a result looks wrong, rewrites the request with the missing detail instead of retrying the same words.
E3 · Distinguished
Splits an analysis into stages: clarify the question, design the approach, then write the query. Asks the model to challenge the framing, such as whether a ratio or a count better fits the question. Specifies how to handle nulls, late data, and test accounts.
E4 · Exceptional
Writes request templates the team reuses for recurring analysis, with fields for metric definition, grain, filters, and exclusions. Knows when a precise single request works and when a short exchange is faster. Colleagues ask better questions after seeing how this person asks.
Common mistakes
Asking for "the" number
Revenue, active users, and churn each have several valid definitions. If the request does not pick one, the model picks for you and does not say which.
Leaving out the date logic
Time zones, week start days, and whether a period is inclusive change results. State them in the request rather than finding the gap in a stakeholder meeting.
Asking for a conclusion instead of an analysis
"Why did conversion drop?" invites a confident story. Ask for the breakdowns that would test each explanation, then look at the numbers yourself.
A worked example
A query for monthly churn rate by plan for a subscription product.
Write SQL to calculate churn by plan for the last six months.
The model must guess what churn means, which table holds subscriptions, how to treat plan changes, and whether a month is a calendar month. It will produce a plausible query built on guesses you cannot see.
Write a query against the subscriptions table (schema below). Churn rate for a month is the count of subscriptions active on the first day of the month that ended during that month, divided by the count active on the first day. Use calendar months in UTC. A plan change is not churn. Exclude internal test accounts where is_test is true. Return one row per month and plan for the last six complete months. After the query, list any assumption you made.
The request defines the metric, the time boundary, the exclusions, and the output grain. Asking for a list of assumptions turns hidden guesses into items you can check.
The full study guide for this skill, for every role, is Asking well. The other five skills for data analysts are on the AI skills for data analysts page. A one-page summary is in the AI prompt checklist.
See where you stand
The free check grades asking well and the other five skills in about fifteen minutes. Nobody sees the grade but you.
Then build the skills and prove it. The three steps for data analysts list the courses and templates that fit the work.