Before configuring a conversion, decide exactly which event it represents. Clicking a contact option, submitting an enquiry and paying for an order are three different actions.
A business can observe all three, but should not combine them under an ambiguous label. Otherwise, a report can show many “successes” without explaining whether new work actually resulted. Definition starts with the business process and only then moves to technical configuration.
Describe the actual event
For a fictional training provider, an important action could be a complete enquiry about a team session. Write down when that action has successfully finished. Opening the form is insufficient. Clicking “Submit” is also insufficient if an error follows or the message never reaches the provider.
A definition might be: “A new session enquiry has been successfully accepted by the system and is available in the intended handling process.” That requires a clear technical acknowledgement and a traceable arrival. Required information should follow the actual enquiry process; do not collect extra fields merely to simplify reporting.
If the website offers only an email link, clicking it generally does not establish whether a message was sent. The observed event should be called “Email link clicked”. Calling it “Enquiry received” would claim more than the measurement demonstrates.
Create a short event register
For each event, record its meaning, trigger and verification method. Add whether it is the main objective or a supporting signal. Downloading course information may indicate interest without amounting to a booking.
Use understandable names. “Session enquiry successfully accepted” is more useful during a handover than “Final event 2”. Display names and technical identifiers need not be identical, but their relationship should be unambiguous. Keep the definition alongside the configuration so website changes cannot quietly alter its meaning.
Google's official website conversion instructions describe configuration in its product. Configuration does not replace the business decision about which action matters. Check the currently available settings rather than copying values from another account.
Prevent duplicate events
A successful form submission can produce several visible consequences: a confirmation page, a record in the system and perhaps an additional confirmation step. If several measurements count the same result as independent successes, the total increases without additional enquiries.
Pay particular attention to reloading a confirmation page, going back in the browser and repeatedly clicking the button. The appropriate technical safeguard depends on the system. The business requirement remains the same: an accepted enquiry should not become a new one merely because its confirmation is displayed again.
In an online shop, a unique order identifier may be relevant to this process. A simple contact route may require another mechanism. Do not adopt a technical solution without checking which information it transmits and whether it fits the system in use.
Test success and failure separately
Perform a successful test using designated test details and check that it arrives. Then try an invalid attempt, such as leaving a required field empty. That attempt must not count as a successful submission. Check an abandoned journey as well: starting a form does not mean completing it.
Review mobile behavior and the contact routes actually supported. If the site offers telephone, email and a form, labels must reflect their different levels of observability. A telephone-link click is not proof that a call was answered. Without an appropriate technical basis, the report should not imply that the conversation is known.
Document the time of the test, the action and expected result. Test events should remain identifiable in later business reporting or be excluded through a documented process. Check possible delays between an event and its appearance in a report before deciding that an apparently empty report indicates failure.
Do not mistake measurement for the entire process
Consent choices, technical limitations and unmeasured contact routes can mean that reporting covers only part of what happens. Which information may be processed must be established for the actual system and use. Do not enable additional collection simply because it would make a figure look more complete.
Regularly compare platform figures with the business's incoming records without assuming they should match perfectly. If there are 14 measured events and eleven received messages, first inspect definitions, test data, duplicate triggers and reporting periods. A discrepancy is a reason to investigate, not proof of a particular cause.
Revisit the definition when forms, confirmation pages or booking workflows change. That keeps the metric tied to the action it was originally intended to describe.
