Form Abandonment: Find the Field That Loses Users

Form abandonment is when someone starts filling in a form and leaves without submitting it. To reduce it, find the field or step where people stop, then watch what happened there: an error they could not resolve, a format the form rejected, a question they did not want to answer.

This post covers how to measure form abandonment, the usual reasons users abandon forms, how session replay shows hesitation and errors even when every value is masked, and a checklist of fixes.

What is form abandonment?

A form is abandoned when a user interacts with it, at least focusing a field, and then does not submit. Visitors who never touch the form are not abandoners; they simply did not start. The distinction matters because the fixes differ: a form nobody starts needs a better reason to begin, while a form people start and leave has a problem inside it.

How do you track form abandonment?

You need two things: a count of how many people start and finish, and the last field each abandoner touched.

• Start and submit events. Send an analytics event on the first focus of any field and another on a successful submit. The gap between them is your abandonment. A tag manager can fire both without code changes to the form.
• Step events for multi-step forms. One event per completed step turns the form into a funnel and shows which step loses people.
• The last interacted field. Record which field had focus most recently when the user left. Across many abandoners, the field that appears most often is where to look first. Some form analytics tools report this directly; with a general analytics tool you can send the field name on blur and read the last one per session.

Send field names, never field values. field: "postcode" tells you where; the postcode itself is personal data you do not need.

Why do users abandon forms?

• Too many fields. Every field is a question, and optional ones look required.
• Unclear errors. "Invalid input" next to a field, or a single message at the top that does not say which field is wrong.
• Errors that clear data. Submitting with one mistake reloads the page and empties the form, including a password the user has to invent again.
• Required fields hidden. A required checkbox below the fold, or a field inside a collapsed section, blocks submission without explanation.
• Strict formats. Phone numbers rejected for spaces or a missing country code, dates that must be typed in one specific order, postcodes checked against the wrong country.
• Password rules revealed late. The requirements appear only after the first attempt fails.
• Autofill breaking. The browser fills the wrong fields, or a custom input ignores autofilled values, so the form looks complete but will not submit.
• Questions people do not want to answer. A phone number for a newsletter, a company size for a free download.

Which form field do users abandon? Watch it in replay

Analytics can name the field. Replay shows what happened at it. The obvious worry is that masking makes forms unwatchable, and it does not.

AnyReplay masks form fields by default: the values are replaced in the browser, before anything is sent, and a masked value replays as asterisks of the same length. You do not see what the user typed, but you still see a lot:

• Focus order. Which fields the user filled, which they skipped and which they came back to.
• Hesitation. A long pause with focus on one field, or focus moving in and out of it several times.
• Corrections. The asterisks growing, shrinking back to nothing and growing again, which is what retyping looks like.
• Validation messages. Error text on the page is recorded like any other text, so you read exactly what the form told the user.
• What happened on submit. Whether the page reloaded, whether the form came back empty, whether the button responded at all.
• Autofill effects. Several fields filling at once, followed by the user correcting one of them.

If the values themselves would help, for example to see which phone format a field rejected, set maskAllInputs: false and AnyReplay records what visitors type. Passwords, one-time codes and payment fields stay masked whatever you configure. Email and telephone fields are ordinary fields, so they are recorded once you opt out; keep them masked with an ar-mask class if you do not want them in the recording. If the page around the form shows personal data, such as a prefilled account name, add the ar-mask class to it. How to mask sensitive data and the masking docs cover the details, and input masking has the short definition.

Tracking form steps with custom events

To find the right sessions quickly, mark the form's milestones with custom events so they appear on the timeline and in the Has event filter.

const form = document.querySelector('#signup');

form.addEventListener('focusin', () => {
  anyreplay('track', 'signup_form_started');
}, { once: true });

form.addEventListener('invalid', (event) => {
  // the field name only, never event.target.value
  anyreplay('track', 'signup_form_invalid', { field: event.target.name });
}, true);

function onSubmitSuccess() {
  anyreplay('track', 'signup_form_submitted');
}

Event properties are stored as sent and are not masked. Put the field name in them, never its value. Then filter to signup_form_started, open sessions without signup_form_submitted in their event list, and jump to the last signup_form_invalid marker. Sessions flagged with Errors are worth watching first, because a script error during submission is a common silent failure.

How do you reduce form abandonment?

Fix what the recordings showed, starting with the field that loses the most people. A checklist to work through:

• Remove every field you do not use. Mark the optional ones that remain as optional.
• Validate on blur, next to the field, with a message that says how to fix it.
• Never clear the form after a failed submit. Keep every value and move focus to the first error.
• Show password requirements before the user types.
• Accept common formats: spaces and dashes in phone numbers, a date picker or clearly labelled day, month and year.
• Use the right autocomplete and inputmode attributes so autofill and mobile keyboards work.
• Keep required controls visible, and say which one is missing when submission is blocked.
• Explain why you ask for anything personal, or stop asking.

After shipping, repeat the same filter on new sessions and check that the pattern has gone, and watch the start-to-submit numbers in your analytics tool for the measured result. If the form is part of a checkout, why users abandon checkout covers the rest of the flow.

Frequently asked questions