1. Enhanced Conversions need a connection you can verify
Enhanced Conversions supplement conversion measurement in Google Ads with customer data your business collects directly. For SMEs, the practical task is to establish a traceable connection between a correctly triggered website event, identifiers used with the necessary permission and, where relevant, a later CRM event. Turning on a setting does not, on its own, confirm that this connection works or that you have acquired additional customers.
This guide takes you from defining an event through to acceptance testing. At its centre is the Enhanced Conversions acceptance checklist: a working framework developed by SaleStudia that helps marketing, website teams and sales verify the same measurement chain. It brings together evidence, responsibilities and clear STOP decisions. This is a practical template, rather than a form prescribed by Google.
What a reliable implementation looks like
For a controlled test case, you can explain when the event occurred, which consent status applied, how the contact data was prepared, which business status was recorded in the CRM and what response the transmission method returned. You then reconcile the results with your own business records. This chain of evidence tells you more than an isolated message saying that a connection has been set up.
The examples below are illustrative test cases and make no performance promises. This article covers the connection and its quality assurance. Choosing a complete set of Data Manager connectors, evaluating sales leads and setting bidding values remain separate tasks. Technical information reviewed on 9 September 2026.
2. What changed in the setup during 2026
Google began accepting user-provided data simultaneously from tags, Data Manager and APIs in April 2026; the rollout of unified activation for web and leads began in June. Current help describes a combined setting. See the official Enhanced Conversions changes for 2026. Existing users are migrated automatically if they previously accepted the customer data terms; Enhanced Conversions can still be disabled per conversion action.
One shared switch does not define your events
In Google Ads, open “Goals” → “Settings” → “Customer data use”; review “Turn on enhanced conversions” and the customer data terms. “Conversion-based customer lists” requires separate audience activation. Record the account, the conversion action being tested and the actual switch status in your acceptance checklist. Next, map the website fields to the correct event and verify the separately configured CRM import for lead outcomes. The account setting cannot provide this evidence for you.
For acceptance testing, the website event and the later business outcome remain distinct. A form may be submitted successfully today, while the resulting order is confirmed later. Even with a shared setting, the time, conversion action and source of each event must be unambiguous. Document the actual account configuration and the transmission methods that have been set up.
A business can combine a tag, Data Manager or an API without creating a conflict simply by doing so. Problems arise when it is unclear which method supplies which event or which supplementary data. Record these responsibilities in the acceptance checklist. The same terminology in two interfaces is not evidence that both perform the same technical function.
A check for existing accounts: Has only the interface changed, has a data source been added, or has the business outcome being measured changed? Only the last option directly changes the business definition. However, all three may require different technical checks.
3. Separate the website conversion from the later lead outcome
With enhanced conversions for web, customer data supplements a conversion event recorded on the website. With enhanced conversions for leads, data collected at the website contact point helps match outcomes submitted later. The Google overview of enhanced conversions explains both uses. Combining their setup does not turn a submitted form into a confirmed order.
Define the business outcome first
A fictional trades business distinguishes between a submitted enquiry and a confirmed on-site appointment. An enquiry can be measured correctly in technical terms yet still be unusable for sales. Conversely, an appointment can be booked even when its advertising attribution is incomplete. The acceptance checklist therefore needs separate fields for the business event and its technical recording.
Describe the outcome so that two employees would classify the same case in the same way: for example, “Appointment confirmed by the customer and saved in the CRM with the confirmation time”. Avoid vague definitions such as “good lead”. Decide separately which outcome the bidding strategy should use, based on your primary, secondary and campaign-specific conversion goals.
Also check the boundaries between conversion actions. The same contact can progress through several genuine business events. Multiple technical records of the same event, however, may represent duplicate counting. A shared customer reference does not remove this distinction. Acceptance always applies to a specific event definition with a traceable source.
4. Create the Enhanced Conversions acceptance checklist
Start your acceptance checklist with one conversion action and a clearly defined workflow. Its rows describe handover points rather than departments. This makes it easier to see where the link to a correctly defined business event becomes ambiguous. Keep supporting evidence in a workspace with restricted access and use only internal test-case references in the checklist itself.
Each row needs a clear acceptance decision
| Handover point | Required state | Evidence | Owner | STOP reason | Acceptance |
|---|---|---|---|---|---|
| Website event | Defined business outcome occurred | Test case and event time | Website team | Triggered before success | Verified or open |
| Consent | Permitted data flow under the agreed implementation | Status and version reference | Privacy lead | Unclear status | Verified or open |
| Identifier | Field prepared correctly | Redacted test log | Implementation team | Wrong field or double hashing | Verified or open |
| CRM event | Defined business status reached | Event ID and time | Sales | Status merely assumed | Verified or open |
| Transmission | Record processed | Response for the individual record | Integration team | Unhandled error | Verified or open |
| Reconciliation | Differences can be explained | Reconciled event list | Marketing analytics | Unexplained duplicate counting | Verified or open |
Add the account reference, conversion action, configuration version, test date and responsible person to the working document. These details apply to the whole checklist. Acceptance without a version reference may lose its value after a form changes, even if nobody deliberately altered the measurement configuration.
Write “open” when evidence is missing. A green dashboard must not silently close that gap. The table is deliberately concise: the detail belongs in the linked internal evidence, while the checklist records the decision. This also keeps it readable for business owners who do not need to assess a tag configuration themselves.
5. Clarify consent, purpose and responsibility first
Your use of customer data must meet the applicable requirements and fit your particular implementation. Google's customer data policies set their own conditions. A hash is not the same as anonymous data; hashing neither obtains consent nor grants blanket permission to share information. Google prohibits certain forms of conversion measurement involving sensitive categories, and consent does not override those exclusions. Have the appropriate specialist resolve outstanding privacy questions before any live transmission.
Test the data flow under different consent decisions
Work with the people responsible for the website and privacy to describe which user data may be available, at what point, and which states your consent management system passes to measurement. The parameters for advertising data and personalised advertising serve different purposes. A technical consent status describes the decision being communicated; its presence alone does not establish that the preceding consent request was implemented correctly in legal or technical terms.
At a minimum, test the cases your workflow supports for granted consent, denied consent and a subsequent change of decision. Record which transmissions are permitted in each case. For an introduction to how these elements fit together, see our guide to Google Ads conversion tracking with GA4 and Consent Mode.
Assign clear responsibilities: marketing defines the measurement question, sales confirms the business event, the implementation team manages the data flow and the privacy lead assesses the applicable requirements. In a small team, one person may perform several roles. Those responsibilities must still remain distinct in the checklist so that a missing business check is not mistaken for a completed technical test.
6. Prepare identifiers using an agreed data specification
Data preparation must follow the requirements of the chosen transmission method. Depending on the integration, Google performs the hashing, or you supply hash values that have already been prepared correctly. The specified one-way hash function is SHA-256. Preparation includes, for example, removing leading and trailing whitespace, converting email addresses to lowercase and formatting telephone numbers in E.164. Provider-specific email rules and individual fields are governed by the current requirements of the particular integration. Specify exactly where normalisation occurs and where hashing takes place. An already hashed value must not accidentally be processed again as raw input.
Document field sources and processing together
For an email address, record which form field supplies it, how unnecessary whitespace is handled and which integration step performs the required normalisation. For telephone numbers, the source of the country code must be traceable. Inferring that code from the website language can produce an error when international customers use the same language version.
Use a small set of synthetic test values covering different formatting, empty fields and invalid inputs. Run processing checks locally or in an appropriate test environment. These test values must not be passed off as real customer data to improve apparent coverage metrics. Their purpose is to verify the data specification, rather than create artificial measurement signals.
Do not transmit additional information simply because it exists in the CRM. Keep the agreed fields and their purposes narrowly defined. An error log should contain the error and an internal reference, rather than automatically including complete contact details. For troubleshooting, “Invalid telephone format” is often more useful than an unprotected export of the entire contact list.
7. Capture the right moment on the website
The form and the conversion event must work together technically. In one illustrative failure, a website clears its input fields after a successful submission but before measurement reads them. The event fires, yet the supplementary data is missing. In the opposite failure, clicking the submit button triggers the event even though validation subsequently rejects the form.
Check success, availability and transmission separately
A status of ad_user_data=denied disables collection of hashed personal data for Enhanced Conversions. ad_storage and ad_personalization address other aspects. The Consent Mode documentation explains these distinctions. A server-side transmission method does not replace the requirement to respect consent.
First, check whether the server or application has confirmed that the business event succeeded. Then verify that the required fields are available at the permitted moment. Only after that should you check their intended transmission. This sequence prevents a technically visible field from being confused with an enquiry that has actually been submitted successfully.
STOP: Contact details must not be placed pre-emptively in URLs, publicly accessible data attributes, general analytics events or public logs. Specify the intended data channel and pay particular attention to redirects, embedded forms and multistep workflows.
Repeat the test case after an invalid entry, a correction and a resubmission. Also test reloading a confirmation page. The aim is to cover meaningful differences in the workflow, rather than run as many identical tests as possible. Document whether another page view creates a new event and which safeguard prevents an unintended repeat.
If the website has several language versions or form types, test representative variants that follow different technical workflows. A successful test of the German contact form does not prove that an English appointment-booking flow built differently makes the same data available in time.
8. Choose an implementation with responsibilities you can verify
Several setup methods are available for websites. An implementation using Google Tag Manager, for example, must correctly connect the relevant user data with the trigger timing; the guide to enhanced conversions with Google Tag Manager describes that approach. Base the decision on your website and how reliably your team can maintain the setup, rather than the apparent simplicity of a switch.
A method is only as reliable as its acceptance testing
| Approach | Suitable context | Key dependency | Test evidence | Typical error | Responsibility |
|---|---|---|---|---|---|
| Automatic collection | Suitable supported website | Actual field detection | Correct data in the event | Empty or incorrect fields | Website and tracking teams |
| Manual tag configuration | Clearly available inputs | Stable variables and triggering | Verified data specification | Reading after fields are cleared | Implementation team |
| Partner integration | Supported shop or form solution | Specific integration version | Documented capabilities | Unchecked default assumptions | Operator and partner |
| Supplementary data import | Business outcomes available later | Identity and event definition | Processing evidence for each record | Importing the same event repeatedly | CRM and integration teams |
These approaches are not necessarily mutually exclusive. Website data collection can work alongside a later import. For every combination, the acceptance checklist must state which system is responsible for each part of the measurement chain. Avoid unclear parallel methods where nobody knows whether a second integration supplements the first or duplicates it.
Treat form changes as potential measurement changes. If a plugin introduces new field names, moves confirmation into a dialog or embeds an external booking service, repeat the relevant acceptance tests. Choosing a setup method once does not replace this maintenance process.
9. Verify website collection with specific test cases
The enhanced conversions for web diagnostics distinguish between issues including missing data, empty fields and invalid formats. Coverage describes the proportion of eligible events containing sufficient user data; match rate concerns matching with Google data. These metrics answer different questions. Alerts may not appear at low volumes, so an empty warning panel does not replace a complete acceptance test.
Turn an observed event into recorded evidence
For a controlled test case, open the appropriate preview or diagnostic tool for your implementation. Record the expected event definition, the actual trigger time and whether the intended fields are present. Then check the permitted transmission state. Avoid unredacted screenshots that spread contact details or access credentials across general project folders.
Add a negative test: the form fails to submit successfully because of an invalid entry. This case must not produce the same business outcome in your measurement. Another negative test with denied consent checks the data flow defined for that decision. Together, these cases reveal more than several successful submissions under identical conditions.
Save the diagnostic findings with the date, reporting period and affected conversion action. A status change following a modification is initially an observation. Retest the affected step before treating the cause as established. The website row in the acceptance checklist passes only when the event, fields and status all correspond to the same workflow.
10. Connect the CRM contact to the correct business outcome
For the lead workflow, the website data and the outcome imported later must correspond. Google recommends continuing to send GCLIDs where available. When user-provided data collection is configured correctly, supported events without a GCLID can also contribute; without that tag-based collection, the GCLID is required. This distinction is explained in the documentation on enhanced conversions for leads.
Keep contact identity and event identity separate
An email address does not uniquely identify an order. The same contact may enquire repeatedly or place several orders. Maintain a unique business-event reference in addition to the contact reference. For supported conversion tracking methods, Google explains preventing duplicate conversions with transaction IDs: the same conversion action and the same transaction ID allow corresponding repeats to be suppressed. This does not imply automatic deduplication across different conversion actions.
In the illustrative test case, a confirmed order receives its own reference. Sending that order again must retain the same event reference. A genuine subsequent order needs a new reference. Choosing “One” as the counting method does not replace this data specification. Also avoid using contact details that directly identify a person as the transaction ID.
Before you export, the sales process must maintain statuses reliably. Our guide to organising leads and sales workflows in the CRM helps with this prerequisite. Enhanced Conversions cannot repair inconsistently used status fields. In the acceptance checklist, sales therefore confirms the business event before the integration team approves its transmission.
11. Check the transition rules for API integrations
Restrictions on new offline and lead uploads through the Google Ads API have applied since 15 June 2026. The current API documentation for offline conversions ties the restriction to developer tokens without previous relevant upload requests and directs users to the Data Manager API. Existing eligible integrations were not all shut down by this change. Conversely, an available code example does not establish current permission to upload.
Verify the actual connection behind the label
Ask the integration provider which API method it uses, whether the specific developer token is eligible and when an individual record was last processed successfully. “Google integration active” is not sufficient. That label may refer to a login, an export schedule or another function while conversion uploads are already failing.
Record in the acceptance checklist whether the connection remains eligible and functional, requires changes or has yet to be checked. Where necessary, request the relevant error message with a redacted reference. Do not put secret tokens or complete user records in the shared checklist.
Scope of this guide: The acceptance test verifies whether the transmission method works. Setting up or migrating individual Data Manager connectors is a separate implementation task. A change in transport method must not silently alter the previously agreed events, timestamps or identity rules.
If two methods temporarily run in parallel, decide in advance which one counts in production and how repeats will be identified. Unplanned parallel operation makes it harder to diagnose causes precisely when you need a reliable comparison.
12. Map diagnostic messages to the correct checklist row
The enhanced conversions for leads diagnostics distinguish between issues including tags not firing, missing data, no import attempts and no matches. Acceptance of an upload request does not yet confirm that every record was processed successfully; even a processed conversion is not a confirmed match to an ad interaction. Map each message to a specific handover point in your acceptance checklist.
Use the observation to choose the next check
| Observation | Affected handover | Supported conclusion | Open question | Next check | Acceptance limit |
|---|---|---|---|---|---|
| Tag not detected | Website to measurement | Collection not demonstrated | Triggering or visibility? | Test the specific workflow | Website cannot pass |
| Empty data | Form to identifier | Field content missing | Read too late? | Availability at event time | Data cannot pass |
| No import attempts | CRM to transmission | Import not demonstrated | Export or schedule? | Run log and record selection | Import cannot pass |
| Record processed successfully | Transmission to processing | Processing confirmed | Has a match been found? | Diagnostics and reconciliation | No proof of outcome |
| No match | Identifier to matching | Matching not demonstrated | Inconsistent data or an unmet prerequisite? | Website and CRM rules | Cause remains unresolved |
A message provides a starting point for investigation, not necessarily the final cause. If contact data is processed differently during website collection and import, a discrepancy can arise. But the same observation can also have other causes. Record a hypothesis separately from a confirmed finding.
Give every unresolved finding an owner and a date for retesting. The appropriate response is a correction at the affected handover point that you can verify. Repeating a complete export before resolving the cause may reproduce errors and make later reconciliation harder.
13. Interpret increases in measured conversions correctly
The impact results for enhanced conversions for web concern additional reported conversions. Google describes a possible training period of up to 30 days and a separate 30-day display period for the impact card. These are different periods, and neither creates a general requirement to delay technical checks. The card disappearing later does not, by itself, establish that measurement has failed.
Separate measurement improvements from business performance
A fictional business sees more attributed orders in Google Ads after the change, while its actual order list remains unchanged. This may reflect better measurement of existing outcomes. It would be incorrect to infer additional sales caused by advertising from that observation alone. Conversely, an unchanged advertising metric does not prove that the implementation has had no effect.
Track three levels side by side: business events that actually occurred, events transmitted by your systems and conversions reported by Google Ads. Record their respective definitions and time references. Exact agreement across all three levels is not a sensible universal acceptance criterion, because selection, consent, matching eligibility and reporting logic may differ.
If you simultaneously change a conversion action to primary or revise its definition, mark a break in the measurement series. A before-and-after comparison may then mix new data, new goals and different reporting bases. Record such changes in the acceptance checklist and assess business developments using your own operational data. A claim about additional impact requires a study designed to answer that question.
14. Control timestamps, delayed uploads and corrections
For enhanced conversions for leads, Google specifies an upload limit of 63 days after the associated last click. The guidelines for importing offline conversions distinguish this limit from the general offline rule. The period does not start with a later CRM status change, and it is not a data retention period. Also check the settings that apply to your conversion action.
Every delayed upload must retain its original reference
A nightly export must not automatically assign its export time to the business outcome. Store the actual event time with an unambiguous time-zone reference. If an order is confirmed in the evening and transmitted the next morning, confirmation and transmission remain two different timestamps. Without this distinction, a daily comparison can appear to show missing or additional outcomes.
For acceptance testing, compare suitable reports by conversion time with the corresponding period in your business records. A standard report using a different time reference can differ even when the transmission is technically correct. Document the columns, filters and period used directly alongside the reconciliation.
After an error, retry only the affected records according to the rules of the specific import method. A record already accepted, a rejected record and an event whose business details were corrected later need different treatment. Do not artificially change its date or identity to get around a rejection. Before a delayed upload, check whether the record still meets the applicable eligibility conditions.
For a correction to the business event, first establish what actually changed. Only then choose the supported technical treatment. This is how the acceptance checklist prevents an apparent repair from creating a second business outcome.
15. Apply clear STOP rules before acceptance
Acceptance testing must support a decision. It is not complete when a team has merely collected all the warnings it found. Classify each open issue according to whether it blocks live data transmission, prevents business analysis or requires a limited observation period. The classification depends on the actual error and its scope.
Four questions lead to an acceptance decision
Is the intended use permitted? If consent status is unclear or data fields are not permitted, stop the affected user-data flow. A better match rate is no reason to relax this boundary.
Is the event genuine? If it fires before a form succeeds or relies on an assumed CRM status, correct the recording of the business event first. Additional identifiers do not make an incorrect event valid.
Is the transmission unambiguous? If parallel methods are unresolved, IDs are incorrect or record-level responses are missing, that handover remains open. Limit the affected workflow before more cases are added.
Can the conclusion be supported? If matching remains unclear or reconciliation is contradictory, do not approve a claim of success. A technically permitted transmission and its analytical assessment may be at different stages of verification.
Also document the condition for resuming: for example, a corrected field mapping followed by a successful repeat of the negative test. “Look at it again later” is not a condition on which a decision can be made. Acceptance applies to the tested configuration and documented scope, rather than automatically covering every further campaign, form or data source.
16. Introduce the setup in traceable stages
Begin with a manageable workflow for which all participating systems are accessible. Expand the scope only after resolving the outstanding findings. This is our own suggested rollout plan; it prescribes neither fixed numbers of days nor a universal minimum volume. Where business events occur infrequently, distinguish deliberately between technical test cases and later observations.
Each stage ends with specific evidence
| Stage | Task | Output | Acceptance condition | Next step |
|---|---|---|---|---|
| Definition | Agree on the event and purpose | Completed scope definition | Unambiguous business meaning | Check the data specification |
| Preparation | Clarify fields and responsibilities | Documented data flow | Permitted use established | Controlled test cases |
| Technical acceptance | Test positive and negative cases | Evidence for each handover | Blocking errors resolved | Limited observation |
| Reconciliation | Compare business records and reports | Explained differences | Limits of conclusions recorded | Expand the scope |
| Operation | Monitor changes and errors | Current acceptance checklist | Ownership established | Retest when changes occur |
Include the checklist in your existing quality review. The Google Ads audit checklist for SMEs helps you examine the measurement setup alongside account structure and other areas of review. Avoid bundling every account change into the same rollout, however, as that makes observed differences harder to trace to a particular change.
Finally, name the person who will route new errors to the appropriate owner. Also specify which changes trigger another acceptance test. A new form, a revised CRM status or an integration change provides a more meaningful trigger than a calendar entry alone.
17. Frequently asked questions about Enhanced Conversions
Does the shared setting replace the existing website and lead workflows?
It simplifies the settings layer. Website events and outcomes imported later still need corresponding data and a correct connection. Check existing workflows according to what they actually do, even if the interface now uses different labels.
Can I use enhanced conversions with multiple data sources?
The current setup supports multiple sources of user-provided data. This does not grant blanket permission to transmit complete conversion events repeatedly. Additional event sources may need a separate setup; identity and responsibility must remain unambiguous.
Is hashing enough to make a data flow permissible?
No. Hashing does not replace checking the intended use, obtaining required consent or meeting other applicable requirements. Document the intended data flow and resolve outstanding questions before live transmission.
Must every lead outcome contain a GCLID?
Continue to send GCLIDs where available. With appropriately configured website collection, supported lead events can also contribute through user-provided data. Without this collection, the GCLID is required. Check the specific data flow before filtering out events.
Does a successful import prove a match to Google Ads?
No. Processing, matching and reported attribution are different stages. Also check the relevant diagnostics and reconcile the results with your business records using aligned time periods and business definitions. Import evidence initially confirms the corresponding technical handover.
Is having no warnings a good sign when conversion volume is low?
It is not enough for acceptance. Diagnostic messages can be limited at low volumes. Use controlled positive and negative test cases and document the observations that are still missing. This does not create a general restriction on activating the feature in small accounts.
Were all existing Google Ads API uploads stopped in June 2026?
No. The current restriction distinguishes between developer tokens according to their previous use or eligibility. Check the actual integration with its provider. New upload methods must meet current requirements; old examples do not establish permission.
Do more reported conversions automatically mean more revenue?
No. Improved matching can make existing business outcomes more visible. Compare business events, transmissions and advertising reports separately. Additional business impact cannot be inferred from improved measurement alone.
18. Keep the measurement chain traceable in day-to-day operation
Enhanced Conversions are reliably implemented when you can explain and verify the connection between the website, identifiers used with the necessary permission and relevant business outcomes. The acceptance checklist keeps that connection visible. It brings together the required evidence without equating technical processing with business success.
Compare the next change with the last test case
Keep a redacted reference case together with its configuration version. When a form, consent flow or CRM integration changes later, you can retest the affected handovers specifically. Troubleshooting then starts with a traceable change, rather than a vague suspicion about the entire account.
The practical next step is manageable: choose one conversion action, complete the six handover points and mark missing evidence as open. Resolve blocking questions first, then run the controlled test cases and assess the observable results. Expand the scope only on that basis.
If you would like to review the connection between Google Ads, your website and your business data together, SaleStudia can help with planning, implementation and quality assurance. Explore our Google Ads management with conversion tracking and bring the unresolved items from your acceptance checklist.