Tasks / Metrics & Experimentation

Analyse experiment results

Can the model separate evidence from speculation, identify decision-relevant uncertainty and recommend a sensible next action?

Task type v1.2 · 2 tasksLast changed 6 Oct 2026 · ChangelogDifficulty

What AI gets right here, and what you’ll still have to catch

From 16 graded outputs by 8 models. 63% were usable with at most a quick edit.

Reliably right

  1. Respects explicit constraints100% pass
    The note is addressed to the onboarding team, stays under 300 words, and proposes actions that would enforce the stated constraints.
    GPT-6 Astra · ChatGPT · The underpowered onboarding test
  2. Interprets power correctly100% pass
    It correctly explains that the test was designed to detect a 3pp effect, that the CI includes both harm and benefit, and that extending would detect about 2pp.
    GPT-6 Astra · ChatGPT · The underpowered onboarding test
  3. Addresses the actual decision92% pass
    The output commits to a staged rollout as the recommended action, and specifies conditions (commercial unacceptability of a 1.4pp loss or value of a 2pp improvement) that would change the call to extending the test.
    GPT-6 Astra · ChatGPT · The underpowered onboarding test

Where it slips

  1. Uses the supplied evidence correctly56% pass
    States that the change is easy to reverse, which is not supported by the supplied context.
    Haiku 5.5 · API · The underpowered onboarding test
  2. Gets the base of every number right59% pass
    The Week 1 lift figure of +4.0% is a miscalculation; the correct rate from the supplied data is about 5.6%.
    Haiku 5.5 · API · Up 6%, and significant
  3. Avoids unsupported claims59% pass
    Presents 'the change is easy to reverse' as fact without evidence from the brief or context.
    Haiku 5.5 · API · The underpowered onboarding test

How it’s graded

Each check is built on how world-class product and growth leaders do this work, as they’ve described it on Lenny’s Podcast, and names the leader it comes from.

  1. Trusts the data before reading it

    Before interpreting effects, does the analysis check whether the result is trustworthy (sample ratio, exposure or logging issues, novelty, a surprisingly large lift) and say what it found?

    Passes when Explicitly checks at least one trust signal in the supplied data, such as the split against the intended ratio, and treats a surprising result as a reason to investigate before acting.

  2. Doesn't overread an unclear result

    Does the analysis state honestly what the data can and can't show: no win claimed from an early peek or a result that isn't significant, and no 'no effect' concluded from a test too small to detect one?

    Passes when Every claim matches the strength of the evidence, and anything unclear is called unclear, with what it can't rule out.

Plus our standard checks

Uses the supplied evidence correctly · Addresses the actual decision · Respects explicit constraints · Identifies material uncertainty · Avoids unsupported claims · Produces the required deliverable · Gets the base of every number right · and 3 written for each task, which you’ll see in the tasks below.

The tasks

Read the brief, then compare up to three outputs, each with the LLM judge’s verdict on every check. Highlights mark what a PM had to fix.

The brief

You're the data-literate PM on the shopping team at Bramble. Zoe wants to recommend shipping the new home page on Monday (her note is below). Check her conclusion against the raw data and write the readout you'd send instead, in no more than 900 words: what the test shows, what it doesn't, whether we should ship, and what we should do next. Show your working.\n\nThe files are attached.

What the model was given5 items: zoe_note.md, test_design.md, daily_results.csv (users and orders per day, by user type and arm), aov_by_week.md, incident_log.md
zoe_note.md1 lines · Download
From Zoe (PM for the home page): "Orders per user are up about 6% for treatment over the 28 days, and it's significant. AOV is flat. I'm going to recommend we ship on Monday. Can you sanity-check my readout before I send it?"
test_design.md5 lines · Download
# Test design (pre-registered)

