Analyze a Dataset

Help the user get a defensible answer out of data they already have. Collecting data is a different job; this one starts once the file is in front of you.

The most valuable thing here is usually not the analysis. It is catching the reason the analysis would have been wrong.

1. Understand the question and the data's limits

Ask what decision this feeds. "Look at this data" produces a tour; "should we keep running this channel" produces an answer.

Then find out where the data came from, what each row represents, what period it covers, and how it was filtered before it reached the user. An export that silently excludes canceled orders answers a different question than the one being asked.

2. Look at the data before analysing it

Inspect it first and report what you find:

• row and column counts, and what one row actually represents;
• missing values, and whether they are missing at random or in a pattern;
• duplicates, and whether they are genuine repeats or a join gone wrong;
• types that do not match their content, such as numbers stored as text or mixed date formats;
• outliers, and whether they are errors or the most interesting part of the dataset.

Say what you found before moving on. A user who learns about a broken join after seeing a chart has already half-believed the chart.

3. Agree the definitions

Most disputes about numbers are disputes about definitions. Before calculating, pin down what counts as active, what counts as a customer, whether the period is calendar or rolling, and which currency or timezone applies. Where the user's organization already has an accepted definition, use theirs rather than a reasonable-looking alternative.

4. Answer the question

Do the analysis the question needs, not the most sophisticated one available. Most real questions are answered by a well-chosen cut, a rate, or a comparison over time.

Show the work: the filters applied, the rows excluded and why, and the formula behind any figure that matters. The user should be able to reproduce the number without asking how it was made.

Separate what the data shows from what it implies. A drop in signups and a pricing change in the same week is a correlation with a plausible story, and it should be labeled as that rather than as a cause.

5. Say what the data cannot support

State the limits plainly: sample sizes too small to generalise, a period too short for a trend, a segment with too few rows to compare, survivorship or selection effects baked into how the data was collected.

A confident answer with an unstated limitation is worse than a hedged answer with a clear one.

6. Deliver and continue

Lead with the answer, then the evidence, then the caveats. Return it in the format the decision needs: a short written answer, an annotated spreadsheet, a table, or a chart where the shape is the point.

Use @extract-web-data when the analysis needs data the user does not have yet, and @create-beautiful-slide-deck when the accepted findings need presenting.

After the analysis proves useful, preserve the accepted definitions, filters, checks, and output format as a custom skill, so the same report does not get rebuilt differently each time. A recurring version can become a Routine once the source, cadence, and review point are settled.