Why Users Abandon Checkout and How Replay Shows It

Users abandon checkout for two kinds of reason: some decide not to buy, often because of a surprise such as a shipping cost, and some want to buy but the checkout gets in their way with errors, long forms or a payment step that fails. Analytics tells you which step loses people. Session replay shows what happened to them on that step.

This post lists the common reasons for checkout abandonment, then walks through a replay workflow for finding the ones that apply to your store and checking that a fix worked.

Why do customers abandon checkout?

Some abandonment is healthy: people compare prices, save a cart for later or check the total before asking someone else. The reasons worth your attention are the ones you can change.

• Unexpected costs revealed late. Shipping, taxes or fees appear only on the last step, and the total is not what the customer had in mind.
• Forced account creation. A sign-up wall before payment turns a purchase into a registration.
• Long or complex forms. Separate billing and shipping forms, fields that are not needed, unclear labels.
• Validation errors. A postcode format rejected, a phone number that needs a country code nobody mentioned, an error that appears only after submitting.
• Payment failures. A declined card with an unhelpful message, a verification step that does not open, a wallet button that does nothing.
• Trust concerns. An unfamiliar payment page, missing return information, a checkout that looks different from the rest of the site.
• Slow steps. A shipping calculation or payment form that takes long enough to look broken.
• Coupon field distraction. For example, a prominent "discount code" box that sends customers off to search for a code they do not have.
• Mobile layout issues. The on-screen keyboard covering the continue button, a wrong keyboard type for a number field, a button pushed below the fold.

Surveys and industry lists tell you which of these are common in general. They cannot tell you which one is happening in your checkout this week. That is the gap replay fills.

What is a good checkout abandonment rate?

There is no single good number. Rates vary widely by industry, price point, device and traffic source, and different tools define abandonment differently: some count from adding to cart, some from reaching the checkout page, some from entering an email. A benchmark measured another way is not comparable to yours. Measure your own baseline with a consistent definition, then work to improve it.

How can session replay reduce cart abandonment?

Replay does not reduce abandonment by itself. It shortens the time between "the payment step loses people" and "the card form rejects valid expiry dates on some browsers", which is the part that usually takes weeks. Here is a workflow with AnyReplay.

1. Mark the checkout steps with custom events

Add a custom event at each step boundary. Names are up to 64 characters of letters, digits and _ . : -, and properties are a small JSON object.

anyreplay('track', 'checkout_started', { items: cart.items.length });
anyreplay('track', 'shipping_submitted', { method: shipping.method });
anyreplay('track', 'payment_submitted', { provider: 'card' });
anyreplay('track', 'order_completed');

Keep properties to counts, methods and your own identifiers. Properties are stored as sent and are not masked, so never put names, addresses, emails or amounts tied to a person in them.

2. Filter to sessions that started checkout

In the session list, set Has event to checkout_started. Every session in the result reached checkout. Open them and check each event list: the ones without order_completed are the abandoned checkouts, and the last event tells you which step they stopped after. If your analytics tool already lists customers who abandoned, and you identify signed-in users, you can also search sessions by email.

3. Watch the stalled step, and start with flagged sessions

Switch the list to Errors or Rage clicks as well, and watch those first. A JavaScript error on the payment step or a burst of clicks on the continue button is the kind of problem that loses buyers who wanted to pay. Then watch ordinary sessions that stopped at the same step. Look for:

• A validation message appearing and the customer retyping the same field.
• Scrolling back up to the order summary, then leaving, which often means the total was a surprise.
• The coupon field getting focus, followed by a switch to another tab and no return.
• A button that did not respond, or responded late. How to fix rage clicks covers the causes.
• On mobile, a layout where the next button is hidden behind the keyboard.

4. Group what you see into patterns

Watch five to ten sessions per step and write down one line each. Patterns show up quickly. One session is an anecdote; the same failure in several is worth fixing. If you watch ten and see nothing in common, the reason may be a decision rather than an interface problem, such as price, and replay will not show you more.

5. Fix, then verify

Ship the fix and repeat the same filter on sessions after the release. The pattern you saw should be gone from new abandoned sessions. For the rate itself, use your analytics funnel: replay shows that the cause is gone, the funnel shows whether completion moved. Session replay vs analytics explains why you need both.

Card fields and masking

Checkout is where sensitive data lives, so check what your recordings contain before you watch them. Card numbers, security codes, expiry dates, cardholder names, IBANs, passwords and one-time codes are masked in the browser whatever you configure. The rest — addresses, names, email and telephone fields — is masked by default too; if you set maskAllInputs: false to see what people typed, mark the fields you still want hidden with ar-mask, and make that choice before you record a checkout. Add ar-mask to the order summary if it shows a customer's name or address, and ar-block to anything that should not appear at all.

Hosted payment fields usually live in the payment provider's iframe, which is a separate document from your page and is generally not recorded. Do not assume: record a test checkout and look at what the replay shows. Masking has a check-it procedure.

Forms are half the problem

Most checkout steps are forms, and many checkout problems are form problems in disguise: a field format, an error that clears input, autofill filling the wrong box. Form abandonment goes field by field.

Frequently asked questions