Experiment specification

Experiment Spec: Delivery Fee in Basket

To: Ravi (build), Ines (analysis), Chloe (approval) From: PM, Checkout Status: For approval

What changed from the draft

• Primary metric moved from checkout completion to basket-to-order conversion. Completion only measures people who reach checkout, so it would miss the risk Chloe raised: people leaving before checkout.
• Randomise by customer, not session. Half of each week's viewers are returning customers. Session splits would show the same person both versions.
• Fixed duration, pre-set sample size. Checking daily and stopping at first significance inflates false positives.
• Free-delivery banner removed. It changes the same thing we're measuring, so we couldn't attribute any effect. We'll propose it as a separate test.

Hypothesis

Showing the delivery fee in the basket changes basket-to-order conversion. We expect an increase of at least 0.5 percentage points (8.0% to 8.5%). The test is two-sided, so a decrease would also be recorded and acted on.

Variants

• Control: Basket as today. Fee appears only on the final checkout step.
• Variant: Basket shows a delivery line under the subtotal: "Delivery: £3.99" or "Delivery: free" once the basket is over £60. Checkout is unchanged.

Ravi: The line must update live as the basket crosses the £60 threshold, and must match the fee charged at checkout exactly.

Population and randomisation

• All customers who view their basket during the test period.
• Randomise 50/50 by customer ID at first basket view in the test. Assignment stays fixed for the whole test.
• Run a sample ratio mismatch (SRM) check on day 1. If the split deviates from 50/50 at p < 0.01, pause and investigate before continuing.

Metrics

Primary: Basket-to-order conversion. Customers who place an order within 7 days of their first basket view in the test, divided by customers who viewed their basket. Baseline: 8%.

Guardrails: - Checkout start rate (checkout starts ÷ basket viewers). Ines to pull baseline. - Checkout completion rate. Baseline: 62%. - Average order value. Baseline: £47. - Delivery-fee support contacts per 1,000 orders. Ines to pull baseline; currently 12% of all contacts.

Sample size and duration

• Baseline 8.0%, minimum effect 0.5 percentage points absolute, two-sided α = 0.05, power 80%.
• Requires about 47,500 customers per arm (95,000 total).
• Traffic is about 40,000 basket viewers per week, of whom about 20,000 are new. Unique customers therefore accumulate at roughly 40k in week 1 and 20k per week after that.
• Plan: 4 weeks of enrolment, then a 7-day conversion window, for a fixed end date of [date]. Ines to confirm the unique-customer count, since the 20k-new-per-week figure is an estimate.
• No decisions before the end date, with one exception: at week 2, Ines runs a harm-only check on guardrails. We stop early only if a guardrail shows harm at p < 0.001.

Decision rules

Ship if: - The primary metric is significantly positive (p < 0.05), with an estimated uplift of at least 0.5 percentage points, and - No guardrail is significantly worse.

Don't ship if: - The primary result is not significant, or - It is significant but below 0.5 points (not worth acting on, per Chloe), or - A guardrail is significantly worse.

We don't iterate on a null result by re-slicing the data until something looks significant.

Analysis (Ines)

• Analyse at the customer level, intention-to-treat: all assigned customers, regardless of whether they saw the fee line.
• Report absolute difference in percentage points and relative difference, each with a 95% confidence interval.
• Report all guardrails.
• Pre-registered segment: new vs returning customers. Returning customers may already know the fee, so the effect may differ. Treat any other segment cuts as exploratory.

Timeline and sign-off

• Build complete: [date]
• Launch: [date]
• Fixed end: [date]
• Readout: [date + 3 working days]

Approved by: _____ Chloe, Head of Growth Date: ___

To: Chloe (Head of Growth), Ravi (Growth Engineer), Ines (Data Analyst) From: PM, Checkout Subject: Experiment Spec: Early Delivery Fee Display in Basket

Team, here is the polished spec for our upcoming checkout experiment. I’ve incorporated Chloe’s threshold, fixed a few methodological traps in the draft, and scoped this for a clean, reliable read.

---

1. Objective & Hypothesis

• Current State: Delivery fee (£3.99, free over £60) is only revealed on the final checkout step. 12% of last quarter’s support contacts were fee-related surprises.
• Hypothesis: Showing the delivery fee (and progress to free delivery) directly in the basket increases customer trust and sets clear expectations upfront.
• Expected Impact: While Chloe rightly worries this might cause some upfront drop-off among sub-£60 baskets, we believe the resulting higher-intent checkout starts will lift overall conversion and reduce cart abandonment due to "sticker shock."

---

2. Variant Definition

• Control (A): Existing basket experience. Delivery fee hidden until final checkout step.
• Variant (B):
• Displays the delivery fee clearly in the basket summary.
• Note on scope: Per Chloe’s suggestion, we are bundling the "free delivery over £60" progress banner into Variant B. Since the fee and the threshold are conceptually tied, showing one without the context of the other would skew the test.

---

3. Traffic Allocation & Unit of Randomization

• Unit of Randomization: User-level (logged-in state or persistent cookie). Correction from draft: Session-level splitting would cause a jarring experience if a user refreshes or returns and sees fluctuating fee visibility.
• Split: 50/50 (Control / Variant).
• Audience: All customers viewing the basket (~40,000 unique users/week, split roughly 50/50 between new and returning).