Change: a new home page that leads with "Your usual basket" (one tap to reorder) for everyone.
Split: 50/50 by user. Primary metric: orders per user over the test. Guardrail: average order value.
Planned length: 28 days, 23 September to 20 October. Decision rule: ship if the lift on orders per user is positive and significant at the end, and average order value doesn't fall by more than 2%.
daily_results.csv (users and orders per day, by user type and arm)date,user_type,control_users,treatment_users,control_orders,treatment_orders 2026-09-23,new,2089,2400,129,184 2026-09-23,returning,4995,5799,464,559 2026-09-24,new,2079,2400,130,178 2026-09-24,returning,4900,5691,455,545 2026-09-25,new,2131,2485,134,188 2026-09-25,returning,4901,5684,465,537 2026-09-26,new,2131,2445,129,187 2026-09-26,returning,4944,5680,475,538 2026-09-27,new,2055,2357,122,180 2026-09-27,returning,4978,5744,471,527 2026-09-28,new,2080,2400,127,185 2026-09-28,returning,4819,5605,447,532 2026-09-29,new,2091,2414,130,186 2026-09-29,returning,4993,5784,483,555 2026-09-30,new,2070,2382,123,169 2026-09-30,returning,4956,5708,469,529 2026-10-01,new,2121,2432,131,170 2026-10-01,returning,5042,5820,482,560 2026-10-02,new,2041,2376,122,164 2026-10-02,returning,4954,5743,478,540 2026-10-03,new,2124,2455,131,166 2026-10-03,returning,4757,5475,453,500 2026-10-04,new,2142,2493,132,172 2026-10-04,returning,4906,5671,469,542 2026-10-05,new,2146,2464,131,175 2026-10-05,returning,5045,5845,472,554 2026-10-06,new,2115,2423,126,165 2026-10-06,returning,4830,5578,440,515 2026-10-07,new,2065,2381,124,149 2026-10-07,returning,4792,5580,458,540 2026-10-08,new,2137,2446,127,160 2026-10-08,returning,4960,5748,477,554 2026-10-09,new,2089,2409,131,159 2026-10-09,returning,4977,5717,465,525 2026-10-10,new,2138,2491,127,158 2026-10-10,returning,4787,5585,451,512 2026-10-11,new,2084,2406,131,151 2026-10-11,returning,4832,5568,461,521 2026-10-12,new,2060,2365,129,153 2026-10-12,returning,5012,5755,466,531 2026-10-13,new,2075,2408,128,154 2026-10-13,returning,4869,5664,462,528 2026-10-14,new,2038,2368,124,296 2026-10-14,returning,4988,5739,480,1058 2026-10-15,new,2078,2394,130,146 2026-10-15,returning,5047,5787,469,548 2026-10-16,new,2043,2340,124,147 2026-10-16,returning,4965,5742,478,541 2026-10-17,new,2078,2403,128,152 2026-10-17,returning,4865,5625,455,518 2026-10-18,new,2157,2472,135,152 2026-10-18,returning,4789,5530,441,526 2026-10-19,new,2046,2346,124,147 2026-10-19,returning,4775,5526,442,512 2026-10-20,new,2129,2481,129,158 2026-10-20,returning,4863,5623,444,536
aov_by_week.md8 lines · Download
# Average order value by week ($, all users)

| Week | Control | Treatment |
|---|---|---|
| 1 | 48.20 | 47.90 |
| 2 | 48.40 | 48.10 |
| 3 | 48.10 | 47.80 |
…
incident_log.md3 lines · Download
# Incident log

- 14 October: a release of the order tracking service logged some order events twice for 9 hours. Fixed the same day. Engineering believes it affected the new home page only.
What a strong answer doesThe answer key the graders mark against

Doesn't recommend shipping on this readout. Checks trust first: treatment got about 53.6% of users against an intended 50/50, a sample ratio mismatch that has to be explained before any result is trusted. 14 October's treatment orders are about double the surrounding days (the logging bug in the incident log), which inflates the headline: about 5.8% lift with it, about 2.4% without. The lift fades week by week (about 5.6%, 2.5%, 0.2%, 1.1%), a novelty pattern, so the long-run effect is near zero. All of the lift is in new users (about 11.5%); returning users, the majority, show none (about -0.1%). AOV is flat, so the guardrail holds. So the pre-registered rule (significant positive lift at the end) isn't met once the data is cleaned. Next steps: find the cause of the sample ratio mismatch, rerun or extend with the logging fixed, and consider the reorder module for new users only as a separate test.

