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 18 graded outputs by 9 models. 56% 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 correctly97% 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. Catches the sample ratio mismatch89% pass
    The output computes the split (53.6% treatment), calls it a sample ratio mismatch, and states the cause must be found before trusting the result.
    Opus 5.5 · Claude · Up 6%, and significant

Where it slips

  1. Uses the supplied evidence correctly50% 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. Avoids unsupported claims56% 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
  3. Trusts the data before reading it60% pass
    Does not check any trust signal (e.g., sample ratio, exposure) before interpreting the results.
    GPT-6 Luna · 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.1

The outputs

9 setups answered this brief.

Needs more than a quick edit10 of 12 checks passed

The user-day and order totals are miscalculated, so a PM would need to redo the arithmetic before trusting any of the numbers. The reasoning is sound, but the underlying figures can't be used as-is.

Output

Subject: Hold on Monday’s launch — Home Page ("Your usual basket") test readout

Hi Zoe, team,

I dug into the raw data to sanity-check the numbers before Monday. My recommendation is that we do not ship on Monday.

While the top-line numbers initially look like a ~5.7% lift, the test suffers from a severe randomization failure (Sample Ratio Mismatch), a logging bug on October 14 that inflated treatment orders, and a product mismatch for new users. When we clean the data and look at the final two weeks, the lift disappears completely.

Here is the full breakdown and my working.

---

1. What the raw data shows (and how we got to ~6%)

If we sum `daily_results.csv` across all 28 days: * Control: 196,353 user-days | 16,580 orders (0.08444 orders/user-day) * Treatment: 226,672 user-days | 20,231 orders (0.08925 orders/user-day) * Apparent Lift: +5.70% ($Z = 5.56, p < 0.0001$) * Guardrail (AOV): Control averaged ~$48.25 vs. Treatment ~$48.00 (-0.52%, well within our -2.0% guardrail).

However, four critical issues in the data invalidate this top-line result.

---

2. What kills the top-line conclusion (Showing the working)

#### A. Severe Sample Ratio Mismatch (SRM) The test was designed as a 50/50 split by user, yet Treatment consistently received ~15.4% more traffic every single day across both new and returning segments: * Total user-days: 196,353 Control (46.42%) vs. 226,672 Treatment (53.58%). * Chi-square test against 50/50: $\chi^2 = 2,173, p \ll 0.0001$. Even if unique users are ~1/4 of user-days, an imbalance of this magnitude is statistically impossible by chance. * Why it matters: An SRM means our assignment or tracking mechanism is broken (e.g., a redirect bug, bot filtering difference, or treatment forcing more session logs). Until we know why 15.4% more users landed in Treatment, any comparison between the two arms is biased and untrustworthy.

#### B. The October 14 double-logging incident Per the incident log, an order-tracking release double-logged orders on the new home page for 9 hours on Oct 14. You can see the exact spike in the raw data: * Oct 14 Control: 124 (new) + 480 (returning) = 604 orders (normal). * Oct 14 Treatment: 296 (new) + 1,058 (returning) = 1,354 orders (~2x the normal ~680/day). * Removing Oct 14 (27-day totals): * Control: 189,327 user-days | 15,976 orders (0.08438 orders/user-day) * Treatment: 218,565 user-days | 18,877 orders (0.08637 orders/user-day) * Adjusted Lift: Drops by more than half to +2.35% ($Z = 2.26, p = 0.024$).

#### C. User-level vs. User-day aggregation The pre-registered primary metric is orders per user over the 28-day test, which requires user-level denominators and variance. However, `daily_results.csv` reports daily active users and orders. Summing daily users gives user-days, not unique users. If the new home page alters visit frequency for returning users, the denominator (user-days) shifts, distorting the conversion rate per visit.

#### D. Segment & Novelty Breakdown: Why did New users spike in Week 1? If we break that remaining +2.35% lift down by user type and week (excluding Oct 14), we uncover a major anomaly:

SegmentControl (27d)Treatment (27d)27-Day LiftWeek 1 LiftWeek 2 LiftWeek 3 Lift (ex 14/10)Week 4 Lift
:---:---:---:---:---:---:---:---
Returning0.09429 (12,519 / 132,750)0.09426 (14,447 / 153,272)-0.03% ($p=0.98$)+0.63%+0.34%-1.49%+0.39%
New0.06110 (3,457 / 56,577)0.06785 (4,430 / 65,293)+11.04% ($p<0.001$)+23.22%+12.66%+4.23%+4.23%
All Users0.084380.08637+2.35%+5.41%+2.97%-0.29%+1.20%

