Experiment specification

Experiment spec: delivery date and fee on the basket page

Owner: Checkout PM · Squad: Checkout · Status: Draft for review

1. Hypothesis

Showing the delivery date and delivery fee on the basket page, before checkout, instead of only on the final checkout step, will increase orders per basket session (checkout completion) by at least +0.19 percentage points (about +3% relative, from 6.35% to 6.54%).

Mechanism: shoppers who learn the fee at the final step are surprised by it and leave. Seeing it early removes that surprise.

Counter-risk: some shoppers who would have paid the fee will leave at the basket page instead. The guardrails below test for this.

2. Population, unit and randomisation

• Population: all signed-in users who reach the basket page on app or web.
• Unit of randomisation: user, not session. Users average 3.8 checkout sessions a month, and 31% shop on both app and web. Session-level randomisation would show the same person both versions.
• Method: hash of the cross-platform user ID, salted per experiment, assigned 50% control / 50% treatment. The same assignment applies on app and web.
• Stratification: check balance by platform. App converts at 7.09% and web at 5.32% (see §4), and app is 57.9% of sessions.
• Dependency: this needs a cross-platform user ID. If we only have device or cookie IDs, cross-device contamination must be estimated before launch.

3. Metrics

Primary - Orders per basket session = orders ÷ basket sessions. Baseline 6.35%. This captures both early exits (at basket) and late exits (at checkout). Denominator needs confirming with the data team (see §8).

Secondary - Checkout-start rate from basket. - Average order value (baseline $64). - Orders per user over 14 days. - All of the above split by platform and by Pay later exposure (see §5).

Guardrails - Basket exit rate (leaving the basket without starting checkout). Must not rise by more than 0.5 percentage points absolute. This is the main test of the early-leave risk. - AOV must not fall by more than 2% ($1.28). - Delivery-fee contacts (support tickets mentioning fee) per 1,000 orders must not rise by more than 10%. - Order cancellations within 24 hours must not rise.

4. Sample size and duration

Baseline (from `checkouttrafficlast8weeks.csv`, 10 Aug to 4 Oct, 56 days): - Checkout sessions: 2,083,390 (about 260,000 a week, 37,000 a day) - Orders: 132,196 - Conversion: 132,196 ÷ 2,083,390 = 6.35% - Weekly range: 6.31% to 6.39% - App: 85,526 ÷ 1,206,537 = 7.09% (1,206,537 sessions) - Web: 46,670 ÷ 876,853 = 5.32% (876,853 sessions)

Power calculation (two-sided α = 0.05, power 80%, p₁ = 0.0635, p₂ = 0.0655): - Variance sum: 0.0635 × 0.9365 + 0.0655 × 0.9345 = 0.05946 + 0.06121 = 0.12067 - (z₀.₉₇₅ + z₀.₈₀)² = (1.96 + 0.8416)² = 7.849 - n per arm = 7.849 × 0.12067 ÷ (0.0020)² = 0.9472 ÷ 0.000004 = 236,800 sessions - Design effect for repeat sessions per user, assumed 1.2: 236,800 × 1.2 = 284,000 per arm, 568,000 total

Duration: - Traffic per arm: 260,000 ÷ 2 = 130,000 a week. - 284,000 ÷ 130,000 = 2.2 weeks. Two weeks is too short: it does not cover the full weekday cycle and gives no margin. - Run 3 full weeks (21 days). That gives 390,000 sessions per arm, which exceeds the 284,000 needed. Each weekday appears three times.

Sensitivity: detecting +0.10 pp needs 0.9472 ÷ 0.000001 × 1.2 ≈ 1.14M per arm, about 9 weeks. Not feasible, so +0.19 pp is the smallest effect this test can detect.

5. Calendar and overlaps

Proposed window: launch Mon 12 Oct, run 21 days, end Sun 1 Nov. Readout by 5 Nov, decision before the 16 Nov freeze.

• Must start by 26 Oct to finish before 16 Nov, so there is no slack for later starts.
• Pay later overlap: our test runs alongside Pay later until 9 Nov. Randomise independently (separate salt) so the two effects cross, and analyse the interaction. A 2×2 readout is enough. If Pay later changes how people respond to fees, the interaction term will show it.
• Search overlap: the search test runs until 30 Oct and changes which products people add to baskets. Monitor basket-value mix in both arms. Not a blocker.

6. Analysis

• Pre-registered, one readout at day 21. No interim peeking.
• Two-sided test for the primary metric; report 95% CI.
• SRM check: expected 50/50 split. Flag if the split is off by more than 0.5% and do not read results until resolved.
• Cluster-robust SEs by user.
• Pre-specified subgroups: platform, Pay later exposure. Report only; no decisions on them.

7. Decision rule

8. Open questions and data gaps

