Conversion tracking tied to business outcomes

The primary event may be a purchase, confirmed booking, qualified lead, paid deposit or accepted quote. I separate that outcome from supporting events such as button clicks or form starts.

This keeps reporting focused on decisions the business can actually act on.

Events and parameters should come from the application state rather than fragile click selectors where possible. Useful values may include form type, service, location, order ID or lead reference, provided they respect privacy and platform policies.

A documented data layer reduces duplicate or inconsistent tracking during design changes.

UTM parameters and supported advertising identifiers can be captured with the initial lead and stored in the operational record. The system should define retention, access and consent requirements rather than collecting every available value by default.

For Google Ads, enhanced conversions for leads and offline conversion imports have specific setup and data-quality requirements.

When the CRM or admin tool records that a lead qualified or purchased, that event can sometimes be sent back to the advertising platform using the supported identifier or first-party matching method.

This allows bidding and reporting to learn from revenue-relevant outcomes instead of only the easiest form submissions.

Testing covers browser events, tag triggers, network requests, analytics reports and duplicate prevention. Consent settings and production domains are checked separately from preview mode.

A tag showing as fired does not prove that the platform accepted or attributed the conversion correctly.