Critical failures (cap the score at 40)
  • Recommends shipping on Monday as Zoe proposed
Task

Staff-level · v1.0

The outputs

8 setups answered this brief.

Needs more than a quick edit6 of 12 checks passed

The output contains miscalculated user-day totals and fabricated weekly metrics, so a PM would need to redo the analysis before using it.

Output

To: Zoe, PM – Home Page From: Shopping Team PM Subject: Sanity Check & Readout: Home Page "Your usual basket" Experiment

---

Recommendation: Do Not Ship on Monday

We should not ship the new home page.

While the headline metric shows orders per user up +6.0% in treatment ($p < 0.01$), this number is an illusion created by two compounding issues: an uncorrected tracking outage on October 14 and a short-lived novelty spike that decayed to near-zero by Week 4. Furthermore, the test suffered a severe Sample Ratio Mismatch (SRM) that statistically invalidates the experiment.

---

What the Test Shows (The Working Behind the Numbers)

#### 1. The Headline Lift (+6.0%) is Skewed by the Oct 14 Outage Zoe’s calculation reflects raw cumulative totals: * Control: 16,560 orders / 196,118 user-days = 8.44% orders/user * Treatment: 20,234 orders / 226,108 user-days = 8.95% orders/user * Relative lift: $(8.95\% - 8.44\%) / 8.44\% = \mathbf{+5.98\%}$

However, on October 14, an order-tracking release logged duplicate events for 9 hours in treatment only. Treatment logged 296 new and 1,058 returning orders that day, compared to baseline averages of ~150 and ~530.

Removing the ~674 phantom orders from October 14 cuts cumulative treatment orders to 19,560 (8.65%), reducing the true test-wide lift from +6.0% to +2.4%.

---

#### 2. Performance Eroded Over Time (Novelty Effect, Not Habit) Breaking the data into weekly cohorts reveals that the remaining lift was concentrated entirely in the first two weeks:

WeekControl Orders/UserTreatment Orders/UserRelative LiftNotes
:---:---::---::---::---
W1 (Sep 23–29)8.46%10.38%+22.7%Initial novelty spike
W2 (Sep 30–Oct 6)8.46%9.07%+7.2%Steep decay
W3 (Oct 7–13)8.46%8.50%+0.5%Parity reached
W4 (Oct 15–20, excl. Oct 14)8.36%8.46%+1.2%Flat / non-significant

By Week 4, the conversion advantage had evaporated.

---

#### 3. Core Hypothesis Failed for Returning Users The feature was built around "Your usual basket" to streamline reordering for repeat shoppers. Yet returning users saw no meaningful lift: * Returning Users (W1–W4 excl. Oct 14): * Control: 12,492 orders / 132,497 users = 9.43% * Treatment: 14,425 orders / 152,736 users = 9.44% * Relative lift: $\mathbf{+0.1\%}$ (Flat across the entire month).

The entire early lift came from new users (W1 lift was +23.9%, dropping to +1.8% in W4). Because new users have no purchase history, their initial behavior was likely driven by curiosity or generic pre-filled items, but it did not drive sustained repeat purchasing.

---

#### 4. Critical Integrity Blocker: Severe Sample Ratio Mismatch (SRM) The experiment was pre-registered as a 50/50 split. The actual traffic split across the test was: * Control: 196,118 user-days (46.45%) * Treatment: 226,108 user-days (53.55%)

With over 422,000 total user-days, a 53.6 / 46.4 split yields a chi-square test statistic $> 2,100$ ($p < 10^{-100}$). This is a massive SRM. It indicates an underlying assignment, routing, or tracking bias (e.g., users re-randomizing into treatment or bot filtering affecting arms unequally). In standard experimentation practice, an unresolved SRM invalidates all primary and guardrail metric conclusions.