---

4. Metrics

• Primary Metric (Guardrail for Business Value):
• Order Conversion Rate: Completed Orders ÷ Total Basket Views.
• (Correction from draft: The draft proposed "Checkout Completion Rate (Orders ÷ Checkout Starts)." That misses top-of-funnel drop-off. If Variant B scares people away before checkout, measuring only checkout-starts will falsely make the variant look better. We must measure from the basket view).
• Secondary Metrics:
• Checkout Start Rate: Checkout Starts ÷ Basket Views.
• Checkout Completion Rate: Orders ÷ Checkout Starts (to isolate downstream behavior).
• Average Order Value (AOV): To monitor if the £60 threshold banner successfully drives basket-building behavior (baseline: £47).
• Support Metric:
• Volume of delivery-fee-related support tickets (Ines, let’s pull this baseline post-launch).

---

5. Success Criteria & Statistical Guardrails

• Minimum Detectable Effect (MDE): Per Chloe, we care about a ≥ +0.5 percentage point absolute change in the Primary Metric (Order Conversion Rate from basket view, baseline ~8%).
• Duration & Peeking:
• Correction from draft: Do not stop the test the moment p < 0.05. Early peeking yields false positives.
• We will run the test for a fixed duration of 2 full weeks to capture day-of-week and new vs. returning user cycles (~80,000 total unique users), yielding adequate statistical power for our MDE.

---

Next Steps:

• Ravi: Let’s sync on tracking implementation for the basket-level fee and banner. Target build completion: [Insert Date].
• Ines: Please set up the tracking dashboard, ensuring we segment by New vs. Returning users and Basket Value (<£60 vs. >£60).
• Chloe: Good to approve?

Experiment: show delivery fees in the basket

Owner/build: Ravi · Analysis: Ines · Approval: Chloe Decision: Should Basketful show delivery charges before checkout?

Hypothesis and scope

Showing the fee in the basket will reduce fee surprises, but could discourage ordering. Unexpected delivery fees accounted for 12% of support contacts last quarter; this is motivation, not a baseline customer complaint rate.

Test fee visibility only. Do not add the proposed free-delivery promotional banner: it introduces a second change and would prevent us attributing results to earlier disclosure.

Experience

• Control: Current experience; delivery fee first appears at the final checkout step.
• Treatment: Show a clearly labelled delivery line beside the basket total: £3.99 delivery, or Free delivery when eligible. Update the fee and total as the basket changes.
• Use the existing pricing service and eligibility rules. Confirm behaviour at exactly £60 before launch; “over £60” must not silently become “£60 or more.”
• Leave checkout, pricing and other messaging unchanged.

Eligibility and assignment

Include customers viewing a non-empty, orderable basket. Exclude staff, bots and test accounts using rules fixed before launch.

Randomise 50/50 by customer, not session, at their first eligible basket view. Persist assignment across visits and devices where identity is available. For signed-out customers, use a stable first-party identifier; Ravi must document identity merging and cross-device limitations before launch.

Analyse everyone assigned, whether or not they start checkout or successfully see the fee: intention to treat.

Metrics

Primary: Customer order conversion — percentage of assigned customers placing at least one order within seven days of assignment. Report treatment minus control in percentage points, with a two-sided 95% confidence interval.

Checkout completion is diagnostic only: treatment may change who starts checkout, so orders ÷ checkout starts could improve while overall ordering falls.

Secondary/diagnostic: - Checkout-start rate and checkout completion. - Delivery-fee-related support contacts per assigned customer within seven days, using consistent tagging. - Orders and revenue per assigned customer; average order value and free-delivery eligibility as diagnostics.

Guardrails: Contribution margin per assigned customer, if reliably available; otherwise net revenue per assigned customer as an explicitly limited proxy. Also monitor basket/checkout errors. Chloe and Ines must approve numerical economic and reliability tolerances before launch.

Sample size and schedule

Chloe’s smallest worthwhile order-conversion change is 0.5 percentage points: 8.0% to 8.5%, not a 0.5% relative lift.

At 5% two-sided significance and 80% power, detecting that increase requires approximately 48,000 customers per arm, or 96,000 total.

Ines must first verify that the 8% baseline matches the eligibility rules and seven-day outcome window; recalculate and freeze the sample target if necessary.

Do not count returning customers again. Expected recruitment is approximately:

• Week 1: 40,000 unique customers.
• Each subsequent week: 20,000 additional customers.
• Four weeks: approximately 100,000 unique customers.

Enroll for at least four complete weeks and until the frozen sample target is reached, ending at a full-week boundary. Then wait seven days for the final cohort’s outcomes: roughly five weeks to readout.

Monitoring and decision

Ravi validates assignment persistence, fee accuracy, exposure/order linkage and sample-ratio balance before ramp-up.

Daily checks are for instrumentation and predefined safety breaches—not efficacy stopping. No “stop when significant,” sample extensions based on results, or repeated significance decisions.

Ines delivers one final primary analysis. Chloe’s default rollout rule is: - Estimated conversion gain at least +0.5 points; - 95% confidence interval excludes zero; - Guardrails pass.

Otherwise, do not roll out on this result alone. A non-significant result does not prove no harm. Secondary trust improvements inform follow-up, not a post-hoc replacement for the primary success rule.