How to design a lead generation form

Completion rate = successful completions ÷ form starts × 100. The numerator is completions, not starts. Count the same form, date window and unit, such as unique form attempts. Match each completion to a start and remove duplicate events.

The 40 incomplete attempts are not automatically 40 frustrated visitors. Some may return later, encounter a tracking gap or decide the service is not a fit. Use a defined follow-up window before calling an attempt abandoned.

With zero starts, the completion rate is not defined, not 0%. More completions than starts usually calls for a tracking, deduplication or cohort check. Do not hide that problem by capping the result at 100%.

There is no universal ideal field count. A quote for a roof repair needs different information from an ecommerce support request. Keep information needed for the next step; test whether later questions can wait.

• Ask for a contact method you will use.
• Use one short question that lets the buyer explain the request.
• Add a qualifier when it changes whether or how you can help.
• Mark optional fields as optional, and explain any unusual request.

A phone number is useful when the buyer is asking for a call. If the next step is an email reply, consider making it optional. Test the change against useful inquiries and paid work, not form count alone. A shorter form can bring more requests that the business cannot serve.

Keep visible, programmatically associated labels. Placeholder text should not be the only label: it disappears while the person types. See W3C's form-label guidance.

Use a clear reading order and enough space to tap each control. A single column is a useful starting point on narrow screens. Test the actual form with its keyboard open, long answers, autofill and zoom.

• Use suitable input types and autocomplete values for names, email and phone.
• Keep labels and help text close to their fields.
• Place the action after the fields. A fixed action must not cover content or keyboard controls.
• Check that visitors can reach errors, privacy choices and the action without sideways scrolling.

Compare results by device and traffic source before blaming the layout. A mobile conversion gap can also come from different intent, slower delivery, broken tracking or an unsuitable offer.

Tell the person which field needs attention and how to fix it. Keep the information already entered. Do not make someone retype the whole form because one answer failed validation.

Validation timing depends on the field. Showing “invalid email” while someone has typed only the first two letters can interrupt them. Check on a suitable pause, after leaving a field or on submission. Always perform server-side validation as well.

Use an error summary linked to affected fields when several answers need correction. Make dynamic feedback available to assistive technology. W3C describes error and success notifications, including why the timing and wording matter.

Use an accurate action such as “Request a quote” or “Send your request.” “Book a call” should book a call, not silently enter someone into a sales sequence. No button phrase guarantees a higher completion rate.

After submission, confirm what the system actually knows. A stored request, delivered email, booked appointment and paid order are different states. If email delivery happens later, a success screen cannot by itself prove the inbox received it.

Give the buyer the real next step, contact method and response expectation the team can meet. Keep an optional resource or booking link secondary. Do not require more information merely to reveal whether the first request succeeded.

When form interactions are enabled, GA4 enhanced measurement can collect form_start and form_submit. Google's definition of submission is an interaction, not proof that your server accepted and stored the request. Check both events on the actual form. See enhanced measurement events.

For a lead accepted by the business system, use a separately verified success event. Google's recommended generate_lead event can describe a request for information. Configure it for the intended success condition and verify that it is received; a tag in source code is not reporting proof. See Google's recommended events.

Choose one owner for each event so built-in and custom tracking do not count the same action twice. Keep tests, spam and retries identifiable. Do not send names, email addresses or free-text answers in analytics event parameters.

For the formula above, use matched attempts or another consistently defined cohort. Dividing raw event counts can be misleading when a visitor submits more than once. Track delivery, human response, qualification and sales separately from form completion.

1. List every field and why it is needed at this stage.
2. Try a valid request, an invalid answer, a duplicate click and a server failure in an authorized test environment.
3. Check phone, desktop, keyboard-only use, zoom and assistive feedback.
4. Match the stored test request to the intended business destination. A thank-you page is only one checkpoint.
5. Verify the event names and counts in the reporting tool. Exclude labeled tests from commercial totals.
6. Compare a proposed change with the current version using completion, inquiry quality and downstream outcomes.

If people start but do not finish, inspect fields, errors and submission behavior first. If they rarely start, inspect the offer and the path to the form. Neither pattern proves a single cause.