---

What the Test Doesn't Show

  1. True long-term incremental lift: Because returning user behavior was flat from Day 1 and new user behavior converged to control, we have no evidence this UI drives sustained incremental GMV.
  2. Impact on discovery: While AOV stayed within guardrails (down ~0.6% across weeks, within the -2% threshold), we do not know if "one tap to reorder" cannibalized category browsing, cross-selling, or discovery of new inventory.

---

What We Should Do Next

1. Halt Rollout: Do not ship to production on Monday. 2. Audit Randomization & Logging (P0): Partner with platform engineering to identify the root cause of the 53.6/46.4 SRM and verify that order-tracking telemetry is isolated and accurate. 3. Re-segment the Product Experience: * For Returning Users: Qualitative/UX research into why returning users did not reorder more. Did "Your usual basket" feel stale, inaccurate, or intrusive? * For New Users: Suppress "Your usual basket" for zero-order users. Replace it with an onboarding module, category discovery, or top-trending items. 4. Re-test with Proper Guardrails: Once the SRM is fixed and segmentation logic is deployed, launch a clean 50/50 A/B test powered by user-level deduplication over a full 28-day cycle.

Claims the judge couldn’t find in the brief

  • Control: 16,560 orders / 196,118 user-days = 8.44% orders/user; Treatment: 20,234 orders / 226,108 user-days = 8.95% orders/user.
  • Removing ~674 phantom orders from October 14 cuts cumulative treatment orders to 19,560 (8.65%), reducing lift to +2.4%.
  • Week 1 treatment orders/user was 10.38% (lift +22.7%), Week 2 9.07% (+7.2%), Week 3 8.50% (+0.5%), Week 4 8.46% (+1.2%).
  • Returning users (W1–W4 excl. Oct 14): Control 9.43%, Treatment 9.44%, lift +0.1%.
  • Actual traffic split: Control 196,118 user-days (46.45%), Treatment 226,108 user-days (53.55%).
  • New users' initial behavior was likely driven by curiosity or generic pre-filled items.

Grades and run details

Decision model 79 · LLM judge 46
Decision model checks
  • failUses the supplied evidence correctly21%
  • passAddresses the actual decision92%
  • passRespects explicit constraints53%
  • passIdentifies material uncertainty92%
  • partialAvoids unsupported claims41%
  • passProduces the required deliverable86%
  • passCatches the sample ratio mismatch100%
  • passRemoves the bug day100%
  • passReads the trend and who it helps91%
  • passTrusts the data before reading it100%
  • failGets the base of every number right37%
  • passDoesn't overread an unclear result36%
Run
Run
#1
API response time
67 s
Submitted
6 Oct 2026

Check by check

Open a check to read the judge’s reasons. “Mixed” means the two graders disagreed.

Got wrong 3

Uses the supplied evidence correctlyWrong

The output uses incorrect user-day totals and fabricated weekly orders/user numbers that do not match the supplied data.

Avoids unsupported claimsWrong

The weekly lift numbers and the explanation of new-user behavior are presented as fact without support from the data.

Gets the base of every number rightWrong

The user-day totals and weekly orders/user rates are computed from wrong base numbers.

Mixed 3

Produces the required deliverableMixed

The analysis contains incorrect numbers, so a PM could not act on it without redoing the calculations.

Reads the trend and who it helpsMixed

The weekly trend and new/returning split are given with numbers, but those numbers are incorrect and not drawn from the data.

Doesn't overread an unclear resultMixed

It overreads the data by presenting a fabricated weekly decay pattern as fact, rather than honestly stating what the data shows.

Got right 6

Addresses the actual decisionRight

The output clearly recommends 'Do Not Ship on Monday' early and unambiguously.

Respects explicit constraintsRight

The readout is addressed to Zoe, is under 900 words, and follows the requested format.

Identifies material uncertaintyRight

