At some point someone will ask how you got the number. That's when an analysis either holds up or quietly comes apart, and it's usually decided long before the chart.

So the valuable part isn't the answer. It's catching the reason the answer would have been wrong, before it's in a slide with your name on it.

Look at it before calculating anything

The file gets inspected first, and you hear what turned up before you see a single number:

  • What one row actually represents, which is not always what the header implies.
  • Missing values, and whether they're missing at random or in a pattern that means something.
  • Duplicates, and whether they're real repeats or a join that went wrong.
  • Numbers stored as text, mixed date formats, and the other quiet type problems that break a sum silently.
  • Outliers, which are either data entry errors or the most interesting thing in the file.

The order matters more than it sounds. Learning about a broken join after you've seen the chart means you've already half-believed the chart, and unbelieving it is surprisingly hard.

Want to try it?

Ask your Strawberry companion: “Analyze this dataset for the question I need answered. Check the data quality first, agree the definitions, show your work, and tell me what the data cannot support.”

Skill

Analyze a dataset I already have

Analyze this dataset for the question I need answered.

Agree what the words mean

Almost every argument about a number is really an argument about a definition. What counts as active. Whether a month is calendar or rolling. Which timezone the day ends in. Whether a refund reverses the sale or sits next to it.

Those get pinned down before anything is calculated, and where your organization already has an accepted definition, that one wins over a more reasonable-looking alternative. Being consistent with the number everyone else quotes usually matters more than being marginally more correct in private.

Show its work

Every figure that matters arrives with the filters applied, the rows excluded and why, and the formula behind it. You should be able to reproduce the number without asking anyone how it was made, because at some point someone will ask you to.

And what the data shows stays separate from what it implies. Signups dropped the week you changed pricing is a correlation with a very good story attached. It gets labeled as one, rather than promoted to a cause because the timing is convenient.

Say what it can't support

Sample too small to generalize. Period too short to call a trend. A segment with nine rows in it. Survivorship baked into how the data was collected in the first place, so the customers who left aren't in the file at all.

These get stated plainly rather than buried, because a confident answer with an unstated limitation is worse than a hedged answer with a clear one. The first kind gets acted on.

Once the definitions, filters, and checks are right, they can be saved so the same report isn't rebuilt slightly differently every quarter. If it genuinely repeats on a schedule, it can become a Routine that runs the same checks and brings you the result to review.

Turn websites into a clean, reviewable datasetFor when the dataset you need doesn't exist yet. Run finance on autopilotThe same validation discipline applied to recurring reporting.
Official Strawberry skill
Copy skill file Download skill file
name
analyze-a-dataset
description
Analyze a dataset the user already has, from first look and data quality through the actual question, with the caveats the data genuinely supports. Use for a spreadsheet, export, or query result that needs interpreting rather than collecting.

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 strawberry/research-analysis/extract-web-data when the analysis needs data the user does not have yet, and strawberry/research-analysis/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.