Analyse experiment results

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.

Readout: new home page test (23 Sep – 20 Oct)

Recommendation: don't ship on Monday. The +6% headline comes from three things:

• A broken 50/50 split.
• A day of double-counted treatment orders.
• A new-user bump that faded to about zero by week 4.

Returning users are the people "Your usual basket" is built for, and they show no lift. None of the three problems is a reason to kill the page. They are reasons not to trust this result yet.

1. Reproducing Zoe's number

Totals across 28 days, using `daily_results.csv`, both user types:

The lift is +5.8%, which matches "about 6%". The arithmetic is right. The problems are in the data underneath it.

2. The split isn't 50/50 (sample ratio mismatch)

The test was pre-registered as 50/50. Treatment has 53.6% of users (226,652 of 422,825).

• A chi-square test against 50/50 gives χ² ≈ 2,200. The chance of that happening randomly is effectively zero.
• The gap is steady: treatment has about 15.5% more users every day, in both segments (new 1.154×, returning 1.156×).
• The new/returning mix is the same in both arms (about 30% new), so this isn't a mix-shift artefact.

A constant 15% surplus usually means assignment or exposure logging is broken. For example, treatment could be logging users that control drops, or redirects or caching could differ between arms. Until we know why, we can't assume the two groups are comparable. On its own, this fails the test's validity check, whatever the lift.

3. The 14 October incident doubled treatment orders

On 14 Oct, treatment orders roughly doubled while control stayed normal:

• New users: 296 orders in treatment, against about 150 on the days around it. Control: 124.
• Returning users: 1,058 orders in treatment, against about 530. Control: 480.

This matches the incident log: order events were logged twice, on the new home page only. That day adds about 680 phantom orders to treatment.

Excluding 14 Oct from both arms:

The overall lift drops from 5.8% to 2.4%. A naive z-test on that is about 2.3, but it treats each user-day as independent, which overstates confidence. The same user appears on many days, and the split itself is suspect.

4. The remaining lift is a fading new-user effect

New users, orders per user by week (week 4 excludes 14 Oct):

Returning users by week: +0.5%, −0.8%, −1.0%, +1.0%. That is flat, which is what noise looks like.

Overall lift went from +5.6% in week 1 to +1.1% in week 4. Two things stand out:

• The effect is decaying towards zero. That pattern looks like novelty, not a lasting change in behaviour.
• It shows up in new users, who mostly have no "usual basket" yet. It is absent in returning users, who are who the feature is for. That doesn't fit the mechanism we expected, and we should understand it before acting.

5. Average order value guardrail

Treatment AOV is $0.30 lower in weeks 1–3 (−0.6%) and $0.10 lower in week 4 (−0.2%). That is inside the 2% guardrail, so "flat" is fair.

Two caveats:

• Week 4 may include the duplicated orders.
• AOV only matters alongside order volume. With clean data, revenue per user is roughly +2.4% × 0.995 ≈ +1.8% overall, and about −0.7% for returning users.

What the test shows

• The new page probably raises early ordering among new users, at least for a couple of weeks.
• It doesn't hurt order value by enough to trip the guardrail.
• No breakage or disaster is visible.

What it doesn't show

• A valid comparison. The sample ratio mismatch means the arms may not be comparable.
• A lasting lift. By week 4 the effect is about 1%, inside the noise.
• Any effect on returning users, the target audience.
• The pre-registered metric. The test design specifies orders per user, but this file holds user-days. We need user-level data to compute it properly. The current significance claim relies on treating user-days as independent.
• That the incident only hit treatment. "Engineering believes" isn't confirmation. If control was also affected at a lower level, the 14 Oct correction above is off.

Should we ship?

No, not on this evidence.

The decision rule technically passes on the raw numbers. But it assumed a valid 50/50 split and clean order counts, and we have neither. Shipping now would lock in a 6% claim that is mostly a logging bug, an assignment bug and novelty.

Next steps

