How to Implement Google Ads Enhanced Conversions

Start with the existing Google Ads purchase conversion action. Record its conversion ID, label, counting method, value source, currency behavior, attribution setting, owner, firing condition, and current validation evidence. Enhanced conversions supplement that tag; they do not repair duplicate purchases, missing values, incorrect currencies, or a conversion that fires before the order is accepted. Reconcile a small set of completed test orders to the base conversion before adding user-provided data. Hold the enhancement if the underlying action cannot reproduce order IDs, values, and currencies consistently.

Write an approved data contract for every field considered. Google describes email address, name, home address, and phone number as possible first-party inputs that are hashed before matching. That description is not blanket permission to collect or transmit every available field. Confirm the lawful basis, consent behavior, customer-data terms, regional requirements, retention expectations, and who can change the implementation. Exclude sensitive or unrelated form data. Document whether checkout, account, or server code provides each field and what happens when a customer declines consent or leaves it blank.

Google documents Google Tag Manager, the Google tag, and the Google Ads API as implementation paths. Select the path already responsible for the base conversion unless a reviewed migration is part of the work. Map the conversion action to a single source of truth and prevent a platform app, theme script, tag manager container, and server integration from sending competing versions. Record the exact container or release, variable names, field origins, normalization rules, consent checks, and rollback. A second path may be useful later, but it should not be enabled casually during initial validation.

For a Google tag implementation, follow the current account and conversion settings, accept the required customer-data terms through an authorized owner, and configure user-provided data only where the purchase is final. Google states that the implementation uses SHA256 for first-party customer data. Do not log raw customer fields, hashed values, or tag payloads in broadly accessible debugging systems. Avoid selectors that depend on temporary styling classes. Prefer stable application values, and test guest, signed-in, accelerated, and alternative-payment checkouts because the same customer field may appear at different points or not at all.

Create a safe test matrix covering desktop and phone, guest and signed-in checkout, each supported payment path, consent granted and denied, complete and missing optional identity fields, validation errors, order retries, and duplicate confirmation-page visits. Use clearly tagged non-prospect orders and prevent fulfillment or customer communication. In Tag Assistant, verify that the base purchase fires once at the accepted order boundary and that enhanced fields are present only when approved and available. Compare the conversion action, value, currency, transaction ID, and consent state with the test-order record.

A browser success signal is necessary but not sufficient. Google notes that empty user-provided fields, selectors that fail on some browsers, and fields collected on a different page can prevent enhanced data from being usable. Inspect the diagnostics after processing time, and distinguish tag firing from data quality. Do not paste customer information into screenshots or tickets. Store the test case ID, expected field presence, redacted Tag Assistant result, browser, device, release, and time. Repair deterministic mapping defects and repeat the smallest failing variation before expanding the test matrix.

After release, monitor the conversion action status, enhanced-conversion diagnostics, base conversion volume, value and currency quality, duplicate rate, consent distribution, and checkout error rate. Google says processing and training can take time before enhanced-conversion impact appears. Treat that delay as a measurement state, not as proof of failure or success. Do not compare partial post-release days with complete historical periods. Separate changes in observed conversions from changes in orders, media spend, channel mix, attribution, consent, or checkout behavior.

Maintain an owner, review cadence, and rollback for every tag change. Re-run the safe matrix after checkout, consent-banner, theme, payment, tag-manager, or conversion-action changes. Reconcile Google Ads conversion evidence to governed order records using aggregate or redacted data. If diagnostics degrade, identify whether fields are absent, consent is blocking them, the base tag changed, selectors broke, or a second integration is competing. Enhanced conversions can improve measurement coverage, but the implementation does not prove incremental sales, ranking gains, or causal advertising performance. Report only the evidence actually shown in the account.

Keep a release register with the conversion action, responsible tag, approved fields, consent configuration, deployment identifier, test cases, diagnostic status, and review date. Sample a small number of redacted conversions after material releases and reconcile them to accepted orders without retaining customer values in the audit. Define an incident threshold for missing enhanced fields, unexpected volume changes, duplicate purchase events, or a status that remains unresolved after the documented processing window. Pause bidding decisions that depend on suspect data until the base conversion and enhanced layer are separated and verified. This operating record lets another reviewer reproduce the measurement state without relying on a remembered checkout configuration.