Your Google Ads dashboard says “conversion.” Your inbox says nothing. Before changing campaign targeting, check whether the website is reporting a successful enquiry or just a click on Submit.
Created with AI assistance for deDevze. The test scenarios below are illustrative.
Write the event contract before adding the tag
For a lead-generation form, define success in application terms:
The server accepted a valid enquiry and returned the response the application treats as successful.
That is different from a button click, the start of a network request, or a component rendering. It also does not prove a salesperson received the message. Delivery needs its own check.
Write a small event contract with four fields: event name, trigger condition, permitted parameters and duplicate-handling rule. For example:
- Event: an enquiry was accepted.
- Trigger: the successful server response for that submission.
- Parameters: non-sensitive form identifier and service category.
- Duplicate handling: prevent repeated UI actions from reporting the same accepted submission twice within the flow.
Do not put names, email addresses, phone numbers or free-text enquiry contents into analytics event parameters.
Treat the form as a sequence of states
A useful implementation model is:
idle → validating → submitting → accepted OR failed
A failed validation should stay out of the success path. A rejected request should show a recoverable error. Disable accidental repeated submission while the request is pending, but restore the control when the request fails.
If the server accepted the enquiry but the response was lost, a browser retry can create a second record. Server-side idempotency can help solve that application problem. A client-side boolean alone is not a universal deduplication strategy across refreshes, tabs and retries.
Run these six tests before campaign launch
- Invalid form: submit with missing required fields. Expect an error and no lead-success event.
- Server failure: simulate a rejected request in a test environment. Expect no success event and a usable retry path.
- Accepted form: submit valid test data. Expect one accepted record and one intended success event.
- Double click: try repeated submission while pending. Check both the backend and the analytics debugger.
- Reload or revisit: revisit the success screen. Ensure a page view does not automatically become a second lead.
- Delivery: confirm the accepted test enquiry reaches the actual inbox or CRM, with enough context for follow-up.
Use staging where possible. If you must test production, label the enquiry clearly and exclude test activity from business reporting through your established process. Respect consent choices; do not force tracking to fire as a way of making a test pass.
Inspect the Google Ads goal, too
A correctly fired event can still be used in the wrong campaign goal. Under standard goals, primary conversion actions may guide bidding when the campaign uses that goal; secondary actions are generally observational. Custom goals are the exception: included secondary actions can still be used for bidding. Google’s primary and secondary conversion documentation explains this distinction.
Do not report a phone-link tap as a completed sales call. Likewise, an accepted enquiry is not automatically a qualified lead or a sale. Preserve those distinctions in your reporting.
Keep the release evidence
Record the test date, page URL, event name, observed count and delivery result. Repeat the relevant tests after changes to the form, routing, consent configuration or tag setup.
The point is simple: the event should describe what happened, not what the business hoped happened.
For help aligning a website’s enquiry flow with campaign measurement, see deDevze’s digital marketing services.