1. Basket session counts are missing. The CSV only has checkout sessions. Without basket sessions the primary metric and basket exit rate cannot be measured. Data team to supply by 8 Oct or we fall back to checkout-based conversion, which misses early exits.
2. Audience numbers do not reconcile. The data team says 412,000 people placed an order in the last 30 days, but the CSV shows about 71,000 orders a month (132,196 ÷ 56 × 30 ≈ 70,800). At 3.8 sessions a month, 412,000 buyers would imply about 1.57M checkout sessions a month, against about 1.13M in the CSV (260,000 × 4.33). One of these definitions is wrong. I used the CSV, which is daily and specific to checkout, for all sample sizes.
3. Cross-platform user ID. Needed for user-level randomisation (§2).
4. Confirm launch date and build owner. Build must be ready by 9 Oct for a 12 Oct launch.

Experiment spec: delivery date and fee on the basket page

Owner: Checkout PM · Status: Draft. Blocked on one data question (see 0).

0. Data question to resolve before launch

The two sources disagree badly:

• CSV: about 16,525 orders a week, or about 70,800 per 30 days.
• Data team: 412,000 people ordered at least once in 30 days, so at least 412,000 orders.
• Sessions: 412,000 × 3.8 = about 1.57M checkout sessions a month. The CSV shows about 1.12M.

The CSV may cover one region or a subset, or the definitions may differ. I've sized the test on the CSV because it is the conservative figure. If real traffic is about 6× higher, the test still runs the full 4 weeks to cover the weekly cycle. It would simply detect a smaller effect.

1. Hypothesis

Showing the delivery date and fee on the basket page removes the "surprise fee" at the final step. That reduces last-step abandonment and increases orders per shopper.

The counter-risk is that some shoppers leave at the basket instead. The test measures the net effect of both.

2. What's randomised and how

• Unit: account ID, 50/50. It is not the session. Buyers average 3.8 checkout sessions a month, and 31% use both app and web. Session-level randomisation would show the same person both versions and contaminate the result.
• Assignment point: first basket-page view in the test window, with the assignment held for the whole test.
• Logged-out web baskets: use the device cookie, then map to the account at login. Accounts that end up in both arms are excluded, and the rate is reported.
• Platforms: both, with app and web as pre-registered segments.
• Run first: a 2-day A/A check for sample-ratio mismatch.

Why the metric can't be "orders ÷ checkout sessions": the treatment changes who starts checkout. People who leave at the basket drop out of the denominator, which would inflate the treatment's rate. The denominator must be fixed at the point of assignment.

3. Metrics

Primary: orders per assigned account during the test window.

Secondary (diagnostic): - Basket → checkout start rate. Expected to fall; this is the risk the squad named. - Final-step abandonment rate. Expected to fall. - Basket → order conversion, split by app and web. - Share of baskets topped up to reach a free-delivery threshold, if one exists.

Guardrails (any breach blocks shipping): - Average order value (baseline $64): no drop of more than 2%. - Delivery-fee revenue per order: no significant drop. Must be explained if it moves. - Basket-page load time (p75): no increase of more than 100 ms. Basket-page error rate: no increase. - Customer contacts about fees or delivery date: no significant increase. - Sample-ratio mismatch: p > 0.001.

Note: the 30-day repeat rate (38%) can't be read inside the window. It becomes a follow-up read 30 days after the test ends.

4. Sample size and duration

Baseline from 8 weeks of CSV data (10 Aug – 4 Oct):

• Weekly volume is very stable: about 260,424 sessions and 16,525 orders a week.
• Weekdays run about 40% above weekends, so the test must run whole weeks.

Minimum detectable effect: a 3% relative lift, from 6.345% to 6.535% (+0.190 pp). At current volume that is about 496 orders a week, or about $31.7k a week at $64 average order value.

Calculation (α = 0.05 two-sided, 80% power):

• n per arm = (1.96 + 0.84)² × [p₁(1−p₁) + p₂(1−p₂)] / d²
• = 7.84 × (0.05942 + 0.06108) / 0.0019035²
• = 0.9447 / 3.623×10⁻⁶
• ≈ 260,750 sessions per arm, or 521,500 in total

Adjusting for repeat users: randomising by account means sessions from the same user are correlated. I've applied a design effect of 1.5 because the true clustering factor is unknown:

• 521,500 × 1.5 = 782,000 sessions
• ÷ 260,424 a week = 3.0 weeks

Planned duration: 4 full weeks. The extra week covers uncertainty in the clustering factor. It also leaves enough power for a directional read on app and web separately (each about 0.5–0.6 of total traffic).

The analysis will use account-level orders with variance computed directly from the data, so the 1.5 design effect is not baked into the result.

5. When it can run

Waiting until Pay later ends (10 Nov) leaves only 6 days before the freeze, which is too short. So we run alongside it.