It names the SRM cause, impact on discovery, and returning-user behavior as unknowns, and says fixing the SRM and re-testing would resolve them.

Catches the sample ratio mismatchRight

It computes the split as 53.6% treatment, calls it a massive SRM, and says the cause must be found before trusting the result.

Removes the bug dayRight

It identifies the inflated orders on Oct 14, links them to the incident log, and recalculates lift without that day.

Trusts the data before reading itRight

It checks the sample ratio mismatch and the logging bug before interpreting the effect.

Results

Every setup we’ve tested on this task type, across all its tasks and repeats, graded on the current checklist. Calibrated. Where our PM checked the graders by hand, they agreed on 63% of 40 checks.

#Model · HarnessTask scoreDecision modelLLM judgeRunsCritical failures
1GPT-6 AstrawithChatGPT95.8100.02None
2Sonnet 5.5withAPI88.395.52None
3Opus 5.5withClaude80.886.42None
4GPT-6.1 SolwithAPI89.280.82None
5Haiku 5.5withAPI88.371.02None
6GPT-6 LunawithAPI88.864.72None
7Gemini 3.8 FlashwithAPI69.645.82None
8Gemini 3.5 Flash-LitewithGemini54.651.72None

What you get for the cost

No setup scores within 5 points of the leader at half its cost or less here, so the leader is also the best value.

Task score against relative cost for each setup. The table below has the same figures.4050607080901001×3×10×30×100×Cost per output, relative to the cheapest setup (log scale) →↑ Task scoreGPT-6 Astra · ChatGPT: task score 98, 107× the cheapest (1 of 2 outputs estimated)Sonnet 5.5 · API: task score 92, 35× the cheapestOpus 5.5 · Claude: task score 84, 95× the cheapest (1 of 2 outputs estimated)GPT-6.1 Sol · API: task score 83, 14× the cheapestHaiku 5.5 · API: task score 78, 1.8× the cheapestGPT-6 Luna · API: task score 75, the cheapestGemini 3.8 Flash · API: task score 55, 12× the cheapestGemini 3.5 Flash-Lite · Gemini: task score 53, 3.1× the cheapest (1 of 2 outputs estimated)GPT-6 Astra · ChatGPTSonnet 5.5 · APIOpus 5.5 · ClaudeGPT-6.1 Sol · APIHaiku 5.5 · APIGPT-6 Luna · APIGemini 3.8 Flash · APIGemini 3.5 Flash-Lite · Gemini
Nobody beats these on both score and costCost partly estimated (app runs with no usage meter)
Task score and relative cost by setup
SetupTask scoreRelative cost (cheapest = 1)
GPT-6 Luna · API751.0×
Haiku 5.5 · API781.8×
Gemini 3.5 Flash-Lite · Gemini533.1× (partly estimated)
Gemini 3.8 Flash · API5512×
GPT-6.1 Sol · API8314×
Sonnet 5.5 · API9235×
Opus 5.5 · Claude8495× (partly estimated)
GPT-6 Astra · ChatGPT98107× (partly estimated)

Cost is each output’s tokens at the model’s list price, shown relative to the cheapest setup. Runs done in an app have no usage meter, so theirs are estimated from the same setup’s measured runs. How we compare cost

About the task

The PM job

Reading a test readout and deciding what to do next.

Why it matters

Experiment readouts are where false confidence is cheapest to produce and most expensive to act on. A model that declares a winner on conversion while retention quietly falls will ship the wrong thing.

What good looks like

  • Checks the result can be trusted before interpreting it
  • Reports effects with their uncertainty
  • Checks guardrail metrics before declaring a winner
  • Separates what the data shows from plausible explanations
  • Recommends a next step proportionate to the evidence

Deliberately not measured

  • Re-running the statistics from raw data
  • Chart production
Capability tested

Interpreting results within their limits

The failure we’re looking for

Claims causality, ignores guardrails or recommends arbitrary testing

Grading

Decision model and LLM judge, calibrated against a blind PM review