1. Find the cause of the 15% user surplus (owner: eng + analytics, this week). Compare assignment logs against exposure logs, and check bot filtering, redirects and caching per arm. Run an A/A check once it's fixed.
2. Deduplicate 14 Oct using order or event IDs, rather than dropping the day, and confirm control was unaffected.
3. Pull user-level data and recompute orders per user as pre-registered. Use proper per-user variance, or bootstrap by user.
4. Rerun once the split is fixed, for at least 4 weeks. Report results by week and by new vs returning users, with returning users as the key read. If returning users still show nothing, rethink the feature (e.g. show "usual basket" only once a user has one) rather than shipping it to everyone.
5. Investigate the new-user effect: what do new users see in the "usual basket" slot, and what are they ordering? If it's real and durable, a new-user variant could be worth its own test.

Zoe: the analysis was a reasonable first pass and the headline maths checks out. Happy to pair on the rerun plan so we can bring a clean answer back.

Readout: don’t ship the new home page on Monday. The logged data reproduce Zoe’s roughly 6% lift, but they do not yet establish a valid, durable improvement in the pre-registered metric. We have a treatment-specific measurement incident, an unexplained arm imbalance, and a lift that weakens substantially over time.

1. What the headline shows—and how I calculated it

I summed orders and reported daily users within each arm, then calculated:

\[ \text{Lift}=\frac{\text{treatment orders}/\text{treatment users}} {\text{control orders}/\text{control users}}-1 \]

Thus, the logged lift is 5.75%, consistent with “about 6%.”

However, summed daily users are not necessarily distinct randomized users. If users recur across days, this is orders per user-day, not the pre-registered orders per user over the test. If these are active or exposed users, the denominator may itself be affected by treatment. We need the denominator definition and assignment-level data before accepting the primary result.

Nor can these aggregates validate Zoe’s significance claim. For illustration, treating orders as independent Poisson counts gives:

\[ SE(\log RR)=\sqrt{1/20{,}234+1/16{,}560}=0.01048 \]

That produces a nominal 95% lift interval of approximately +3.6% to +8.0%. But it ignores repeated-user dependence, potentially treatment-dependent denominators, and corrupted order counts. It is not a valid substitute for inference at the randomized-user level.

2. The tracking incident materially inflates the result

On 14 October, treatment logged 1,354 orders, versus roughly 700 on surrounding days. Control logged 604. This aligns with the incident report, although we cannot identify the exact duplicate count from these aggregates.

As a sensitivity check, removing that entire day from both arms, including its denominators, gives:

Lift becomes 2.41%, less than half the headline. This does not prove there is no effect; equally, dropping a day is not a repaired primary analysis. We should deduplicate against authoritative order IDs, not halve the day’s orders or discard inconvenient observations.

3. The remaining signal is concentrated early and among new users

Using the same rate calculation within each week and segment:

Across all non-incident days, new-user lift is approximately +11.5%, while returning-user lift is −0.1%.

This is not evidence of a broad reorder benefit for everyone. The pattern is consistent with novelty, changing cohorts, or another time-dependent effect—not proof of any one explanation. These are exploratory comparisons, not statistically established segment differences or grounds to ship only to new users. Calendar-week results also do not measure persistence since each user’s first exposure.

4. Allocation and AOV require qualification

Treatment accounts for 53.6% of reported user-days, despite the planned 50/50 user split; the imbalance appears throughout the test. Repeated daily users prevent a valid assignment-level sample-ratio test here. It could reflect assignment problems, logging, filtering, or treatment-driven activity. We must reconcile it against unique randomized users, rather than assume either harmless imbalance or broken randomization.

Weekly AOV is down approximately 0.2–0.6%, not literally flat. Those point estimates are within the −2% guardrail, but weekly averages provide neither uncertainty nor assurance that duplication did not distort order weighting.

Decision and next steps

The pre-registered shipping rule should stand—but we have not established that it was met with valid data.

1. Reconcile assignment, eligibility, exposure, and user counts; investigate the imbalance.
2. Rebuild orders and revenue from authoritative transactions; verify the incident’s scope in both arms.
3. Recompute 28-day orders per randomized user, including zero-order users, with user-level uncertainty; recompute AOV and its uncertainty.
4. Examine pre-treatment segments and exposure-age cohorts to investigate persistence without treating exploratory findings as confirmatory.
5. If the original test cannot support a trustworthy decision, run a repaired, newly pre-registered test. Do not silently extend this fixed-horizon test until significance returns.