Form Abandonment: How to Find the Field Where People Give Up

What form abandonment means

A visitor abandons a form when they start it and leave without submitting. That definition has two parts, and both matter. “Started” means they did something with the form: clicked into a field, typed, picked an option. Visitors who see the form and never touch it are a different problem (the offer, the page or the placement), and the fixes are different too. “Left without submitting” includes people who closed the tab, went back, got stuck on an error, or simply decided it wasn’t worth it.

Separating those two groups is the first step. If most people never touch the form, rewording a field label won’t help; you need to look at the page around it. If many people start and few finish, the problem is inside the form, and field-level data will show you where.

The funnel: view, start, field, submit

Think of every form as a short funnel with four layers. Each one answers a different question.

Google’s web.dev guides on sign-up forms and on payment and address forms make the same point: page analytics alone aren’t enough. They recommend interaction analytics, such as funnels and events, to show where users abandon the flow, alongside real-user performance data to catch forms that are slow or visually unstable. A field-level report is the most direct form of that interaction data.

How field-level tracking works

Field-level analytics listen to browser events on each input. The two that matter most are focus (the visitor clicks or tabs into a field) and blur (they leave it). From those, a tool can work out three useful numbers per field.

1. Focused: how many sessions clicked or tapped into the field. This tells you how many people got that far.
2. Completed: how many of those sessions had a value in the field when they left it. The completion rate is completed divided by focused, and the drop-off rate is what’s left.
3. Average input time: the average time between focusing the field and leaving it. Long times point to fields that make people think, look something up, or struggle with the format.

How to read a drop-off report

A drop-off report lists your fields in order with those numbers next to each. Here’s a step-by-step way to read one so you end up with one clear candidate to fix.

1. Compare views with sessions that reached the form. If very few viewers ever focus a field, stop here: the problem is above the form. Look at the page, the headline and what you promise in exchange for the details.
2. Follow the “Focused” column down the form. The number should shrink gradually. A sharp fall between two fields tells you people stopped before reaching the second one, so the field above it (or something between them, like a long block of text) deserves a look.
3. Find fields with a high drop-off rate. These are fields people entered and left empty. A high rate on a required field is serious, because the form can’t be submitted without it. A high rate on an optional field may be fine; people skip it on purpose.
4. Check the average input time. A field that takes far longer than its neighbors is costing effort. That’s normal for a free-text message box and suspicious for a phone number or postcode.
5. Compare field completion with submissions. If most fields are completed but submissions are much lower, look at what happens on submit: error messages, a reCAPTCHA challenge, or a confirmation step people don’t finish.
6. Pick one field. Choose the field where the drop is largest among people who reached it. That’s your first fix.

Common patterns and what they usually mean

What to change first: a priority order

Once you know the field, fix it in the cheapest way that could work. This order runs from the smallest, safest edits to bigger structural changes.

1. Remove or make fields optional

Every field is a question someone has to decide to answer. web.dev’s sign-up guidance is blunt: “On sign-up, ask for as little as possible.” For checkouts, Baymard Institute’s benchmark research found the average checkout had 11.3 form fields in 2024, while most sites need only 8 in total. Contact and lead forms tend to accumulate fields the same way, one “nice to have” at a time. For each field, ask whether you use the answer before the first reply. If not, remove it or ask later.

2. Fix labels and hints

Many drop-offs are simple confusion. web.dev recommends one label per input, connected to the field, and warns against using placeholder text as the only label because it disappears once the visitor starts typing. Say exactly what you want (“Work email” rather than “Email” if you need a business address) and add a short hint for anything with a format.

3. Use the right input types and autocomplete

The right input type gives mobile visitors the right keyboard and basic built-in validation, and autocomplete attributes let browsers fill names, emails, phone numbers and addresses in one tap. web.dev also suggests a single name field instead of separate first and last name fields unless you have a clear reason to split them. These changes don’t remove any questions; they make each question faster to answer.

4. Validate as people go, not after submit

Finding five errors after pressing submit is one of the most discouraging moments in any form. web.dev recommends validating inline as data is entered (and again on submission). Accessibility rules point the same way: WCAG’s Error Identification criterion (Level A) requires that when an error is detected, the field in error is identified and the error is described to the user in text. A red border on its own isn’t enough. Tell people what’s wrong and how to fix it, next to the field.

5. Reorder from easy to hard

Start with easy, low-commitment fields (name, email) and put effortful ones (a detailed message, budget) near the end. By the time visitors reach the hard question, they’ve already invested in the form. If your report shows the focus count dropping sharply right after a big free-text box near the top, this is the likely fix.

6. Split long forms into steps

For forms that genuinely need many fields, such as quote requests or applications, splitting them into short steps with a progress indicator can make them feel manageable. Only do this after trimming: a long form split into steps is still a long form. Also check that each step works well on mobile.

7. Help people who get interrupted

Some abandonment isn’t a decision at all: a phone call, a closed laptop, a tab lost among twenty others. Two small aids help. A warning before leaving a partly filled form catches accidental closes, and saving entries in the browser lets people pick up where they left off. Use the warning sparingly; it should protect work in progress, not trap people who have decided to leave.

What to ask on different kinds of forms

The right number of fields depends on what the form is for. A useful test is to ask what you need in order to send a good first reply, and to leave everything else for later in the conversation.

