Enhanced Conversions Setup: The 70% Match Rate Target (2026)

What is Enhanced Conversions?

Enhanced Conversions extends standard Google Ads conversion tracking by passing hashed user data (email, phone, name, address) alongside each conversion. Google's servers compare the hashes against logged-in Google account data to match cross-device journeys, recover conversions otherwise lost to consent or cookie restrictions, and improve Smart Bidding signal quality.

The benchmark for a healthy implementation is 70%+ match rate in the Google Ads admin — below 60% indicates broken hashing, missing fields, or consent gating issues. Setup requires SHA-256 hashing of normalised inputs (lowercase, trimmed) before transmission — the most common implementation failure is sending unhashed data, which Google rejects entirely.

What Enhanced Conversions actually does

The mechanic:

1. User makes a conversion (purchase, signup, lead form)
2. Your site captures their email, phone, name, address — fields they entered during checkout/signup
3. Your client-side or server-side code SHA-256 hashes these fields after lowercasing and trimming
4. The hashed values are passed to Google Ads alongside the conversion event
5. Google matches the hash against logged-in Google account data
6. If a match is found, the conversion is attributed even when standard cookie/click-ID linkage failed

The key benefits:

• Cross-device matching — a user who clicked the ad on mobile and converted on desktop links up
• Cookie-restriction recovery — conversions from Safari (where standard cookies expire in 7 days) get matched
• Consent-resistant attribution — even when ad_storage=denied, hashed user data passed via ad_user_data=granted still enables matching
• Smart Bidding improvement — the algorithm sees more conversions with full attribution chains

Real-world impact: 5–15% increase in attributed Google Ads conversions on properties with proper Enhanced Conversions implementation. The lift comes from conversions Google was missing under standard tracking.

The three implementation methods

Method 1 — Google Ads conversion tag (gtag-based)

Available for properties using gtag.js for Google Ads conversion tracking. Add user-provided data to the conversion event:

gtag handles the hashing automatically when you pass raw values to the user_data field. Lowercase + trim is also handled. This is the easiest method for properties already using gtag.

Method 2 — GTM (manual hashing required)

For GTM-based implementations, configure user-provided data variables and pass them to the Google Ads Conversion Tag:

1. Create variables for each user data field (email, phone, etc.)
2. In the Google Ads Conversion Tag, expand the User-provided data section
3. Map your variables to the appropriate fields

GTM hashes the values before sending — same as gtag. The implementation difference is that you're configuring the data flow in the GTM UI rather than in code.

Method 3 — Google Ads API (offline)

For server-side or backend-driven conversions, use the Google Ads API:

API method requires you to do the hashing yourself. SHA-256 of the lowercased and trimmed value, output as a 64-character hex string.

The hashing requirements

Critical: Google rejects unhashed data outright. The exact spec:

Normalisation rules

Before hashing each field:

• Email: trim whitespace, lowercase entirely
• Phone: trim whitespace, remove all formatting except + (no spaces, no dashes, no parentheses), prefix with country code
• Name: trim whitespace, lowercase, no titles (Mr/Mrs/Dr)
• Address: trim whitespace, lowercase, expand abbreviations where practical
• Postal code: trim whitespace, lowercase (UK postcodes), uppercase (some other formats)
• Country: ISO 3166-1 alpha-2 code, uppercase (GB, US, DE)

Hash format

SHA-256, output as 64-character hex string. NOT base64. NOT truncated.

The most common implementation bug: forgetting to normalise before hashing. 'User@Example.com' and 'user@example.com' produce different hashes — Google's matching only works on exact hash equality, so casing matters.

Verifying your hashes

Test the hash output for a known string:

If your code produces something different for that input, your normalisation is wrong. Google rejects mis-normalised hashes silently — the data appears to upload successfully but matches fail.

The 70% match rate target

In Google Ads → Tools → Conversions → click on your conversion action → check the "Diagnostic" or "Recent Diagnostic" section. The match rate is shown as a percentage.

Benchmarks:

• Below 50% — broken implementation. Either fields aren't being captured, hashing is wrong, or consent is blocking the data.
• 50–69% — partial implementation. Missing one or more important fields (often phone number).
• 70–84% — healthy. Most properties with full implementation land here.
• 85%+ — exceptional. Usually requires consistent multi-field collection (email + phone + name) and high consent acceptance.

If match rate is below 70% after implementation:

1. Check fields are populated — empty strings count as "data missing"
2. Verify hash format — 64-char hex, no extra characters
3. Check normalisation — lowercase, trim, country code on phones
4. Verify consent — ad_user_data=granted is required; with V1 consent (no ad_user_data signal), Enhanced Conversions can't work
5. Wait 30 days — match rate stabilises after data accumulates

Stacking with Consent Mode V2

Enhanced Conversions and Consent Mode V2 work together but each has independent requirements:

• Consent Mode V2 controls whether the conversion is sent at all (cookieless ping vs full conversion)
• Enhanced Conversions adds user data to whatever conversion is sent

When ad_user_data=denied, Enhanced Conversions data should NOT be sent — Google's terms require respecting the consent state. The implementation must check consent before passing user data.

In gtag and GTM, this happens automatically — Enhanced Conversions data is gated on ad_user_data=granted.

In API-based implementations, you must check the consent state yourself. Don't pass hashed user data for users who denied ad_user_data consent.

Stacking with offline conversion import

Enhanced Conversions can be combined with offline conversion import (covered in the next post):

• Online conversion + Enhanced Conversions — captures the conversion at the point of action with user data
• Offline conversion import — uploads conversions that happened offline (sales call closes, in-store purchases) with the gclid and optional Enhanced data

The combination provides the most complete attribution picture: online conversions matched cross-device via Enhanced Conversions, offline conversions matched via gclid + Enhanced data.