Dates: - Build and A/A check: 5–11 Oct. - Test: Mon 12 Oct – Sun 8 Nov. That is exactly 4 weeks. It ends the day before Pay later finishes, so Pay later's 50/50 split is constant for our whole test. - Analysis and ship decision: 9–13 Nov, before the freeze.

6. Decision rule (pre-registered)

1. Ship if the primary lift is positive and significant (p < 0.05), no guardrail is breached, and sample-ratio mismatch passes. 2. Don't ship if: - the primary is significantly negative, or - any guardrail is breached.

Either way, investigate whether the basket-stage drop outweighed the last-step gain. 3. Flat result (confidence interval within ±3%, no guardrail breach): ship only if final-step abandonment fell significantly, on the grounds of transparency. Otherwise keep control. 4. Pay later interaction: if the effect differs significantly between Pay later arms, report the effect within each arm. The ship decision then follows Pay later's own launch decision. 5. No early stopping on the primary metric. A guardrail breach above a pre-set threshold may stop the test early.

Experiment Specification: Early Delivery Fee & Date Preview

Author: PM, Checkout Squad Date: October 2026

---

1. Hypothesis

Showing the delivery date and delivery fee on the basket page (pre-checkout) will reduce final-step checkout abandonment by setting upfront expectations. * Core Hypothesis: The reduction in late-stage drop-off outweighs any early-stage basket abandonment caused by friction, resulting in a net positive impact on overall checkout conversion.

2. Randomisation Strategy & Unit

• Unit of Randomization: User ID (sticky across app and web platforms, given 31% multi-platform usage).
• Allocation: 50% Control (status quo: fee shown on final checkout step), 50% Treatment (fee and date visible on the basket page).

3. Metrics

• Primary Metric: Checkout Conversion Rate (Completed Orders / Unique Checkout Sessions).
• Secondary Metrics:
• Basket-to-Checkout Drop-off Rate (users leaving before entering checkout).
• Average Order Value (AOV).
• Guardrail Metrics:
• Total Orders / Gross Merchandise Value (GMV).
• 30-day Repeat Purchase Rate.

---

4. Traffic Analysis & Sample Size Sizing (The Sums)

Real Traffic Baseline (from past 8 weeks data): * Summing the 8-week dataset (56 days): * Total App Checkout Sessions = 1,304,784 (~23,300/day) * Total Web Checkout Sessions = 959,183 (~17,128/day) * Total Combined Sessions (8 weeks) = 2,263,967 * Daily Average Traffic = 40,428 checkout sessions/day * Total Orders = 155,752 * Baseline Conversion Rate ($p$) = $155,752 / 2,263,967 \approx 6.88\%$

Sample Size Calculations: To detect a relative change of 2% in conversion rate (e.g., from 6.88% to 7.02%) with $\alpha = 0.05$ (two-tailed) and power $(1-\beta) = 0.80$: * Using standard sample size formulas for proportions, we require approximately 375,000 users per variant (~750,000 total sessions). * At our baseline traffic of ~40,428 sessions/day (split 50/50 = ~20,214 sessions per variant daily): * Required Duration = $750,000 / 40,428 \approx 18.5$ days. * We will round up to 3 full weeks (21 days) to cleanly account for day-of-week seasonality (grocery ordering behaves very differently on Saturdays vs. Mondays).

---

5. Calendar & Timing

• Overlaps & Conflicts:
• Search squad: Runs exclusively on search results pages. Zero overlap with checkout/basket flows. Safe to run concurrently.
• Payments squad ("Pay later"): Runs on the checkout page (affecting 50% of users) until 9 November. Because the checkout page is downstream of our intervention (basket page), running both creates a multi-variate interaction risk if not accounted for.
• Holiday/Promo Constraints:
• Black Friday promotions start November 20.
• Code freeze begins November 16.
• Proposed Window:
• Start: Monday, October 12, 2026
• End: Monday, November 2, 2026 (Exactly 21 days).
• Note: This completely clears the Payments squad end-date (Nov 9) by launching earlier, and sits safely clear of the November 16 code freeze.

---

6. Decision Rule

We will evaluate the experiment after exactly 21 days of data collection.

1. Ship (Rollout 100%): If the Primary Metric (Checkout Conversion Rate) shows a statistically significant positive lift ($p < 0.05$), and no guardrail metrics (GMV, 30-day repeat rate) drop significantly.
2. Iterate / Inconclusive: If the primary metric shows no statistically significant change ($p \ge 0.05$), but secondary metrics show positive intent shifts, review basket abandonment drop-offs and redesign the UI placement.
3. Rollback: If the Primary Metric drops significantly ($p < 0.05$) due to early basket abandonment outweighing final-step savings, or if guardrail metrics degrade, immediately halt the experiment and revert to control.