Google Ads Enhanced Conversions Checklist

Use this Google Ads enhanced conversions checklist in four passes: define the business outcome, confirm the implementation and consent path, test one conversion without duplication, and reconcile Google Ads with the source system. The checklist is complete only when the enhanced signal improves a meaningful conversion action and the team can explain what happened when a count changes.

Enhanced conversions add hashed first-party data to an existing measurement path. They do not replace the conversion tag, fix a weak goal, or make raw customer data safe to collect without consent. Google’s Enhanced Conversions Best Practices is the primary technical reference. Tick each item with evidence, not just a green toggle in the interface.

Pass 1: Define the conversion outcome

Before touching Google Ads, write down the action that should guide bidding and the action owner. A purchase, qualified application, paid subscription, or completed consultation is usually more useful than a page view or a form start. Record whether the action is primary or secondary, how it counts repeated events, what value and currency it carries, and how long after an ad interaction it may be credited.

Compare the definition with the account’s existing conversion tracking settings. If a campaign already optimizes toward an incorrect or duplicate action, fix that design first. An enhanced signal makes the selected action more observable; it does not change what the action means.

Pass 2: Prepare the implementation

Conversion-source checklist

[ ] The account’s selected enhanced-conversion method matches the system that owns the event: Google tag, Google Tag Manager, API, or the current account configuration.
[ ] The conversion action, event name, source, and destination are documented.
[ ] A web conversion fires only after a successful action, not on a page view, form start, or button press that can happen without completion.
[ ] A lead-stage import has a stable relationship to the original online lead.
[ ] The team has recorded whether an event is an original conversion, adjustment, or later reporting stage.

If the action is sent through an API, check Google’s enhanced conversions API documentation for the current requirements. Do not let a browser tag and server integration become two undocumented owners.

First-party-data checklist

[ ] The field is collected at the conversion and is first-party data supplied by the customer or held by the business lawfully.
[ ] The implementation follows Google’s current normalization and hashing instructions for the selected method.
[ ] Raw email addresses, phone numbers, names, and addresses are absent from URLs, screenshots, console output, and shared logs.
[ ] Empty, placeholder, malformed, and test values are handled deliberately.
[ ] The event carries the value, currency, transaction ID, and timestamp needed for the business model.

Use the smallest useful field set. Sending more fields is not automatically a better setup, especially when the extra field is optional, inaccurate, or not covered by the site’s consent decision.

Consent checklist

[ ] The consent management platform and advertising tag agree on the current consent state.
[ ] A granted state sends the permitted enhanced data through the intended path.
[ ] A denied state does not send prohibited user-provided data.
[ ] A visitor who has not answered is tested separately from a denial.
[ ] The EEA and UK path has been reviewed against the site’s legal and privacy requirements.

Google recommends a strong consent framework for enhanced conversions in the EEA and UK. Hashing is a technical protection; it is not a substitute for consent or a legal basis.

Pass 3: Prevent duplicates and run tests

Deduplication checklist

[ ] An ecommerce order keeps one stable transaction ID through refreshes, payment retries, browser back navigation, and server callbacks.
[ ] A lead form submission and a later CRM qualification have different, documented roles rather than two primary conversion records.
[ ] Direct tags and Tag Manager triggers cannot both fire the same action unintentionally.
[ ] Server retries are idempotent and preserve the original event identifier.
[ ] A test order or lead can be traced from the source system to Google Ads.

Run a controlled test with a test account or a clearly labelled internal conversion where the production workflow allows it. Inspect the trigger and network behavior without retaining raw personal data in the test record.

Diagnostics checklist

[ ] The conversion action receives the event in the expected account.
[ ] Google Ads shows the current enhanced-conversion status or diagnostic result for that action.
[ ] Any warning is classified as missing data, policy/consent, formatting, method mismatch, processing delay, or duplicate behavior.
[ ] The source-system count, Google Ads count, date definition, and timezone are compared on the same basis.
[ ] The test result is saved with a timestamp, action name, identifier, and owner, but no raw customer data.

A tag preview can prove that code ran; it cannot prove that Google accepted the event, attributed it, or used it in bidding. Keep those checks separate.

Pass 4: Approve the release and monitor it

Before publishing, record the expected result and rollback plan. Do not combine an enhanced-conversion release with a new bid strategy, a consent-banner rewrite, a checkout migration, and a landing-page redesign if you want to know which change affected reporting.

For the first review cycle, compare:

Google Ads conversions and value by action.
Orders, leads, qualified opportunities, or paid subscriptions in the source system.
Duplicate identifiers, rejected uploads, and delayed records.
Business-quality measures such as qualified rate, revenue, refunds, or sales acceptance.
The primary/secondary status and campaign bidding goal.

Allow for the normal conversion lag before judging a change. A one-day increase can be a retry or late report, and a one-day decrease can be a consent or upload delay. Review the full cycle, annotate the launch date, and keep a note of any account-level UI changes because Google is consolidating enhanced-conversion settings during 2026.

Stop conditions and handoff notes

Do not approve the setup when the action is undefined, consent is unknown, raw customer data is appearing in logs, browser and server events cannot be matched, or the source system cannot reconcile one event to one result. Leave the existing measurement path intact, document the blocker, and assign an owner.

Once every item has evidence, link the checklist to the implementation ticket and the next review date. adz.so can inspect supported account settings through its audit workflow, but it does not install tags, configure consent, or repair a CRM pipeline. For the surrounding design, use the enhanced conversions setup guide and Google’s current documentation.

Research note: reviewed against Google Ads Help enhanced-conversion best practices, account-level guidance, and API documentation on 2026-08-03. Verify current UI labels and policy requirements before a production release.