Dataford
Popular roles
Software EngineerData AnalystData ScientistData EngineerBusiness AnalystAI EngineerMachine Learning EngineerProduct Manager
Browse
Browse All RolesEvery role hub, from analyst to MLBrowse All CompaniesCompany-specific interview loopsAll Interview GuidesThe full guide library
Top questions by role
Software EngineerData AnalystData ScientistData EngineerBusiness AnalystAI EngineerMachine Learning EngineerProduct Manager
Top questions by skill
SQLPythonStatisticsMachine LearningA/B TestingSystem DesignGenerative AIProduct SenseMetricsBehavioral
Browse all questions →Try a mock interview
ExperiencesCoaching
New
Practice
Mock InterviewsTimed interview simulations with feedbackSuccess PathYour 6-week structured planModulesCurated lessons by topicWebinarsTalks from ex-Big Tech data leadsPlaygroundA free-form scratch editor
Learn
BlogInterview strategy and career adviceTech Job Market ReportHiring trends across data and AI rolesFor UniversitiesDataford for career centersAbout DatafordWho we are and how we build
Pricing
Get started

Plan Sample Size for Checkout Test

MediumA/B Testing & Experimentation00:00
Practice interviewer
In session
5 left
00:00

Your question is Plan Sample Size for Checkout Test. Take a moment with it on the right.

Talk me through your thinking if you like. When you're confident, submit your answer and I'll grade it like a real screen (7/10 or better passes).

You need to log in / sign up to chat or submit.

Problem

Context

ShopNow, a mid-sized e-commerce app, wants to test a simplified mobile checkout flow that removes one confirmation step. The product manager believes this will increase completed purchases, but engineering wants a clear answer within a fixed launch window.

Hypothesis Seed

The proposed change reduces friction in checkout, so the team expects a modest lift in purchase conversion among users who start checkout. Because the change touches payment UX, the team is also concerned about accidental purchases, payment failures, and support contacts.

Constraints

  • Eligible traffic: 120,000 mobile users per day who start checkout
  • Randomization can only be done at the user_id level
  • Maximum experiment duration: 14 days, including ramp
  • Planned allocation after ramp: 50/50
  • Baseline checkout completion rate: 24%
  • Business wants to detect at least a 5% relative lift in checkout completion
  • False positives are costly because a bad checkout experience can harm trust and payment success; false negatives are acceptable if the effect is too small to matter operationally
  • You may assume a two-sided test with  = 0.05 and power = 80%

Deliverables

  1. State the null and alternative hypotheses, define the primary metric, and propose 2-4 guardrail metrics.
  2. Calculate the required sample size per arm using the stated baseline and MDE, and determine whether the test can be completed within 14 days.
  3. Choose the experiment design: unit of randomization, allocation/ramp, duration, and any stratification or blocking.
  4. Pre-register an analysis plan covering the statistical test, peeking policy, multiple comparisons treatment, and how you would check for sample ratio mismatch.
  5. Explain the ship / don't-ship rule, including what happens if the primary metric is significant but a guardrail worsens or the observed lift is below the planned MDE.