Act as a senior data scientist helping me analyze [BUSINESS OR RESEARCH QUESTION] using [DATA DESCRIPTION]. My intended decision or audience is [DECISION CONTEXT]. The target outcome is [TARGET OR METRIC], and the available tools are [TOOLS AND ENVIRONMENT]. These are the known data limitations, definitions, and constraints: [DATA CONSTRAINTS]. First, state the analytical question in one testable sentence and list the assumptions that must hold. Then produce a practical analysis plan and code. Do not invent columns, row counts, results, source quality, statistical significance, or business context. When a needed field or definition is missing, ask up to 3 clarifying questions; otherwise label the assumption in the code and explanation. Output these sections:
1. Data audit: grain of the table, likely keys, required columns, missingness checks, duplicate checks, date-range checks, and leakage risks.
2. Method: the appropriate descriptive, inferential, predictive, or causal approach; explain why it fits and name a simpler baseline.
3. Reproducible code in [TOOLS AND ENVIRONMENT], with imports, explicit transformations, validation assertions, and comments at non-obvious steps. Use parameterized SQL where applicable; never silently drop missing values or outliers.
4. Results template: tables or charts to produce, the denominator for every rate, and plain-English language for interpreting each output.
5. Limitations and next actions: confounders, sampling bias, uncertainty, and what decision would be justified versus premature.
Before answering, self-check that the unit of analysis is consistent from source data through metric calculation, and that any proposed join, split, or model evaluation avoids target leakage and temporal leakage. Flag formulas or queries that cannot be validated from the supplied schema.Fill in
| Placeholder | What to enter | Example |
|---|---|---|
| [BUSINESS OR RESEARCH QUESTION] | Enter the decision-focused question the analysis needs to answer. | Which onboarding behaviors are associated with a new account becoming active within 14 days? |
| [DATA DESCRIPTION] | Enter tables, fields, grain, sample rows, and any schema details available. | Postgres tables accounts(account_id, created_at, plan), events(account_id, event_at, event_name), and subscriptions(account_id, started_at); events are one row per event |
| [DECISION CONTEXT] | Enter who will use the result and what decision it may influence. | Product managers will decide which onboarding step to test next quarter |
| [TARGET OR METRIC] | Enter the outcome, KPI, or phenomenon to measure or predict. | active within 14 days, defined as completing three distinct core events after account creation |
| [TOOLS AND ENVIRONMENT] | Enter the language, database, libraries, and execution environment you can use. | Postgres SQL and Python 3.12 with pandas, seaborn, and scikit-learn |
| [DATA CONSTRAINTS] | Enter known gaps, privacy rules, time windows, definitions, and assumptions. | Data covers January through June; no user demographics; exclude internal accounts; do not treat post-day-14 events as predictors |
How to use
- Paste the actual schema or a small anonymized sample, and define the table grain before requesting code.
- Run the audit first; confirm joins and metric denominators before trusting a model or visualization.
- Treat association and causation separately, especially when the result will decide a product or business action.
- Follow up with: “Turn the plan into a notebook sequence, and add a synthetic test case for each validation assertion.”
Variations
SQL analysis
Use when you need a query that can be reviewed before it runs.
Write a [SQL DIALECT] query to answer [QUESTION] from this schema: [SCHEMA]. Define [METRIC] with an explicit numerator, denominator, date window, and unit of analysis. Return the query, a line-by-line explanation, and a small table of validation queries for duplicates, unexpected nulls, and row multiplication after joins. Do not assume field meanings beyond the schema. Check that filters occur at the correct grain and that division by zero and timezone boundaries are handled.
Model plan
Use before building a predictive model.
Design a predictive-modeling plan for [PREDICTION GOAL] using [DATASET DESCRIPTION]. The prediction is made at [PREDICTION TIME], and the label becomes known at [LABEL TIME]. Include target definition, eligible population, feature families, leakage exclusions, time-based train-validation-test splits, baseline model, evaluation metrics, calibration, and fairness or subgroup checks appropriate to [USE CONTEXT]. Do not write code until you identify missing definitions. Check that every feature would exist at prediction time.
Results explanation
Use after analysis is complete and you need a careful stakeholder summary.
Explain these analysis outputs for [AUDIENCE AND DECISION]: [RESULTS]. The question was [QUESTION], and the metric definitions are [DEFINITIONS]. Write a one-page summary with finding, evidence, uncertainty, limitations, and recommended next step. Separate observed associations from causal claims. State denominators and comparison groups in plain language. Do not infer significance, mechanisms, or business impact that the outputs do not establish. Check each conclusion against a quoted result or calculation from the supplied material.
Tips
- Define the observation unit before writing code: an account, user, order, session, or day can produce materially different denominators.
- Create the target and eligibility window before features; this makes it easier to spot data that appeared after the prediction or decision point.
- Ask for validation queries alongside the main query, especially after joins, because duplicated rows can create convincing but false rates.
- For a business metric, write its numerator, denominator, inclusion rules, and time window in one sentence before charting it.
FAQ
Can AI safely write SQL or Python for analysis?
It can draft useful code, but run it against the schema and inspect intermediate row counts, joins, and denominators. Do not accept a result that the code cannot reproduce.
Should I ask for a model first?
Usually start with a data audit and descriptive baseline. A model is not useful if the target, eligibility population, or data timing is unclear.
How can I prevent data leakage?
State when the prediction or decision occurs and when every field becomes available. Exclude any variable collected after that point, including post-outcome status fields.