web.dev’s sign-up guidance adds a related point: don’t insist on a username unless or until you actually need one. The same logic applies to every field in the “later” column. You can collect it in your reply, on a follow-up form, or when the customer has a reason to give it.

When the problem isn’t in the form

Sometimes the field-level report looks healthy (people who start the form mostly finish it) but very few people start. Then the cause sits outside the form, and you’ll want to check the page around it.

1. Can people see the form? If the form sits far down a long page, many visitors never reach it. A scroll map shows what share of visitors gets that far.
2. Is it clear what happens next? A short line above the button, such as “We reply within one business day” or “No sales call unless you ask for one,” answers the question people silently ask before giving their details.
3. Is the button specific? “Send my question” or “Get my quote” says more than “Submit.”
4. Does it load quickly and stay put? web.dev recommends checking real-user performance for forms; a form that shifts around as the page loads invites mis-taps.
5. Does it work on a phone? Fill in your own form start to finish on a phone, using autofill, and note every moment of friction. web.dev suggests testing on the platforms most common among your users.

Test your fix instead of assuming it worked

After a change, compare the same report over a similar amount of traffic. Better still, run an A/B test: show the old and new versions of the form to two random halves of visitors at the same time, so seasonality and campaign changes affect both equally. Look at the conversion rate (submissions divided by views), not only the field you changed. Removing a field can raise completion of the next one while lowering overall submissions if the removed question was doing useful qualifying work. And wait for enough data before calling a winner; small samples often show big differences that disappear later.

Ask one more question before celebrating a higher submission rate: are the leads still useful? If you removed a qualifying question, check that the people submitting are still the people you can help. Sometimes the best form is slightly longer, because it filters out inquiries you can’t serve.

A quick form abandonment checklist

1. Every field is used before the first reply, or it has been removed.
2. Required fields are marked, and optional ones are clearly optional.
3. Each field has a visible label; placeholders are only examples.
4. Email, phone and number fields use the matching input type and autocomplete.
5. Errors appear next to the field in plain words as soon as the visitor leaves it.
6. On submit, the page scrolls to the first error.
7. The longest free-text question is at or near the end.
8. The form has been tested on a phone, start to finish.
9. You know your view-to-start rate and your start-to-submit rate.
10. You’ve picked one field to improve and a date to review the result.

Measuring form abandonment in marketingLABO

marketingLABO includes a form builder with drop-off tracking on every plan. Forms you build there get a drop-off report automatically; there’s nothing extra to set up. Here’s what the report contains.

The red highlights are a starting point rather than a verdict. The report suggests adding help text, making the field optional or rewording the question when drop-off is high, which matches the priority order above.

The builder also includes optional input aids you can switch on per form: real-time validation when a field loses focus, highlighting of empty required fields, a warning before leaving a partly filled form, saving entries in the visitor’s browser, scrolling to the first error on submit, a progress bar based on required fields, and a confirmation screen before sending. You can split a form into steps, edit the error messages, and show “Required” or “Optional” badges. While you build, an EFO score checks the number of fields (seven or fewer recommended), the number of required fields (five or fewer), whether free-text questions sit in the second half, and whether a progress bar is on.

To test a fix, start a form A/B test. Your current form becomes variant A and a copy becomes variant B, with traffic split 50:50 by default (you can change the split). The results show views, conversions, conversion rate, average input time and a p-value against variant A; the dashboard reminds you to wait for at least 100 views per variant before deciding. When you’re ready, choose the winner and the test ends. You can also open a heatmap for the page your form is on to see clicks and scroll depth around it.

Forms are included on every plan: one published form on Free, three on Light, and unlimited on Standard. See plans and pricing for details. For the page around your form, our guide to website heatmaps explains how to read click and scroll maps.

FAQ

What’s a normal form abandonment rate?

It varies too much by form type, traffic source and audience for a single benchmark to be useful. A newsletter sign-up and a detailed quote request behave very differently. Track your own form over time and compare it with itself after each change.

Can Google Analytics show which field people abandon?

Not out of the box. Page-level analytics show visits and submissions; field-level detail requires event tracking for each field, or a form tool that records it for you.

Should I remove reCAPTCHA to reduce abandonment?

Not without a plan for spam. If your report shows people completing every field but not submitting, check whether the challenge is the obstacle, then weigh that against the spam it blocks.

Is a multi-step form always better?

No. Steps help long forms feel shorter, but they add clicks and page changes. For a contact form with four or five fields, one short page is usually simpler.

Does a field’s drop-off rate include people who never clicked it?

In a focus-based report like the one described above, no. Drop-off is measured among people who focused the field. Visitors who left before reaching it show up as a lower “Focused” count further down the form, which is why it’s worth reading both columns together: the focus count shows how far people got, and the drop-off rate shows which field they entered and then gave up on.

How long should I wait before judging a change?

Until you have a similar number of views to the period you’re comparing against, and long enough to cover your usual weekly cycle. For an A/B test, wait for enough views on each variant before reading the p-value.

Want to see where people give up on your own forms? Sign up free; the free plan includes one form with drop-off tracking, plus analytics and heatmaps for one site.

Sources

1. web.dev: Sign-up form best practices
2. web.dev: Payment and address form best practices
3. Baymard Institute: average number of checkout form fields (June 26, 2024: average 11.3 checkout fields in 2024; most sites need 8)
4. W3C WAI: Understanding Success Criterion 3.3.1 Error Identification