Experiment specification

Experiment Spec: Upfront Delivery Fee in Basket

To: Ravi (Eng), Ines (Analytics), Chloe (Head of Growth) From: Checkout PM Subject: Experiment Spec – Showing Delivery Fee in Basket

1. Background & Hypothesis

Last quarter, 12% of support contacts were complaints about unexpected delivery fees. Currently, our £3.99 fee (free on orders >£60) is hidden until the final checkout step.

• Hypothesis: Showing the delivery fee in the basket will build trust and reduce support contacts without hurting overall conversion, rather than scaring users away early.

2. Scope & Variants (Fixing the Draft)

Chloe suggested adding a "Free delivery over £60" banner to the variant. Recommendation: Hold this for a follow-up test. If we test the fee and the promotional banner together, we won’t know if a change in conversion came from fee transparency (friction) or the £60 threshold incentive (upsell). However, because our delivery fee is dynamic, the variant line item must accurately reflect the £60 rule so users aren't misled.

• Control: Current basket experience (no delivery fee shown until final checkout step).
• Variant: Add a single, standard-text line item to the basket summary:
• If basket < £60: “Estimated Delivery: £3.99 (Free over £60)”
• If basket ≥ £60: “Estimated Delivery: FREE”
• (Note for Chloe: If we want to test a high-visibility promotional banner/progress bar to drive AOV, let's fast-follow with that as V2).

3. Metrics (Fixing the Draft)

The draft plan used Checkout Completion Rate (Orders ÷ Checkout Starts) as the primary metric. We must change this. Moving the fee to the basket will likely cause sticker-shock drop-offs to happen in the basket rather than at the end of checkout. This will shrink the number of "Checkout Starts" and artificially inflate Checkout Completion Rate, even if total orders drop.

Because the intervention happens in the basket, our denominator must be basket viewers:

• Primary Metric: Basket-to-Order Conversion Rate (Unique customers placing an order ÷ Unique customers viewing the basket). Baseline: 8.0%.
• Secondary Metrics:
• Average Order Value (AOV): To see if the subtle text nudges baskets over £60. Baseline: £47.
• Basket-to-Checkout Start Rate & Checkout Completion Rate: To observe the shift in where drop-off occurs.
• Support Contacts (Delivery Fee): Tracked via contact form tags/UTMs where possible.
• Guardrail Metric: Net Revenue per Basket Viewer (ensuring total revenue doesn't drop even if conversion holds).

4. Randomization & Targeting (Fixing the Draft)

The draft plan splits traffic 50/50 by session. We must change this to a 50/50 split by Customer/User ID (or persistent device cookie for logged-out users). Groceries are a high-consideration purchase; 50% of our weekly traffic consists of returning users. Splitting by session means a single customer could see the fee in the morning, and not see it in the evening, causing confusion and polluting our data.

• Trigger: User lands on `/basket`.

5. Sample Size & Duration (Fixing the Draft)

The draft plan suggests checking daily and stopping when significant. We cannot do this ("peeking" skyrockets false-positive rates). We need a fixed horizon.

• Minimum Detectable Effect (MDE): Chloe set our threshold at 0.5 percentage points (an absolute shift from 8.0% to 8.5% or 7.5%).
• Sample Size Needed: At an 8% baseline, 80% power, and 95% significance (two-tailed), detecting a 0.5pp change requires ~46,200 unique users per variant (~92,400 total).
• Duration: 4 Weeks (Fixed).
• Traffic math: We get 40,000 unique basket viewers in Week 1, and ~20,000 net-new viewers each subsequent week (since 50% are repeat visitors). We will hit ~100,000 unique users across the test at the end of Week 4. Running in full weekly increments also accounts for weekend vs. weekday shopping cycles.

6. Decision Criteria

After 4 weeks, Ines will run the readout (segmented by New vs. Returning users): * Ship Variant: If Basket-to-Order CR is flat (within ±0.5pp) or significantly positive, AND AOV/Revenue guardrails do not significantly decline. * Rollback: If Basket-to-Order CR drops by ≥ 0.5pp.

Sign-offs Needed: * Chloe: Approve scope (holding the promo banner for V2) and 4-week runtime. * Ines: Confirm sample size math and user-level tracking. * Ravi: Confirm engineering effort for user-level bucketing on `/basket`.

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.

Basket delivery-fee experiment

For: Ravi (build), Ines (analysis), Chloe (approval) Decision requested: Approve a test of showing the existing delivery fee in the basket.

Hypothesis and scope

Showing the delivery cost before checkout will reduce surprise and fee-related support contacts, without materially reducing orders.

• Control: Current experience; delivery fee first appears on the final checkout step.
• Variant: Show the applicable fee in the basket: “Delivery £3.99” below the free-delivery threshold, or “Free delivery” when the basket qualifies. Keep the existing “free on orders over £60” rule and wording.
• Change nothing else. Do not add the free-delivery banner: that would test a second intervention and make the result hard to interpret.

Build and assignment — Ravi

Randomise 50/50 by customer, not session, and keep each customer in the same arm across visits and devices where identity is available. Stratify assignment by new versus returning basket viewers. Exclude staff and test accounts. Log assignment, basket value/fee shown, basket views, checkout starts, orders, order value, and relevant support contacts.

Measurement — Ines

Primary metric: Basket-viewer conversion: percentage of assigned customers who place at least one order within 7 days of their first eligible basket view. Count each customer once, in their assigned arm (intention-to-treat). This captures any deterrence before checkout; checkout completion alone would miss it.

Guardrails / secondary measures: Checkout starts per basket viewer; checkout completion (orders ÷ checkout starts); average order value and revenue per assigned customer; delivery-fee-related support contacts per assigned customer. Support contacts may be too sparse for a definitive test, so treat them as directional, not a substitute for the primary outcome.

Sample, duration, and analysis

Baseline basket-viewer conversion is 8%. Power the test to detect a 0.5 percentage-point absolute difference (Chloe’s smallest worthwhile order effect), with 80% power and a two-sided 5% significance level. This requires approximately 95,000 unique customers total (about 47,500 per arm), assuming independent customer-level outcomes.

There are about 40,000 basket viewers weekly, but many return across weeks. Run for at least four full weeks and until the sample target is reached; then allow 7 days for outcomes to mature before reading results. If the target is not reached, extend in full weeks. Ines should confirm the final sample-size calculation and report actual enrolment.

Do not stop early for significance or check daily results to make a stopping decision. Monitor only for implementation or customer-harm issues. Analyse the primary metric at the customer level, with a 95% confidence interval and the pre-specified two-sided test.

Decision

Recommend rollout if the variant improves basket-viewer conversion by at least 0.5 percentage points, the result is statistically significant, and guardrails show no material harm. Do not roll out if there is significant harm. If results are inconclusive, report that clearly; do not interpret “not significant” as proof of no effect.