A form click is not an enquiry: build a measurement chain

A report showing more conversions may be counting button clicks rather than received enquiries. Define the business outcome first, then connect the measurement stages. A useful report explains where visitors stop and where accepted records go next.

Write an event dictionary

Separate form view, submission attempt, accepted submission and qualified enquiry. A click on submit can happen before validation, while a thank-you page may be opened again. Decide exactly which observable action each event describes.

Do not send names, email addresses or message contents into general analytics events. Use non-identifying technical labels and review the applicable collection and consent setup separately. This guide proposes a measurement design, not a privacy compliance assessment.

Map the chain

Keep qualification in the operational system with a documented rule. A tracking script cannot decide whether an enquiry is commercially useful unless that decision is actually defined and connected.

Read the text version

1. Form viewed. The visitor saw the form.
2. Submission attempted. The visitor tried to send it.
3. Submission accepted. The system validated and retained the record.
4. Enquiry qualified. The team assessed the business opportunity.

Test the event and the record together

Google Analytics supports event collection, but the event name alone does not establish what your implementation measures. Use an authorised synthetic test and inspect both the tracking result and the retained submission.

1. Submit a valid test and look for one accepted outcome.
2. Try an invalid required field and confirm it is not counted as accepted.
3. Refresh or revisit the success route and check duplication.
4. Test a failed submission and inspect the recovery message.
5. Verify whether relevant consent states change collection.

Record any expected measurement gaps. Analytics counts and operational records can differ because of collection conditions or implementation problems; investigate before declaring the form broken.

Use the report to decide an action

Hypothetical example: many people view the form, few attempt it, and valid attempts are retained correctly. Investigate the request and field burden before changing the handoff. If accepted submissions exist but no owner receives them, investigate the operational chain instead.

Review accepted records, invalid attempts and qualification using the same reporting period and timezone. Exclude your controlled tests where the system supports a reliable method. Avoid comparing a weekly analytics chart with an unfiltered lifetime enquiry list.

The result is a chain of evidence, not a promised conversion increase. Each stage should have an owner who can explain the definition and the action it informs.

Read a funnel without mistaking every gap for a fault

Suppose a hypothetical weekly report shows 200 form views, 30 submission attempts, 24 accepted submissions and 18 qualified enquiries. View-to-attempt is 15 per cent, attempt-to-accepted is 80 per cent and accepted-to-qualified is 75 per cent. Those rates answer different questions and use different denominators.

The first gap suggests reviewing the offer, field burden and visitor intent. The second needs validation and submission diagnostics. The third depends on the team’s qualification definition and traffic mix. None of the numbers alone proves why people stopped. Review the corresponding records and observed behaviour before choosing a fix.

Define when each event is allowed to fire

An illustrative event dictionary could define form_attempt as the user’s submission action and enquiry_accepted as the application’s confirmed valid intake. An invalid required field can produce an attempt but must not masquerade as accepted intake. The precise implementation depends on the form software; a generic click trigger cannot establish server acceptance.

Check reloads, browser back navigation, repeated clicks and failures. A thank-you URL visited twice should not automatically represent two distinct enquiries. Use the application’s actual confirmation and deduplication design where supported. Keep operational identifiers and personal information out of general analytics unless a separate reviewed design explicitly permits the intended non-identifying data.

Reconcile two systems using comparable definitions

Analytics and the operational database observe different things. Collection can be affected by consent, browser behaviour and implementation. The database may retain spam, tests or records outside the analytics period. Choose the same timezone, dates and inclusion rules, then document expected gaps before investigating unexplained ones.

If accepted analytics events exceed retained records, check duplicate firing and the meaning of “accepted”. If retained records exceed events, inspect collection conditions and tracking failures. If both agree but ownership is missing, fix the handoff rather than the event name.

Keep a small evidence log for synthetic valid, invalid, repeated and failed attempts, with observed events and retained outcomes. Report enquiry quality from the operational decision process, not as a guess inferred from a button click. The report becomes useful when each stage leads to a specific investigation or business decision.

Take one practical next step

If the gap is between the event and the retained enquiry, discuss a concrete implementation through custom development. Scope, timing and price are agreed before work starts. An enquiry does not place an order or guarantee a result.

Sources and further reading

• Google Analytics event setup

About the author

Martin Iliev

Martin builds Set It Once to help people spend less time on repeated work. His guides explain what you can try, how to check the result and where the limits are.

More about Martin

All articles