Measure successful enquiries before judging a campaign

A contact-button click tells you that someone clicked a button. It does not tell you whether the form accepted their message, whether the email arrived or whether the enquiry was relevant. Before comparing campaigns, decide which action your measurement is supposed to represent.

For a small service business, a confirmed enquiry is often a useful starting point. The job is to connect that definition to a reliable signal on the website, check the collection and then interpret the result alongside the enquiries the business actually receives.

Write a definition someone else can test

“Track leads” leaves too much room for interpretation. A more useful specification is: record an enquiry when the website’s contact form confirms that a valid submission has been accepted.

That definition deliberately stops short of a qualified sales lead. The form may accept a supplier pitch or an unsuitable request. Keep qualification in your enquiry log or customer system, where someone can assess it.

For a fictional repair business, the measurement specification might read:

• Action: accepted submission of the repair-enquiry form.
• Event name: generate_lead.
• Success signal: the form platform confirms acceptance.
• Failure condition: validation errors or failed requests must not record a completed enquiry.
• Duplicate check: refreshing a confirmation page must not create another enquiry for the same submission.
• Owner: the person responsible for the form integration and its test record.

Google documents generate_lead as a recommended event. Using that name does not configure your form. The event still needs to be sent at the right moment through the implementation used by your website.

Attach the event to confirmed success

Ask whoever maintains the form which supported success signal is available. A platform may offer an integration, a submission callback or a confirmation-page workflow. The right trigger depends on the form system.

A click listener attached to Submit is insufficient for this definition. It can fire before validation, before the request reaches the server or when the user clicks repeatedly. An event called “lead” can still be measuring clicks if its trigger is wrong.

A dedicated thank-you page can help, but it brings another question: what happens when someone reloads the page or opens its address directly? If every page view sends the event, the count can exceed the number of accepted submissions. Have the implementer explain how the workflow handles those cases.

Keep the event payload limited to what is needed for measurement. There is no reason to include the customer’s name, phone number, email address or message in this example. An invented cash value is also unhelpful. An enquiry is not a completed sale with known revenue.

Check which features are already enabled

Before adding a new tag, inspect the existing setup. A plugin, tag-manager container or another integration may already send a form event. Two implementations attached to the same success signal can both look correct when inspected separately.

This is also why a universal snippet is a poor substitute for checking the form platform. The event name may be shared across websites, but their submission behaviour can differ.

Test a small set of different outcomes

Google’s event setup documentation describes Realtime and DebugView for inspecting collected events. DebugView requires additional configuration. Use those tools alongside the form’s own confirmation and delivery record.

1. Send one valid test enquiry. Check that the website confirms success and the message reaches its destination.
2. Submit a form with a required field missing. Confirm that this does not produce a completed-enquiry event.
3. Where the form can be tested safely, check a failed submission response rather than assuming all requests succeed.
4. Refresh the confirmation page and try its address directly. Look for duplicate or false events.
5. Record the observed event name, test time and result in the correct Analytics property.

Do not send large numbers of test enquiries to a live business inbox. Arrange a small controlled test and label its message clearly. If a failure cannot be reproduced safely on production, ask for that part of the test in a suitable development environment.

Mark the event as a key event after checking it

A key event identifies an action you consider important in GA4. Google’s key-event guidance explains the available setup routes and permissions. The reporting change applies from creation onward and does not rewrite historical data.

Allow for reporting delays. A recent action appearing in a debugging view does not mean it must already appear in every standard report. Keep the test time so that you can compare the same observation later.

Setting a GA4 key event is also separate from deciding which Google Ads conversions should guide bidding. If advertising is involved, check that configuration explicitly rather than assuming the Analytics label completes it.

Reconcile the count with actual enquiries

Suppose the fictional business receives eight accepted forms while Analytics records six enquiry events over the same period. The difference needs investigation, but it does not establish which system is wrong. Check collection settings, duplicate messages, test submissions and the time boundaries.

Keep a second record of which enquiries were useful. A campaign that sends many unsuitable messages may need a different offer or clearer qualification. Once the measurement behaves consistently, the owner can discuss those commercial questions with evidence that goes beyond button clicks.