Before changing the checkout, make sure the drop is real, find the affected customers and pinpoint where the journey breaks down.
Map the real journey
Split the journey by device, customer type, payment method and acquisition source. One blended funnel can hide the people who are actually having trouble.
Use numbers and customer feedback together
Use behavioural data to find where people stop. Then review sessions, support themes and usability findings to understand why.
Change one thing for a reason
Write down what you expect to improve before the work starts. Check the result alongside error rates, margin and support contacts so a local gain does not hide a new problem.
Rule out a measurement problem first
Confirm that step events fire once, reflect the actual interface state and preserve order and revenue values. Changes in consent, payment redirects or single-page checkout behaviour can create an apparent drop without a customer problem.
Segment where the experience actually differs
Device, market, new or returning customer, payment method and delivery eligibility can reveal different problems. Start with a sensible theory and enough traffic to judge the result. Do not keep slicing the data until a story appears.
Example: a payment-step drop
A mobile payment drop could come from validation errors, missing wallets, slow third-party responses or an event firing too early. Check funnel data against error logs, support messages and session recordings before asking for a design change.
Use the Growth Opportunity Review if you are not yet sure checkout is the right priority. If the problem is already understood, a Focused Build Sprint can take it through implementation, QA and tracking.
Worked example