# How to increase form conversions: measure each field, fix, then test

Page: https://alidemirbas.com.tr/en/blog/how-to-increase-form-conversions

2026-11-14 · A/B Testing · Ali Demirbaş

To increase form conversions, measure which field people leave at with GA4 events, fix the problem in that field and test the change against a control group.

Here's how to increase form conversions: measure which field people leave at after they start your form. Then fix the problem in the field that loses the most people and test the change against a control group. Usability guidelines tell you what can be fixed, and your own field data tells you where to start.

Where leads come from, the offer itself and the landing page as a whole are out of scope here. This post looks only at the form: the fields visitors fill in and the moment they submit.

## Define form conversion with four separate counts

A single conversion rate hides whether people drop before the form or inside it. Keep four counts for the same period and unit, ideally unique users. Count who saw the form, who started it, who submitted it successfully and who started but left without submitting.

The drop between seeing and starting is mostly about the page and the offer. The drop between starting and submitting comes from the form itself, and form analytics guides call its share the form abandonment rate.

Google Analytics 4 (GA4) gives you two of these counts out of the box. According to its [enhanced measurement events](https://support.google.com/analytics/answer/9216061?hl=en) page, form_start fires when a user first interacts with a form in a session. The form_submit event fires when the user submits a form. So form_start counts people who interacted with the form, not people who saw it.

To count viewers, send your own event when the form becomes visible on screen. To use parameters such as form_id and form_name in reports, you also need to register them as custom dimensions.

"Submitted" and "submitted successfully" aren't the same thing. Google Tag Manager's [form submission trigger](https://support.google.com/tagmanager/answer/7679217?hl=en) fires only on a successful send when its Check Validation option is selected. When the option is left unselected, the trigger fires on every attempt to submit.

To keep failed attempts out of your count, tie success to a signal such as the thank-you page or the server's confirmation. Exclude your own test submissions and entries filtered as spam from the count too.

## Measure each field with an event plan

The form parameters listed in GA4's enhanced measurement docs carry the form's ID, its name, its destination URL and the text of the submit button. Nothing in that list says which field a user stopped at. To see field-level drop-off, you need your own [custom events](https://support.google.com/analytics/answer/12229021?hl=en). A starting plan can use five events:

- form_view: when the form becomes visible, with the form ID.
- form_field_leave: when a user leaves a field, with the field name and its state (empty, filled or invalid).
- form_error: when a validation error appears, with the field name and the error type (required field left empty, or wrong format).
- form_success: when the server confirms the submission.
- form_abandon: when a user who started the form leaves the page without a successful submission, with the name of the last field they touched.

Never put what users typed into these events. Send the field name only. Google's [guide to avoiding PII](https://support.google.com/analytics/answer/6366371?hl=en) (personally identifiable information) warns that visitors type personal data into form fields. It asks you to remove that data before it reaches Analytics.

Register the field name parameter as a custom dimension so you can see it in reports. Google treats dimensions with more than 500 possible values as high-cardinality, and the field names of one form stay far below that.

This plan is a method, not a built-in GA4 feature. In particular, the docs don't promise that a form_abandon event will arrive every time a page closes, so treat that as an assumption. Before launch, fill in the form yourself, leave it at different fields and watch the events arrive in [DebugView](https://support.google.com/analytics/answer/7201382?hl=en).

According to Google, DebugView shows the events collected from a user in real time while debug mode is on. If some exits never get recorded, your last-field counts will undercount real drop-off. Check whether the missing events cluster on one device or browser.

Lining fields up as steps in a GA4 funnel looks like the obvious approach, but it can mislead. The [funnel exploration](https://support.google.com/analytics/answer/9327974?hl=en) docs say a user who misses a step falls out of the funnel and isn't counted in later steps. People skip fields and come back, so a field-order funnel can show even users who finished the form as lost. Grouping leavers by the last field they touched avoids that problem.

## Hypothetical example: the phone field holds a third of the drop-off

A hypothetical B2B (business-to-business) site has a demo request form with six fields: full name, work email, phone, company, company size and an optional message. Over 28 days, 12,000 users saw the form and 3,000 started it.

Of those who started, 1,800 submitted successfully in the same session and 1,200 left without submitting. Grouping those 1,200 people by the last field they touched puts the largest share at the phone field, with 400 people:

| Field | Users who interacted | Left at this field | Left / interacted |
| --- | --- | --- | --- |
| Full name | 2,950 | 90 | 3.1% |
| Work email | 2,880 | 210 | 7.3% |
| Phone | 2,620 | 400 | 15.3% |
| Company | 2,200 | 150 | 6.8% |
| Company size | 2,080 | 130 | 6.3% |
| Message (optional) | 1,950 | 80 | 4.1% |
| Submit, failed attempt | 3,000 starters | 140 | not calculated |

The phone field accounts for 33.3% of everyone who left, and it also has the highest drop-off share among users who interacted with it. Both rankings point to the same field, so the first review starts there.

The rows aren't consecutive funnel steps. Each row's denominator is the users who interacted with that field, and people can skip fields and return. The 140 people in the Submit row pressed the button, got an error and left without a successful submission.

The 400 people who left at the phone field show how many people the problem touches. They aren't the gain from fixing it. A fix might bring some of them back, but some would have left anyway for other reasons. Only a test can measure the gain.

The type of problem decides the first test. Of the 2,620 users who interacted with the phone field, 520 (19.8%) saw at least one error message. Splitting the people who left by whether they saw an error first can change which fix to try first:

| Scenario | Saw an error, then left | Left without an error | First test |
| --- | --- | --- | --- |
| A | 260 (65.0%) | 140 (35.0%) | Relax the validation |
| B | 140 (35.0%) | 260 (65.0%) | Make the field optional |

In both scenarios 400 people left and 520 saw an error, and only the share of leavers who saw an error changes. In scenario A, most of the drop-off comes with a format error: the field may reject spaces, a country code or brackets. In scenario B, people leave without seeing an error, so they may not have wanted to give a phone number. That makes an optional field, or a short note on why you ask, the first candidate.

Field data shows where people left, not why. Reading scenario B as "didn't want to share a number" is an inference. To check it, watch a few session recordings that end at that field. You can also ask a handful of people to fill in the form and say where they hesitate.

Because form_start is counted per session, someone who leaves today and submits tomorrow shows up as a leaver in today's data. Drop-off measured within one session can make the real loss look larger than it is.

All figures in the tables are hypothetical. Counts of people are exact, and shares are rounded to one decimal place.

## Field count and order set the effort

Unnecessary fields are one of the first warnings in the World Wide Web Consortium (W3C) forms tutorial. The [forms tutorial](https://www.w3.org/WAI/tutorials/forms/) from the W3C Web Accessibility Initiative (WAI) says users usually prefer short, uncomplicated forms. It adds that users are more likely to abandon a form that asks for irrelevant or excessive data.

For each field, ask whether you need that information for the first assessment. For a plan that also counts what a removed field costs the sales team, see the [fewer fields test](https://alidemirbas.com.tr/en/lab/ab-test-library/tests/fewer-fields-on-a-demo-request-form-ab-test-example).

The layout of the remaining fields matters too. NN/g's 2016 [form design guidelines](https://www.nngroup.com/articles/web-form-design/) recommend a single column, because multiple columns interrupt the vertical momentum of moving down the form. The same guidelines allow short or logically related fields, such as city, state and postal code, to share a row. You can check this choice on your own form with the [one-column vs two-column test](https://alidemirbas.com.tr/en/lab/ab-test-library/tests/one-column-vs-two-column-form-layout-ab-test).

NN/g also recommends standard field sequences, such as card number, expiration date and security code. For choices within a field, it suggests listing the most common values first. Opening with the least demanding field is a separate question, since moving a hard field to the end may only shift where people leave. That's why the [easiest field first test](https://alidemirbas.com.tr/en/lab/ab-test-library/tests/easiest-field-first-form-field-order-ab-test) judges the result by submissions rather than form starts.

## Labels, helper text and required-field markers

A label is the persistent text that says what a field asks for. W3C's [labeling guide](https://www.w3.org/WAI/tutorials/forms/labels/) says most users prefer or even need visible labels to understand the form. The same page says labels above fields reduce horizontal scrolling for people with low vision and mobile users.

W3C adds that this benefit depends on nearby fields and content and needs to be assessed form by form. The [label position test](https://alidemirbas.com.tr/en/lab/ab-test-library/tests/above-vs-left-aligned-form-label-ab-test-example) gives you a ready plan for comparing labels above and to the left of fields.

Placeholder text inside a field doesn't replace a label. W3C's [form instructions page](https://www.w3.org/WAI/tutorials/forms/instructions/) says so directly. NN/g's 2014 [placeholder article](https://www.nngroup.com/articles/form-design-placeholders/) explains that text which disappears once people start typing makes it hard to remember what belongs in the field.

If a field has a format rule (MM/DD/YYYY, say), keep it visible in the label or below the field. The [helper text test](https://alidemirbas.com.tr/en/lab/ab-test-library/tests/testing-short-helper-text-under-each-form-field) measures whether a short note under each field lowers errors.

Mark every required field. NN/g's 2019 [article on required fields](https://www.nngroup.com/articles/required-fields/) notes that users don't read instructions at the top of a form, such as "all fields are required". It recommends marking each required field instead. Labeling optional fields as "optional" isn't mandatory, but the same article says it lightens the user's cognitive load.

NN/g's form guidelines also suggest limiting a form to one or two optional fields. You can measure the effect of clear markers with the [required and optional fields test](https://alidemirbas.com.tr/en/lab/ab-test-library/tests/labeling-required-and-optional-form-fields-test).

## Error messages and when to validate

An error message should name the field in error and say how to fix it. The Web Content Accessibility Guidelines (WCAG) version 2.2 cover both. Under [3.3.1 Error Identification](https://www.w3.org/WAI/WCAG22/Understanding/error-identification.html), an automatically detected input error is identified and described to the user in text.

[3.3.3 Error Suggestion](https://www.w3.org/WAI/WCAG22/Understanding/error-suggestion.html) asks for a correction suggestion when one is known. The exception is a suggestion that would put security or the content's purpose at risk. In W3C's example, "Email is not valid" meets 3.3.1. A message that also gives the expected format, such as "Enter your email as name@example.com", meets both.

Timing matters as well. NN/g's 2019 [guidelines on form errors](https://www.nngroup.com/articles/errors-forms-design-guidelines/) advise holding an error, in most cases, until the user has finished the field and moved on. Baymard Institute's user testing shows why. In its [inline validation research](https://baymard.com/research-articles/inline-form-validation) (January 9, 2024), premature validation tells users their input is wrong before they've had a chance to type it correctly.

Baymard also notes that inline validation doesn't fully replace error handling on submit, because users may still try to submit with errors present. If errors appear after submission, W3C's [notifications guide](https://www.w3.org/WAI/tutorials/forms/notifications/) suggests moving focus to the first field in error. NN/g's form guidelines add that the user's erroneous input should be preserved, so they only need to fix the mistake.

NN/g treats the same error showing up three or more times in one attempt as a sign of a deeper interface problem. If you count the form_error event by field name, those fields show up in your reports.

Validation rules should be forgiving too. W3C's [validation guide](https://www.w3.org/WAI/tutorials/forms/validation/) points out that phone numbers are written with different separators and digit groupings. A form that can interpret several notations is easier to use. The same guide says client-side validation alone doesn't make data secure, so validate on the server as well.

Scenario A in the example is exactly the kind of case this fix targets.

## Autofill and mobile keyboards

Browser autofill fills in a user's saved name, address or phone number with one tap. It works only if the browser can tell what the field is for. Mozilla's MDN Web Docs (MDN) page on the [autocomplete attribute](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Attributes/autocomplete) says the attribute tells the browser what type of information the field expects. Use the standard values, such as name for a name, email for an email address and tel for a phone number.

MDN warns that autocomplete="off" stops the browser from offering stored data and removes a feature many users depend on. Made-up values have a similar effect, because the browser can't match the field to a known purpose. Valid values also matter for accessibility: MDN says they satisfy WCAG 2.2's [1.3.5 Identify Input Purpose](https://www.w3.org/WAI/WCAG22/Understanding/identify-input-purpose.html). That criterion asks that the purpose of fields collecting information about the user can be determined programmatically.

Browser autofill and the suggestions your own site offers (an address or company lookup, for example) are different things. The first uses data the user saved in the browser. The second uses your suggestion source. To see how a suggestion list affects completion and data accuracy, run the [autocomplete suggestions test](https://alidemirbas.com.tr/en/lab/ab-test-library/tests/autocomplete-suggestions-in-form-fields-ab-test).

To measure browser autofill itself, web.dev's [guide to measuring autofill](https://web.dev/articles/autofill-measure) separates four states for each field: left empty, filled manually, autofilled, and autofilled then changed. You can add that state to the form_field_leave event.

On mobile, the right keyboard cuts typos. In Baymard's 2015 [touch keyboard research](https://baymard.com/research-articles/mobile-touch-keyboards), typos were much more common on sites that used the standard keyboard for numeric inputs. The same research found that auto-correct works poorly for words that aren't in the dictionary, such as names, street names and email addresses.

MDN's page on the [inputmode attribute](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Global_attributes/inputmode) says inputs that need a phone number should typically use type="tel". For touch targets, WCAG 2.2's [2.5.8 Target Size (Minimum)](https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum.html) asks for at least 24 by 24 CSS (Cascading Style Sheets) pixels. Enough spacing around a smaller target is one of its exceptions.

## Multi-step forms, modals and social sign-in

Splitting a long form into steps doesn't change how many fields it asks for. In [checkout research](https://baymard.com/research-articles/checkout-flow-average-form-fields) Baymard published on June 26, 2024, the number of form fields affects overall usability far more than the number of steps. The finding comes from checkout flows, so applying it to demo or signup forms is an inference. Still, it's a reason to look at field count before you debate step count.

If you do split the form, W3C's [multi-page forms guide](https://www.w3.org/WAI/tutorials/forms/multi-page/) suggests saying up front how many steps follow. It also suggests showing progress on each step.

WCAG 2.2's [3.3.7 Redundant Entry](https://www.w3.org/WAI/WCAG22/Understanding/redundant-entry.html) covers information the user already entered in the same process. When that information is needed again, it should be filled in automatically or available to select. The criterion has exceptions and doesn't require storing information between sessions.

Going back to an earlier step helps people correct answers, as long as their entries are kept. The [back button test](https://alidemirbas.com.tr/en/lab/ab-test-library/tests/should-a-multi-step-form-show-a-back-button-ab-test) asks you to confirm that before measuring anything. In your field events, add the step number as a parameter.

Showing the form in a modal or inline, and adding social sign-in to a signup form, change the presentation while the fields stay the same. Measure the modal choice against everyone eligible to see the form, including visitors who never open the modal, not against field data. The [modal vs in-page form test](https://alidemirbas.com.tr/en/lab/ab-test-library/tests/modal-form-vs-in-page-form-ab-test-example) defines that audience.

For social sign-in, track activation and whether people can sign in again later, not only signups. The plan for that sits in the [social sign-in test](https://alidemirbas.com.tr/en/lab/ab-test-library/tests/adding-social-sign-in-to-a-signup-form-ab-test).

## Test the change against a control group

A before-and-after comparison can't separate the effect of your change from seasonality, campaigns or a shift in traffic mix. The [forms data module](https://web.dev/learn/forms/data) on web.dev suggests deploying the fix and measuring its effect after some days. That shows whether the problem is still there, but it doesn't prove a gain. If your ad budget changed in the same weeks, the difference could come from that.

The combined effect of usability guidelines has been measured in a lab. Seckler and colleagues published a [controlled eye tracking experiment](https://research.google.com/pubs/archive/42513.pdf) on this in 2014. Its 65 participants filled in either the original or a guideline-improved version of forms from real company websites.

With the improved forms, 78% of form fillings were submitted on the first try, against 42% with the originals. The difference in submission attempts was significant for all three forms. For the form the researchers had rated as good quality before the changes, the difference in completion time wasn't significant. The result shows what twenty guidelines did together, not what a single change will do on your form.

In your own test, assign users at random to two groups when they first see the form. Compare them by the group they were assigned to, not by whether they saw the change. The control group keeps seeing the current form. Make the primary metric successful submissions per assigned user: in the hypothetical example that's 15.0%, or 1,800 successful submissions from 12,000 users.

Find the number of users you need with the [sample size calculator](https://alidemirbas.com.tr/en/calculators/sample-size-calculator), using that baseline and the smallest effect you want to detect. Run both groups over the same period and in full weeks.

Write the decision rule before the test starts. For example, the variant with relaxed phone validation ships if it beats the control on successful submissions per assigned user. The difference has to be significant once the planned sample is reached.

Set a guardrail metric up front as well. For a variant that makes the phone optional, it could be the share of leads the sales team can reach by phone. If that share falls below the limit you wrote down, stop the test.

If the result is unclear, record it as unclear rather than as no effect, and don't treat the testing tool's "winner" label as your decision. For group sizes and how to check the assignment, see the post on [control groups in A/B testing](https://alidemirbas.com.tr/en/blog/control-group-ab-testing).

## Your form's first four weeks

This order is enough to find the biggest loss inside your form and set up the first test:

1. Count users who saw, started and successfully submitted the form with separate events, and tie success to the server's confirmation.
2. Set up the field events, then fill in the form yourself to check that no field content is sent and the events reach DebugView.
3. Collect four weeks of data, group leavers by their last field and count separately the people who saw an error at the field that loses the most.
4. For that field, write down one change, one primary metric, one guardrail and one decision rule, then test the change against a control group.

When the test ends, rebuild the same field table for both groups. If the winning variant moved the drop-off to another field, your next test starts there.