Enhanced conversions: web and lead workflows, current settings and verification
Understand the different business workflows behind enhanced conversions, Google’s unified settings, and the evidence needed to verify a setup.
By Mika Garcia · Published
In this article
Start with what the feature adds
Enhanced conversions supplements Google conversion measurement with eligible first-party customer information. Google describes hashing customer data such as email addresses before matching it to improve measurement. It is an additional matching mechanism, not a new definition of a sale.
A website purchase and a later closed lead remain different business workflows even when account settings are unified. First identify where your meaningful conversion occurs and which system observes it. Then follow the current Google instructions for that data path.
A hash should not be treated as permission to share a field. Collection, consent, destination policies and data handling still need to be evaluated for the use case. Do not send information merely because a field exists in the source system.
Avoid outdated web-versus-leads setup instructions
Google’s 2026 settings update describes a unified enhanced-conversions on/off setting and simultaneous acceptance of user-provided data from supported website and connection paths. Its notice also describes migration of offline and enhanced-lead API uploads to Data Manager API, with legacy eligibility conditions.
That means a guide asking every advertiser to choose one old implementation-method setting can be misleading. Use the current account interface and official instructions. Do not infer from the unified switch that every data source is already connected, validated or suitable for your conversion.
This article explains the workflow distinctions and a verification method. It does not certify that a particular account has completed a migration or that a third-party connector implements every enhanced-conversion feature.
Distinguish the outcome from the transport
For a website purchase, the meaningful outcome may be completed at checkout. For a lead workflow, the website interaction may be followed by qualification and a sale in another system. In both cases, the matching data needs to refer to the intended customer and outcome.
Write down which record establishes the conversion, when it occurred, which value it carries and which sender owns delivery. Keep a later lead outcome distinct from its initial form submission. A shared setting does not make those events interchangeable.
Two business workflows
Website outcome
Checkout → conversion
The meaningful outcome occurs on the website journey.
Later lead outcome
Form → qualification → sale
The meaningful outcome is recorded later.
Design a verification case with an expected result
Imagine a permitted test journey in which a customer submits a form and later pays $500. The form record contains the lead reference and the approved matching fields. The later payment has its own business identifier, event time, amount and currency.
Before sending anything, decide whether the conversion action represents the form, the qualified lead or the payment. If it represents payment, the form is supporting journey evidence, not a second $500 outcome. Keep the response from the sender attached to the payment record.
This is an illustrative record design, not a claim that any particular test customer can be matched or credited to an ad. An intentional unmatched case is also useful: it helps confirm that the system exposes missing evidence rather than silently inventing a source.
Read diagnostics before reading campaign totals
Check the source event and the intended conversion configuration, then inspect the supported sender’s response and Google’s diagnostics. Confirm field formatting against the current implementation guide for the chosen path. Avoid normalizing or hashing twice when a supported integration already performs that step.
After delivery, investigate matching and reporting as separate questions. Acceptance means a request passed a particular stage; it does not guarantee that every record will receive campaign credit. Compare consistent conversion definitions, dates and reporting windows.
Evidence to collect at each boundary
1. Source
Defined outcome
Correct reference, time, value and currency.
2. Sender
Supported path
Formatting and response evidence.
3. Google
Diagnostics + reporting
Investigate matching and credit separately.
Keep the DATALYR setup claim narrow and verifiable
If DATALYR is part of the workflow, follow its current Google Ads connection and delivery documentation. Verify the exact supported path with the account you use. The presence of a Google Ads integration alone does not establish support for every web-tag or enhanced-lead implementation method.
Use a short verification record containing the source identifier, outcome, sender, response and unresolved questions. Recheck when the conversion action, source schema, consent configuration or integration version changes. That record is more durable than screenshots of a settings page.
If the source-to-sale handoff itself is unclear, fix the event contract first. Better matching cannot make a signup become a paid customer or correct a revenue amount drawn from the wrong field.