Help me design and perform a defensible analysis. Do not jump to a query until you define the metric and identify data limitations. Business question and decision: [BUSINESS QUESTION] Data source and schema: [DATA SCHEMA] Time period, population, and filters: [SCOPE] Metric definitions or business rules: [METRIC RULES] Analysis tool and dialect: [TOOL AND DIALECT] Ask up to 3 clarifying questions only if a required input is missing. Then produce: 1. A restatement of the decision, the primary metric, denominator, unit of analysis, time grain, comparison group, and inclusion or exclusion rules. 2. A concise analysis plan that identifies needed joins, likely grain mismatches, late-arriving data, duplicates, null handling, timezone issues, and cohort or seasonality concerns where relevant. 3. Working [TOOL AND DIALECT] code or formulas, fully formatted and commented. Use explicit column names, join keys, date boundaries, and safe division. If the supplied schema cannot support a requested metric, say exactly what field is missing instead of inventing one. 4. A validation section with at least three checks: row counts or reconciliation, uniqueness at the intended grain, and a reasonableness check on totals or rates. 5. A plain-English findings template that separates observed result, likely interpretation, limitations, and the next decision or test. Do not claim causation from an observational comparison. Before answering, self-check that joins cannot multiply rows unnoticed and that metric numerator and denominator use the same eligible population. Flag any ambiguous definition that could materially change the result.
Fill in
| Placeholder | What to enter | Example |
|---|---|---|
| [BUSINESS QUESTION] | State the decision to make and the question the analysis must answer. | Should we offer onboarding calls to accounts with fewer than 20 employees to improve first-month activation? |
| [DATA SCHEMA] | List tables or sheets, key columns, their grain, and known data-quality notes. | accounts: one row per account, account_id, created_at, plan, employee_count; events: one row per event, account_id, occurred_at, event_name; calls: one row per call, account_id, scheduled_at, completed_at. |
| [SCOPE] | Specify the date range, population, segments, and filters to include or exclude. | Accounts created from April 1 through June 30, 2026; exclude internal accounts and enterprise plans. |
| [METRIC RULES] | Define important business terms, attribution rules, and calculation requirements. | Activated means completing both import_completed and first_payroll_run within 30 days of account creation; use account timezone when available. |
| [TOOL AND DIALECT] | Name the analysis environment, such as BigQuery SQL, Excel, Google Sheets, or pandas. | BigQuery Standard SQL. |
How to use
- Paste the schema at its real grain, including keys and any fields you do not trust.
- Check the metric definition and join logic before running the generated code.
- Run the validation queries first and investigate unexpected counts before reading findings.
- Send this follow-up: “Adapt this for a weekly cohort chart with 95% confidence intervals, and explain any assumptions needed.”
Variations
SQL metric audit
Use this to review a query or dashboard metric that stakeholders dispute.
Audit this [SQL QUERY OR FORMULA] for the metric [METRIC NAME]. The relevant schema is [SCHEMA], and the intended definition is [INTENDED DEFINITION]. Identify grain, joins, filters, time boundaries, null behavior, duplicate risks, and denominator errors. Return a corrected version in [DIALECT], followed by validation queries and a short explanation of each changed line. Do not assume columns not listed. Check that the corrected query returns one row per intended reporting unit.
Spreadsheet analysis
Use this when data is in Excel or Google Sheets rather than a warehouse.
Create a spreadsheet analysis for [QUESTION] using sheet data described in [SHEET STRUCTURE]. The required metric rules are [METRIC RULES], and I use [EXCEL OR GOOGLE SHEETS]. Provide the helper columns, exact formulas using the actual column names or ranges, pivot-table setup if useful, and three validation checks. Explain how blanks, text dates, duplicates, and divide-by-zero are handled. Do not fabricate values. Check that formulas can be filled down without changing the intended references.
Experiment readout
Use this after an A/B test or controlled rollout.
Prepare an analysis plan and readout for [EXPERIMENT] using [DATA SCHEMA], [PRIMARY METRIC], [GUARDRAIL METRICS], and [EXPOSURE RULES]. Produce metric definitions, eligibility criteria, SQL or formulas in [TOOL], sample-ratio and data-quality checks, result table layout, and decision rules for ship, iterate, or stop. Distinguish statistical significance from practical significance. Do not claim a winner without supplied results. Check that treatment assignment precedes measured outcomes.
Tips
- Write the unit of analysis first: account, user, order, session, or day; most misleading queries mix these without noticing.
- Keep the eligibility population identical across a rate’s numerator and denominator unless the metric definition explicitly says otherwise.
- Test every join with a count before aggregating, especially when joining events to account-level tables.
- Report observational comparisons as associations and name plausible confounders before recommending a causal action.
FAQ
Can I paste customer data into an AI prompt?
Follow your organization’s data-handling policy first. Remove direct identifiers and sensitive fields when they are not required for the analysis.
Will AI-generated SQL be correct?
It can be a strong starting point, but correctness depends on your metric definition, table grain, and validation results.
What should I provide if I do not know the schema?
Export or describe column names, example values, and what one row represents for each source before asking for formulas or queries.