Confirm form submissions before counting them as leads

Define what a successful submission means

For a local service form, our recommended success definition is: the system accepts the request, stores or reliably routes it, and tells the visitor what happens next. Pressing Send is only an attempt. Write that definition down before asking a developer to install tracking; otherwise they may faithfully measure the wrong action.

GA4 enhanced measurement includes form_start and form_submit events. These are useful interaction signals, but your business should separately verify that its particular form workflow delivers a usable enquiry. A measurement label does not establish that a member of staff received the details.

Run a four-path test

First, send a valid test with an obvious marker such as TEST-October-08. Confirm the success message, the saved record, and the message reaching the intended staff member. Second, leave a required field empty. You should see an understandable correction prompt rather than a success message. Third, enter a malformed email address and inspect the result. Fourth, refresh the success page and check whether your measurement fires again.

Test the real form on a phone as well as a computer. Where a booking widget or form provider sits on another domain, include that handoff. A polished page can still lose information at a provider boundary. Write observed results beside each test instead of recording only “form tested.”

Inspect measurement without sending customer details

Google’s DebugView is designed to inspect collected events during testing. Have the implementer show which event fires after acceptance and which parameters accompany it. Compare the test timestamp with your submission record; the event name alone is not proof.

A practical event specification might read: “accepted_quote_request fires once after the quote form receives a successful server response; include a non-personal form identifier, exclude message text and contact details.” The exact technical implementation depends on the site. Your specification should also explain what happens on validation failure, a double click, and a direct visit to a thank-you URL.

Diagnose the missing step

If the visitor sees success but there is no saved request, investigate the submission handler. If the request is saved but the notification is missing, inspect routing and delivery. If staff receive it but analytics shows nothing, investigate measurement without assuming the enquiry was lost. These are different repairs.

For example, a landscaping form may accept five test requests but send notifications to an unattended former employee’s mailbox. Tracking changes would not fix that problem. Assign a current notification owner and an alternate, then retest. Keep test records identifiable and exclude them from your monthly business count. Repeat this check after form, email, plugin, or hosting changes.

Write a compact acceptance record: test device, form name, test marker, result shown to the visitor, record location, notification recipient, and event observed. Give unresolved failures an owner. This makes the next retest repeatable and provides a useful handoff when the person maintaining the website changes.