Google Ads Enhanced Conversions, explained (and how not to leak PII doing it)

Enhanced Conversions attach hashed first-party data — email, phone, name, address — to your Google Ads conversions so Google can match them to signed-in users when cookies cannot. It typically recovers a meaningful share of conversions that would otherwise go unattributed, and it is one of the highest-return tracking changes available right now. It is also the easiest place to leak personal data if you wire it up carelessly.

What it actually does

A normal conversion relies on a click identifier or cookie surviving from ad click to conversion. Increasingly it does not: cookies expire, are blocked, are partitioned, or the conversion happens on another device.

Enhanced Conversions add a second matching route. When someone converts, you send hashed customer data alongside the conversion. Google hashes the identifiers it holds for signed-in users the same way and looks for a match. Matches recover conversions that cookie-based tracking lost.

Three things are true and worth stating together: the data is hashed with SHA-256 before it leaves the browser or your server, Google never receives the raw values from you, and this is still personal data processing that requires a lawful basis and appropriate disclosure.

The two variants

Enhanced Conversions for web improve measurement of conversions that happen on your site. You send hashed identifiers with the conversion event itself.

Enhanced Conversions for leads close the loop for offline outcomes. A visitor submits a form; weeks later that lead becomes a customer in your CRM; you upload the outcome keyed on the same hashed identifier. This is how lead-gen businesses get Smart Bidding to optimise for closed revenue rather than form fills — see offline conversion imports.

	Enhanced Conversions for web	For leads
Fires when	Conversion happens on site	Outcome happens in CRM
Keyed on	Hashed identifiers at conversion	Hashed identifiers from the form
Improves	Attribution of online conversions	Bidding toward real revenue
Needs	Tag or API implementation	CRM upload pipeline

Implementation paths

Google Tag / gtag

Provide the identifiers to the tag and let it hash them before sending. Simplest path, and the one most sites use.

Google Tag Manager

Configure the conversion tag to read user-provided data — either from specific page elements, or, far more reliably, from variables you populate from a dataLayer push. Automatic collection by CSS selector works until a redesign moves the field.

The API path

Send hashed conversions server-side. Most robust, because it fires from your system of record rather than depending on a confirmation page rendering. This is the Data Manager route described in server-side conversion tracking.

Normalisation: the part that decides whether it works

Hashing is only useful if both sides hash the same string. Get normalisation wrong and every hash is unique noise — the implementation reports success and matches nothing.

• Email: lowercase, trim whitespace. For gmail.com addresses, Google also ignores dots in the local part.
• Phone: E.164 format — a plus sign, country code, digits, nothing else. No spaces, no dashes, no parentheses.
• Name: lowercase, trim, no punctuation.
• Address: lowercase, trim; street, city, region, postcode, and country as separate fields.
• Then SHA-256, hex encoded.

If you use the gtag or GTM path with raw values, Google's tag handles normalisation and hashing in the browser. If you hash yourself, you own every one of these rules.

The PII trap

This is where implementations go wrong in a way that matters legally rather than just technically.

Never send raw personal data to GA4. Enhanced Conversions are a Google Ads feature. It is entirely possible to wire up a dataLayer that exposes an email address to every tag in your container, including GA4 — and GA4's terms prohibit storing personal data. Google can and does delete data for this.

Practical rules:

• Keep user-provided data in variables consumed only by the Ads conversion tag.
• Never put an email address in a URL query string. It leaks to every vendor on the page as the page location, and it is a hard failure on any audit. Keeping PII out of GA4 covers cleanup.
• If you hash server-side, hash before the value crosses any boundary — not in the same payload as the raw value "for debugging".
• Confirm your privacy policy discloses the sharing, and that your consent flow covers it.

Consent

Enhanced Conversions are advertising data. For EEA and UK users, they require ad_user_data and ad_personalization consent, and should not be sent when those are denied.

A correctly configured Consent Mode v2 setup handles this — but "correctly configured" is doing real work in that sentence. Verify that a denied state actually prevents the enhanced payload, rather than only preventing the cookie.

Verifying it works

1. Check the diagnostics. Google Ads reports Enhanced Conversions status per conversion action, including whether it is receiving data and whether the data is usable. Warnings there are the fastest feedback available.
2. Inspect the network request. With the browser tag, confirm the payload contains hashed values — long hex strings — and no plaintext email addresses anywhere.
3. Watch the recovery rate. Google reports additional conversions attributed via enhanced matching. If it is zero after a week of volume, normalisation is almost certainly wrong.
4. Test the consent path. Deny consent, convert, confirm nothing is sent.

FAQ

Do Enhanced Conversions send personal data to Google?

They send SHA-256 hashes of normalised identifiers, not raw values. It is still personal data processing under most privacy regimes, so disclosure and lawful basis still apply — but Google does not receive plaintext from you.

Will Enhanced Conversions increase my reported conversions?

Usually yes, by recovering conversions that cookie-based attribution missed. The uplift varies by industry, device mix, and how many of your customers are signed in to Google.

Do I need Enhanced Conversions if I already run server-side tagging?

They solve different problems and complement each other. Server-side improves delivery and cookie durability; Enhanced Conversions improve matching. Most mature setups run both.

What is the most common reason Enhanced Conversions do not work?

Normalisation. An email with stray whitespace or a phone number with dashes hashes to something Google cannot match, and the implementation looks healthy while matching nothing.

Can I use Enhanced Conversions with a consent banner?

Yes, and you should gate them on ad_user_data and ad_personalization. Verify the denied path actually suppresses the payload rather than just the cookie.

Make sure the basics are in place first — the free tracking audit checks for a Google Ads conversion tag, consent signals, and PII exposed in your URLs.