Back to course overview
Module 2Analyzing data with AI 20 min

Lab: The refund investigation

Run the full analysis loop on Harbor Lane's data pack: localize the spike, find the bend, check the counter-segment, kill the alternatives — and write the memo.

The data team answered your Module 1 checklist with three extracts (below). Work them with the loop from this module: plan with AI before pasting data, verify in your spreadsheet anything you'll quote, and keep the numbers log. The answer is findable — and so are two decoys.

extract 1 — refund % of revenue, by category × month (all channels)text
category, Jan, Feb, Mar, Apr, May, Jun
Coffee,   2.1,  2.3,  2.2,  2.4,  2.3,  2.5
Bakery,   1.4,  1.5,  1.6,  1.5,  1.7,  1.6
Beans,    2.8,  2.6,  2.9,  3.0,  2.8,  3.1
Gear,     7.9,  8.2,  8.0, 11.6, 15.8, 19.1
extract 2 — Gear refund % by channel × monthtext
channel, Jan, Feb, Mar, Apr, May, Jun
web,      9.4,  9.8,  9.5, 15.2, 21.7, 26.9
store,    5.9,  6.1,  6.0,  6.3,  6.1,  6.4
extract 3 — Gear WEB refund reasons, share of refundstext
reason,             Q1_avg, Apr,  May,  Jun
damaged_in_transit,   22%,   41%,  53%,  61%
changed_mind,         31%,   24%,  19%,  16%
wrong_item,           12%,   10%,   9%,   8%
quality_complaint,    18%,   14%,  11%,   9%
other,                17%,   11%,   8%,   6%
  1. 1Plan first. Give AI the investigation question, your labeled hypothesis from Module 1, and the extract descriptions (not the data). Get the cut order and kill-criteria committed. Then look.
  2. 2Localize: Extract 1 should hand you the segment in one read — Gear moved ~8%→19% while nothing else moved a point and a half. Verify the claim 'all other cells < 1.5pt change' yourself; that sentence is going in the memo.
  3. 3Find the bend and check the mechanism: Extract 2 gives the April bend and the counter-segment in one table — web bends hard, store barely moves. Does that match the mailer mechanism? Extract 3 confirms or kills it: damaged_in_transit share nearly tripled while every other reason's share fell as damage crowded them out — remember shares sum to 100, so a falling share isn't the same as a falling count. Note that changed_mind's share falling doesn't mean fewer people changed their minds. (This is decoy #1; don't report 'customers stopped changing their minds.')
  4. 4Kill the alternatives. Generate five with AI, then use the extracts: A spring gift-season mix shift? Would raise Gear volume, not the damage reason share. A promo attracting returns-happy buyers? Would hit changed_mind, which fell. Beans creeping 2.8→3.1 (decoy #2)? Within its Jan–Mar wobble — say why it doesn't clear your bar. Each kill is one memo line.
  5. 5Size it and write the memo using the five-part structure: Gear web refunds run ~27% in June vs. a ~9–10% baseline — so roughly two-thirds (~65%) of the June Gear-web refund rate is excess, about 17 refund-rate points above baseline. Put a dollar range on it — but you don't have Gear's revenue in the extracts, so state your assumption explicitly (e.g. 'assume Gear web ≈ $X in June revenue'), label it as an assumption, and show the range that follows. Never present an assumed denominator as a known number; ranges beat false precision. Run the hostile-CFO review prompt, fix what it catches, and file your numbers log.
What this data cannot tell you

Nothing in these extracts proves the mailers did it — the data localizes where and when, and the reason mix matches the mechanism, but the fragile-flag audit (which SKUs ship in which packaging) is the confirming link, and it's still pending from Module 1. Your memo's confidence section should say exactly that. An analyst who reports 'strong circumstantial case, one confirming check outstanding' is more credible than one who reports certainty — and Module 4 is where the process fix gets designed either way.

Problem set 2

A second investigation with the same loop but messier data: a 'conversion rate drop' that turns out to be a definition change in how sessions were counted (the metric moved; the business didn't). Detecting instrumentation causes vs. business causes is the problem set's whole point — and the reason Data Foundations exists.