Look closely at what this table tells us: 1. Zero effect on our target audience: Returning users—the only people who actually have a "usual basket" to reorder in one tap—saw -0.03% lift over the test. The feature did not move their order rate at all. 2. A phantom lift on New users: Complete newcomers (who have no "usual basket") drove 100% of the remaining lift (+23.2% in Week 1), which then decayed rapidly to +4.2% by Week 3 and Week 4. 3. Overall lift vanished in the second half: Across all users, the lift in Week 3 (-0.29%) and Week 4 (+1.20%, $Z=0.58, p=0.56$) is completely flat and statistically indistinguishable from zero.

(Note on AOV: Because Oct 14 logged single baskets twice, Week 3 AOV isn't skewed by half-value orders, though double-weighted orders slightly skew the week's average. Regardless, AOV isn't why we're holding).

---

3. What this test does and doesn't tell us

  • What it shows: After removing the Oct 14 bug, there is 0% lift on returning users, and overall lift decays to noise (+0.45% across Weeks 3–4 combined). Furthermore, the test is compromised by a 15.4% SRM.
  • What it doesn't show: True user-level cumulative orders (since we only have daily grain), what new users actually saw on the home page (an empty state? a fallback? a bug?), and why the traffic split failed.

---

4. What we should do next

1. Hold Monday's launch. Shipping based on a logging spike and a broken traffic split risks degrading the home page experience for zero real gain. 2. Investigate the SRM & New User experience with Engineering: * Why did Treatment get 15.4% more users every day? (Check bucketing logic, caching, and trigger timing). * Why did New users see a +23% spike in Week 1 that decayed? What does "Your usual basket" render for a user with no order history, and did the SRM disproportionately bucket high-intent new users into Treatment? 3. Pull user-level data: Have Data Science query deduplicated, user-level orders and AOV (excluding the 9-hour window on Oct 14) to verify if returning users increased visit frequency rather than conversion per visit. 4. Re-scope and re-test: "Your usual basket" only makes sense for returning customers with purchase history. Once the SRM bug is fixed, let's run a clean 2-week test targeted exclusively at returning users, evaluated at the unique-user level.

Happy to walk through the numbers live before you message leadership!

Claims the judge couldn’t find in the brief

  • Total user-days: Control 196,353, Treatment 226,672.
  • Total orders: Control 16,580, Treatment 20,231.
  • Removing October 14 gives 27-day totals of 189,327 Control user-days and 218,565 Treatment user-days, and an adjusted lift of +2.35%.
  • Returning users saw -0.03% lift and new users +11.04% lift over 27 days (excluding Oct 14).
  • Overall lift vanished in the second half: Week 3 (-0.29%) and Week 4 (+1.20%, Z=0.58, p=0.56) are statistically flat.

Grades and run details

Decision model 88 · LLM judge 77
Decision model checks
  • failUses the supplied evidence correctly23%
  • passAddresses the actual decision22%
  • passRespects explicit constraints61%
  • passIdentifies material uncertainty95%
  • passAvoids unsupported claims2%
  • passProduces the required deliverable35%
  • passCatches the sample ratio mismatch100%
  • passRemoves the bug day98%
  • passReads the trend and who it helps72%
  • passTrusts the data before reading it100%
  • passGets the base of every number right25%
  • partialDoesn't overread an unclear result38%
Run
Run
#1
API response time
20 s
Submitted
13 Oct 2026

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 67 · LLM judge 46
Decision model checks
  • failUses the supplied evidence correctly46%
  • passAddresses the actual decision51%
  • passRespects explicit constraints71%
  • passIdentifies material uncertainty89%
  • failAvoids unsupported claims49%
  • passProduces the required deliverable23%
  • passCatches the sample ratio mismatch100%
  • passRemoves the bug day94%
  • partialReads the trend and who it helps7%
  • passTrusts the data before reading it100%
  • failGets the base of every number right41%
  • partialDoesn't overread an unclear result25%
Run
Run
#1
API response time
67 s
Submitted
6 Oct 2026

Needs more than a quick edit4 of 12 checks passed

The analysis relies on incorrect numbers and unsupported conclusions; a PM would need to redo the entire analysis from the raw data.

Output

A/B Test Readout: New Home Page ("Your Usual Basket")

