A contact button click is an intention. An accepted enquiry is a different outcome. If both are reported as leads, a small service business can spend weeks optimising the wrong number.
This is a practical QA checklist for developers implementing an asynchronous enquiry form. It is an implementation approach, not a claim that GA4 will capture every real-world lead.
Give each stage its own meaning
Google's enhanced measurement documentation describes form_start and form_submit. Google also recommends generate_lead for a submitted form or request for information.
For an AJAX form, define your application-level success separately: the backend has accepted the enquiry and returned the response that your application treats as success. The button click alone is not that response.
Write the measurement contract before installing another tag:
| Stage | Meaning in the application | Count as an accepted enquiry? |
|---|---|---|
| Contact link clicked | A visitor opened the contact route | No |
| Form started | A visitor interacted with the form | No |
| Submit attempted | The visitor attempted to send data | No |
| Enquiry accepted | The backend accepted the request | Yes, under this contract |
| Sales-qualified enquiry | The team reviewed the request and found it relevant | Separate business outcome |
This makes a failed validation attempt useful diagnostic data without promoting it to a successful enquiry.
Choose one owner for the success signal
Inventory all the places that can send the success event: the form plugin, a WordPress snippet, a tag-manager trigger and a thank-you-page listener. Two individually sensible implementations can report the same action twice when they are both active.
Pick one success hook for this form and document it. If you use a backend success callback, a generic submit-button listener should not also send the same success event. Do not disable unrelated measurements merely to make the totals match.
A success callback should run only after the response has been validated according to the actual API contract. An HTTP response by itself may not be sufficient if the form provider returns an application-level failure in its response body.
Test the failure paths first
Use a staging environment or clearly labelled test enquiries, with the receiving team's permission. Check these scenarios before trusting the dashboard:
- Press submit with a required field missing. Expect an error and no accepted-enquiry event.
- Simulate an application-level rejection. Expect no accepted-enquiry event, even if the request reached the server.
- Test a slow response. A visitor should not be able to create duplicate requests by repeatedly pressing an enabled button.
- Complete one valid request. Expect one accepted enquiry in the backend and one intended success event in the browser's measurement flow.
- Refresh a thank-you page. Confirm that a refresh does not create another enquiry or a second success event under your chosen design.
- Navigate away and back. Check whether your listeners have accidentally been registered more than once.
Capture the expected and observed results in a short table. A green message on the page proves that the UI displayed a message; verify the receiving system separately.
Keep enquiry details out of analytics
Google's enhanced-measurement guidance requires avoiding collection of personally identifiable information. Keep the form contents in the system intended to process enquiries, not in analytics event parameters.
For this implementation, use a stable form identifier such as contact_main. Do not populate event labels with a visitor's name, email, telephone number or message. Inspect the outgoing payload and page URL as well as the tag configuration: a confirmation URL can accidentally expose values even when the event fields look clean.
Reconcile records without expecting identical totals
After launch, compare accepted enquiries in the backend with the intended analytics event over the same period. They can differ because browser collection is affected by consent choices, blockers, connectivity and navigation timing. A lower analytics count is a reason to investigate, not permission to resend events until the numbers look equal.
Use backend records as the operational record of requests received. Use analytics to examine journeys and acquisition patterns within the limits of the data it actually collected. Keep test enquiries identifiable in the operational record so the sales team does not follow up on them as real prospects.
Before calling the implementation finished
Document the form, success condition, event owner, failed cases tested and where the accepted request can be found. The most useful handover is one another developer can reproduce, including a failure that must not count.
Written by the ONE SOCIAL team, sharing practical notes on marketing websites and measurement. AI-generated article; the checklist is general guidance, not a production test report for a particular website.
