Analyse experiment results

Readout: Home page test ("Your usual basket")

To: Zoe Re: Monday ship recommendation

Recommendation: don't ship Monday. The readout overstates the result. The test has a sample ratio problem, a logging incident inside the test window, and a lift that is fading. Next steps are at the end.

Working

I summed the daily CSV across all 28 days. The file gives daily active users and orders, so each "user" is a user-day. That matters for the first finding below.

Correction: on 14 October, treatment orders were about double the surrounding days (new: 296 vs ~150; returning: 1,058 vs ~530). I replaced that day with half the logged value. Using the average of the adjacent days gives nearly the same answer (+2.2%).

What the test shows

1. The split isn't 50/50. Treatment received 53.6% of user-days, and the ratio holds every day (roughly 2,400 treatment vs 2,090 control among new users, and 5,700 vs 4,900 among returning users). Against an expected 50/50 split, the chi-square statistic is over 2,000. This is a sample ratio mismatch. It usually means assignment, bucketing, or event logging is broken, and it undermines any comparison between arms until it's explained.

2. The 6% headline is mostly the incident. The raw lift is +5.7%. Once the 14 October double-count is removed, it's +2.2%. Engineering's belief that the incident "affected the new home page only" doesn't match the data. Control on that day was normal, and the spike appeared in both new and returning treatment users. Treatment was affected across the board.

3. The lift is fading. Corrected weekly lift on orders per user-day:

This looks like a novelty effect. Returning users, who are the people the feature is built for, show roughly zero lift overall once corrected (treatment 0.0940 vs control 0.0943).

4. The lift is concentrated in new users, which is suspicious. New users go from 0.0612 to 0.0681 per user-day (+11%). A reorder feature should help returning users most, since they have baskets to reorder. Combined with the SRM, this points toward a measurement artifact, possibly in how new users are counted, until shown otherwise.

5. AOV passes the guardrail. Treatment AOV averages $48.00 vs $48.25 for control, a gap of 0.5%. This is inside the 2% limit. The gap narrowed to 0.2% in week 4, which is the incident week, so I can't rule out the duplicate events affecting AOV. Revenue per user is only up about 0.3% in week 4, once the lower AOV is included.

What the test doesn't show

• Significance. Even corrected, a simple Poisson approximation gives z ≈ 2, which is borderline. Days aren't independent, so a proper clustered analysis would likely be weaker. The pre-registered rule requires a positive and significant lift at the end of the test. The end of the test shows about +0.5%, so the rule isn't met.
• Per-user outcomes. The file only has daily counts. The design specifies orders per user over the test. Without unique user IDs we can't measure that, and repeat users are counted once per active day.
• Long-run effect. Four weeks with a decaying effect doesn't tell us the steady state.

Decision

Don't ship Monday. The pre-registered rule isn't met. The SRM invalidates the comparison until explained. The incident contaminates the final week. The best estimate of the lift is near zero and falling.

Next steps

1. Resolve the SRM this week. Check bucketing logic, whether treatment users get a different login or app path that changes logging, and whether control users are dropped somewhere. Don't analyse further until this is explained.
2. Get the incident fixed in the data. Rebuild order counts from deduplicated events for 14 October and confirm which arms and user types were affected. Ask engineering to explain why control wasn't affected.
3. Pull user-level data. Rerun the primary metric on unique users over the test window, with the pre-registered definition.
4. Test the novelty explanation. Check whether returning users' use of the one-tap reorder changes over time. If it doesn't stick, the feature isn't working for the people it targets.
5. Decide the next test. If the SRM is fixed, consider a rerun with a fresh 50/50 split and a 4–6 week window. Predefine the analysis of new vs returning users, and set a stopping rule that accounts for novelty decay. If the SRM can't be fixed, we start again.
6. Report back on the revised numbers before any ship decision.

Recommendation: don’t ship on Monday. The reported ~6% lift is reproducible, but it includes a treatment-specific tracking incident. The supplied aggregates also cannot establish significance for the pre-registered, user-level metric. We have a promising signal—not a reliable launch decision.

What the raw data shows

I summed orders and daily user counts across the 28 days:

The calculation is:

\[ \text{Lift}=\frac{20,234/226,652}{16,560/196,373}-1=5.86\%. \]

So Zoe’s arithmetic is right for this aggregate ratio. However, summed daily users are not necessarily unique randomized users. If people appear on multiple days, this is orders per user-day, not the pre-registered orders per user over the test.

The tracking incident materially changes the result

On 14 October, treatment recorded 1,354 orders versus 604 in control, with 8,107 versus 7,026 daily users. Treatment’s order rate was almost twice its normal level. That is consistent with the documented duplicate-event incident.

As a sensitivity check only, removing that entire day from both arms gives:

\[ \text{Lift excluding 14 October} =\frac{18,880/218,545}{15,956/189,347}-1 =2.52\%. \]

The remaining signal is positive, but much smaller. Dropping a whole day is not a valid substitute for recovering actual orders: the incident lasted nine hours, and that day also contains legitimate transactions.

The effect is not stable or broad-based

Using the same aggregate calculation:

Excluding the incident day, the full-period lift is +11.9% for new users and −0.14% for returning users. New-user weekly lifts decline from approximately 24.0% to 15.0%, 4.7%, and 2.5%.

That suggests the remaining aggregate gain is concentrated among new users and may be fading. It does not prove novelty: calendar effects, changing cohorts, or instrumentation could also explain the pattern. Nor does a positive new-user estimate alone establish a statistically reliable difference between segments.

What we cannot conclude yet

“Significant” is not established by these files. For the intended user-randomized analysis, we need unique assigned users—including users with zero orders—and each user’s deduplicated order count. Daily aggregates do not provide the user-level variance or account for repeated appearances. Treating user-days as independent could overstate precision.

The denominator needs investigation. Treatment has 15.4% more summed daily users than control, despite the planned 50/50 assignment, with an imbalance throughout the test. This is a warning, not proof of assignment failure: if these are active users, treatment could change activity. Check assignment counts separately from exposure/activity counts. An activity-conditioned denominator can change the estimand and introduce bias.

AOV is slightly down, not flat. Weekly declines range from approximately 0.2% to 0.6%, all within the 2% guardrail. Weighting the reported weekly averages by logged order counts gives approximately $48.25 control versus $48.01 treatment, or −0.51%. That is descriptively reassuring, but duplicate orders may distort the weights or AOV calculation. These summaries also lack uncertainty estimates.

What we should do next

1. Reconcile against canonical transactions. Deduplicate using order IDs and validate the incident’s actual scope rather than assuming only treatment was affected.
2. Audit randomization and denominators. Check unique assignments, eligibility, exposure logging, missing users, and sample-ratio mismatch.
3. Recompute the pre-registered analysis: intention-to-treat orders per unique assigned user over the full 28 days, with user-level confidence intervals; recompute AOV from valid orders and revenue.
4. Apply the original decision rule to that repaired result. If lift is positive and significant and the AOV guardrail passes, shipping becomes defensible. If trustworthy recovery is impossible, rerun with fixed instrumentation and a pre-specified duration and analysis.
5. Investigate durability and targeting separately. Pre-specify new/returning-user interactions and time-since-exposure analyses in follow-up work. Don’t use this post-hoc segment result to justify a targeted launch.

Bottom line: pause the launch, repair the measurement, and decide on the registered metric—not the contaminated headline.

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:

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.