To: Zoe (PM, Shopping Team) From: Data-Literate PM Date: October 24, 2026 Subject: Sanity-check readout on the Home Page A/B test (Sept 23 – Oct 20)

*

Zoe—I’ve pulled the raw data and checked the numbers against our pre-registered design. While your top-line metric looks like a win on the surface, a deeper dive into the daily breakdown reveals a major data anomaly that completely flips our conclusion.

We should not ship on Monday. Here is what the data actually shows, why your initial read is misleading, and what we need to do next.

---

1. Working & Data Breakdown

Let’s aggregate the 28-day totals from `daily_results.csv` by summing total users and orders across the test window:

  • Control Arm:
  • New Users: ~58,698 user-days | 3,556 orders
  • Returning Users: ~137,367 user-days | 12,949 orders
  • Total Control Orders: 16,505
  • Treatment Arm:
  • New Users: ~67,820 user-days | 4,505 orders
  • Returning Users: ~158,837 user-days | 15,084 orders
  • Total Treatment Orders: 19,589

If we simply take the aggregate ratio of orders to user-days, treatment appears to show a healthy lift. However, two critical factors invalidate a straightforward shipping decision: the October 14 data contamination incident and a sharp downward trend over time.

#### The October 14 Incident (The Smoking Gun) Check the `incidentlog.md` and `dailyresults.csv` for October 14: * Control: 124 new user orders, 480 returning user orders. * Treatment: 296 new user orders, 1,058 returning user orders! (More than double normal volume).

An engineering bug logged order events twice for 9 hours on October 14, exclusively affecting the treatment arm. If we remove October 14 from the dataset and recalculate the totals: * Treatment orders drop by 1,354 (296 $\rightarrow$ ~155 for new; 1,058 $\rightarrow$ ~530 for returning). * Adjusted Treatment Orders: ~18,235.

When you control for this logging artifact, the apparent 6% overall lift vanishes.

#### The Trend Line (Novelty vs. Fatigue) Even more concerning than the incident is the trajectory of the test. Let’s look at the treatment vs. control order lift week-by-week (normalized by user-day volume): * Week 1 (Sept 23–29): Treatment orders per user-day ran ~11.5% higher than control. * Week 2 (Sept 30–Oct 6): Lift compressed to ~6.5%. * Week 3 (Oct 7–13, pre-incident): Lift compressed further to ~2.8%. * Week 4 (Oct 15–20, post-incident): Lift hovered near +1.2% to +2.0%.

The treatment experienced a massive novelty effect. Users loved the "one-tap reorder" novelty in week one, but engagement steadily eroded every single week until it flatlined near zero by the end of the test.

(Note on AOV: As you noted, AOV remained flat across all 4 weeks at ~$48.00–$48.30 for both arms, successfully passing our guardrail criteria—but a flat AOV doesn't save a primary metric that is dying out).

---

2. What the Test Actually Shows

  1. A Severe Novelty Effect: The home page redesign generated short-term excitement, but long-term sustained engagement for the "Your Usual Basket" feature is weak. By week three and four, the feature stopped driving incremental orders.
  2. Zero Net Long-Term Lift: Once you excise the duplicate logging events from October 14, the actual organic lift over 28 days is negligible and statistically insignificant.
  3. AOV Guardrail Passed: The feature did not cannibalize basket sizes. Customers ordering via the one-tap shortcut spent roughly the same per order as control users.

---

3. What the Test Does Not Show

  • It does NOT show a permanent 6% increase in orders. That figure is an artifact of combining uncleaned incident data with outsized first-week novelty behavior.
  • It does NOT show user frustration or churn. AOV is flat and user counts remained stable in treatment, meaning the feature isn't hurting the experience—it's just failing to create a lasting habit.

---

4. Recommendation: Do Not Ship on Monday

We should hold off on shipping the new home page. Launching it now would mean shipping a feature that currently provides zero net business value after the initial novelty wears off, while locking in UI space for a component that isn't pulling its weight.

---

5. Next Steps

  1. Clean the Data & Re-run Stats: Have data engineering pull a properly deduplicated user-level dataset for the 28 days (excluding the Oct 14 telemetry glitch entirely) to get the true p-value on the clean sample.
  2. Segment Analysis by User Frequency: "Your Usual Basket" assumes users have a habitual, repetitive basket. Let's slice the data by user tenure and order frequency. Did it work brilliantly for high-frequency weekly buyers while failing for monthly/new buyers? If so, we might have a targeted personalization play.
  3. UX Iteration: If high-frequency users did retain value, consider a hybrid home page where one-tap reordering is surfaced dynamically only to returning users with high purchase frequency, rather than the blanket "for everyone" treatment tested here.

Claims the judge couldn’t find in the brief

  • Control Arm totals: ~58,698 new user-days, 3,556 orders; ~137,367 returning user-days, 12,949 orders; total 16,505 orders.
  • Treatment Arm totals: ~67,820 new user-days, 4,505 orders; ~158,837 returning user-days, 15,084 orders; total 19,589 orders.
  • Adjusted Treatment Orders after removing Oct 14: ~18,235.
  • Week 1 lift ~11.5%, Week 2 ~6.5%, Week 3 ~2.8%, Week 4 +1.2% to +2.0%.
  • The apparent 6% overall lift vanishes after removing Oct 14.
  • The actual organic lift over 28 days is negligible and statistically insignificant.
  • The home page redesign generated short-term excitement (novelty effect) and long-term engagement is weak.
  • By week three and four, the feature stopped driving incremental orders.

Grades and run details

Decision model 42 · LLM judge 31
Decision model checks
  • failUses the supplied evidence correctly83%
  • passAddresses the actual decision13%
  • passRespects explicit constraints58%
  • partialIdentifies material uncertainty62%
  • failAvoids unsupported claims83%
  • failProduces the required deliverable56%
  • failCatches the sample ratio mismatch98%
  • passRemoves the bug day49%
  • partialReads the trend and who it helps76%
  • passTrusts the data before reading it86%
  • failGets the base of every number right69%
  • failDoesn't overread an unclear result30%
Run
Run
#1
Time to output
7 s
Submitted
5 Oct 2026

Check by check

Where the outputs differ comes first. Open a check to read the judge’s reasons. “Mixed” means the two graders disagreed.

Where they differ 7

Avoids unsupported claimsRightWrongWrong
Gemini 4 Argon · API

Causes and hypotheses (e.g., possible reasons for SRM, new-user spike) are presented as questions, not as established facts.

Gemini 3.8 Flash · API

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

Gemini 3.5 Flash-Lite · Gemini

It presents the novelty effect, the feature stopping incremental orders, and statistical insignificance as established facts without labelling them as hypotheses.

Produces the required deliverableRightMixedWrong
Gemini 4 Argon · API

It is a complete readout for the named reader, within the word limit, and could be used after fixing the arithmetic errors.

Gemini 3.8 Flash · API

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

Gemini 3.5 Flash-Lite · Gemini

The readout contains incorrect numbers, so a PM cannot act on it without redoing the analysis; it is not usable as-is.

Catches the sample ratio mismatchRightRightWrong
Gemini 4 Argon · API

Output computes the split (~46.4/53.6) and states that the cause of the mismatch must be found before trusting the result.

Gemini 3.8 Flash · API

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

Gemini 3.5 Flash-Lite · Gemini

The output never computes the user split or mentions the sample ratio mismatch (treatment got ~53.6% of users).

Removes the bug dayRightRightMixed
Gemini 4 Argon · API

Identifies 14 October spike, links it to the incident log, and recalculates overall lift without that day (directionally correct, though exact numbers are flawed).

Gemini 3.8 Flash · API

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

Gemini 3.5 Flash-Lite · Gemini

It identifies the Oct 14 bug but the recalculation is wrong and it does not state the corrected lift falls to about 2-3%.

Reads the trend and who it helpsRightWrongWrong
Gemini 4 Argon · API

Provides weekly trend and new-vs-returning split with numbers and concludes the lift fades and comes only from new users.

Gemini 3.8 Flash · API

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

Gemini 3.5 Flash-Lite · Gemini

It gives weekly trend numbers but does not show the new vs returning split or that the lift comes only from new users.

Gets the base of every number rightMixedWrongWrong
Gemini 4 Argon · API

Derived figures (user-day totals, order totals, lift percentages) are based on incorrectly summed denominators; the arithmetic does not check out against the supplied data.

Gemini 3.8 Flash · API

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

Gemini 3.5 Flash-Lite · Gemini

Derived figures (totals, weekly lifts, adjusted orders) are not computed correctly from the supplied data.

Doesn't overread an unclear resultRightWrongWrong
Gemini 4 Argon · API

The analysis does not claim a win or 'no effect' from an underpowered test; it states what the data can and cannot show and calls the result unclear.

Gemini 3.8 Flash · API

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

Gemini 3.5 Flash-Lite · Gemini

It claims the lift is negligible and statistically insignificant without a proper test, overreading an unclear result.

All got wrong 1

Uses the supplied evidence correctlyWrongWrongWrong
Gemini 4 Argon · API

Several key figures (user-day totals, order totals, and derived lift and segment numbers) are miscalculated; they do not follow correctly from the supplied data by arithmetic.

Gemini 3.8 Flash · API

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

Gemini 3.5 Flash-Lite · Gemini

Multiple key numbers (user-days, orders, adjusted totals, weekly lifts) are invented and do not match the supplied data.

All got right 4

Addresses the actual decisionRightRightRight
Gemini 4 Argon · API

Output unambiguously recommends not shipping on Monday and identifies conditions (investigate SRM, fix logging, re-test) that would change the call.

Gemini 3.8 Flash · API

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

Gemini 3.5 Flash-Lite · Gemini

The output clearly says 'We should not ship on Monday' and states that a clean dataset and true p-value would change the call.

Respects explicit constraintsRightRightRight
Gemini 4 Argon · API

Readout is within 900 words, addresses Zoe and the team, and does not propose shipping on Monday.

Gemini 3.8 Flash · API

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

Gemini 3.5 Flash-Lite · Gemini

The readout is addressed to Zoe, is under 900 words, and includes the requested sections.

Identifies material uncertaintyRightRightRight
Gemini 4 Argon · API

Identifies specific unknowns (SRM cause, what new users saw, true user-level metrics) and says how they would be resolved.

Gemini 3.8 Flash · API

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.

Gemini 3.5 Flash-Lite · Gemini

It names the need for a deduplicated dataset, segment analysis, and UX iteration to resolve unknowns.

Trusts the data before reading itRightRightRight
Gemini 4 Argon · API

Before interpreting the effect, the analysis checks the split ratio, the logging bug, and novelty decay, treating the surprising result as reason to investigate.

Gemini 3.8 Flash · API

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

Gemini 3.5 Flash-Lite · Gemini

It checks the Oct 14 logging incident as a trust signal 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 60% of 40 checks.

#Model · HarnessTask scoreDecision modelLLM judgeRunsCritical failures
1GPT-6 AstrawithChatGPT91.7100.02None
2Sonnet 5.5withAPI84.695.52None
3Opus 5.5withClaude88.386.42None
4GPT-6.1 SolwithAPI76.380.82None
5Haiku 5.5withAPI82.571.02None
6GPT-6 LunawithAPI78.364.72None
7Gemini 4 ArgonwithAPI68.865.72None
8Gemini 3.5 Flash-LitewithGemini53.351.72None
9Gemini 3.8 FlashwithAPI63.345.82None

What you get for the cost

Sonnet 5.5 · API scores within 5 points of GPT-6 Astra · ChatGPT at a third of the cost.

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 96, 107× the cheapest (1 of 2 outputs estimated)Sonnet 5.5 · API: task score 91, 35× the cheapestOpus 5.5 · Claude: task score 88, 95× the cheapest (1 of 2 outputs estimated)GPT-6.1 Sol · API: task score 78, 14× the cheapestHaiku 5.5 · API: task score 76, 1.8× the cheapestGPT-6 Luna · API: task score 70, the cheapestGemini 4 Argon · API: task score 64, 14× the cheapestGemini 3.5 Flash-Lite · Gemini: task score 53, 3.1× the cheapest (1 of 2 outputs estimated)Gemini 3.8 Flash · API: task score 52, 12× the cheapestGPT-6 Astra · ChatGPTSonnet 5.5 · APIOpus 5.5 · ClaudeGPT-6.1 Sol · APIHaiku 5.5 · APIGPT-6 Luna · APIGemini 4 Argon · APIGemini 3.5 Flash-Lite · GeminiGemini 3.8 Flash · API
Best valueNobody 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 · API701.0×
Haiku 5.5 · API761.8×
Gemini 3.5 Flash-Lite · Gemini533.1× (partly estimated)
Gemini 3.8 Flash · API5212×
GPT-6.1 Sol · API7814×
Gemini 4 Argon · API6414×
Sonnet 5.5 · API9135×
Opus 5.5 · Claude8895× (partly estimated)
GPT-6 Astra · ChatGPT96107× (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