Google Ads enhanced conversions: what they do and how to set them up
Enhanced conversions are a small amount of configuration on top of the existing conversion tag, and widely half-finished: switched on in the account, never wired to any customer data. This covers what it sends, the two variants, the setup routes, and the diagnostics.
What enhanced conversions actually are
A Google Ads conversion tag identifies the click through a cookie holding the GCLID. When the cookie is missing or expired, the conversion is counted but unattributed, and the campaign that earned the sale shows nothing.
Enhanced conversions add a second route. Customer data the advertiser already holds (email, phone, name, postal address) is hashed with SHA-256 in the browser and sent with the conversion. Google hashes the same details on its signed-in accounts and compares. A match to an account that clicked an ad attributes the conversion to that click.
The boundary gets misdescribed. Enhanced conversions are a matching layer. They do not move the conversion request off the browser, and they do nothing for a tag blocked before it fires. The same request goes to the same endpoint, carrying more identifiers.
Search Ads 360 and Campaign Manager 360 have the equivalent on Floodlight activities.
Enhanced conversions for web and enhanced conversions for leads
The two variants are configured separately and solve different problems.
Enhanced conversions for web apply where the conversion completes online. Data is read on the confirmation page or form submission, travels with the ping, and matches immediately against signed-in Google accounts. Suits ecommerce, sign-ups, anything that finishes in the browser.
Enhanced conversions for leads apply where the outcome arrives later, from a CRM. A hashed email or phone number is captured at the form submission; the closed deal is later uploaded keyed on the same hash, and Google joins it back to the lead event and the click.
The leads variant removes a dependency. Classic offline conversion import needs the GCLID to survive four steps:
- captured in a hidden form field
- written into the CRM
- kept intact through every integration on the way to the sales pipeline
- returned in the upload
Every step is a place it gets lost. A hashed email replaces a value nobody in the sales team protects.
Lead generation businesses generally want both: web on the form submission, leads on the closed outcome.
What gets hashed, and what Google receives
Nine fields are accepted. Email is the strongest single signal and where most implementations stop. Phone number is a useful second where captured reliably.
- Hashed: email address, phone number, first name, last name, street address.
- Sent unhashed: city, region, postcode, country. None identifies a person on its own; they only disambiguate a name match.
Normalisation matters more than it sounds. Values are trimmed and lowercased before hashing; phone numbers go to E.164 with country code, no punctuation. A hash of " [email protected] " and a hash of "[email protected]" are unrelated strings: a normalisation mistake matches nothing.
The Google tag and Google Tag Manager normalise and hash automatically. Implementations that pre-hash in application code are the ones that get this wrong, and the failure is silent.
What leaves the browser is 64-character hexadecimal digests, which Google cannot reverse. It compares hash against hash and states that unmatched data is discarded. No report shows which individual matched.
Setting it up through Google Tag Manager
My default route: the mapping stays visible in the container alongside everything else.
1. Enable it on the conversion action
In Google Ads, open the conversion action, turn on enhanced conversions, accept the customer data terms, and select Google Tag Manager as the method. Nothing works until the terms are accepted at account level.
2. Get the customer data onto the page
The durable option is a data layer push on the confirmation step carrying the email and any other fields. Automatic collection scans the rendered page; manual configuration reads CSS selectors. Both break quietly when a template changes. The same discipline as GA4 event design applies: agree the fields, push them deliberately.
3. Build a user-provided data variable
Variables, new, user-provided data. Map each field to its data layer variable, or choose automatic collection if the page cannot be changed. One variable serves every conversion tag in the container.
4. Attach it to the conversion tag
Open the Google Ads conversion tracking tag, tick the option to include user-provided data, and select the variable. Repeat for each conversion action.
5. Check the variable resolves before publishing
The variable must show real values on the event that fires the conversion tag. The common failure is timing: the tag fires on a page view, the email arrives in a later push, and the request goes out empty.
Setting it up with the Google tag, and through a server container
Where a site runs gtag.js directly with no container, set the method to Google tag on the conversion action. From there:
- Automatic collection can be enabled from the tag settings, without touching the code.
- A gtag set call for user_data before the conversion event, or user data on the event itself, gives explicit control of the fields.
- Pre-hashed values are accepted under the sha256-prefixed keys if they were normalised first.
A server container changes where the work happens. Customer data passes through with the event and the Google Ads tag there forwards it on. Unhashed data is hashed server-side, putting normalisation in one place, and the container can read fields from the incoming request that were never in the page HTML.
What server-side tagging changes is how the event reaches Google, not what identity it carries. Run the two together by all means, but a server container with no user-provided data configured matches no better than a browser tag.
Consent Mode, UK and EEA rules, and enhanced conversions
Hashed personal data is still personal data, and Google's EU user consent policy treats it that way. On UK or EEA traffic, customer data only goes to Google with consent; the gate is the ad_user_data signal.
Under advanced Consent Mode, tags send cookieless pings while consent is denied; user-provided data is withheld until ad_user_data is granted. Under basic implementation the tags do not load before a decision, so nothing is sent at all. Read what Consent Mode sends in each state before interpreting a diagnostics figure.
The consequence is arithmetic. Enhanced conversions only apply to the consented share of conversions. Half of visitors accepting marketing cookies means half of conversions eligible, and a roughly proportionate reported effect. Set that expectation before switching on.
Hashing does not discharge the data protection obligations either. Lawful basis, privacy notice wording and the record of processing sit with the advertiser and their data protection adviser. The technical implementation is the part I can speak to.
Checking it works: diagnostics and match rates
Enhanced conversions fail silently. A misconfigured setup produces a valid conversion request carrying nothing useful, so the check has to be deliberate.
Google Ads diagnostics
The tab on the conversion action reports whether user data is arriving, the share of recent conversions carrying it, and errors such as unhashed or malformed fields.
Preview mode
The user-provided data variable resolving to real values on the conversion event. Firing order problems show up here and nowhere else.
The network request
The outbound request in developer tools should carry the user data parameters, each a 64-character hex string. Anything shorter went through unhashed.
Leads upload results
Offline uploads return a match rate and the failed rows. Failures usually mean the CRM holds a different address from the form.
Two readings catch people out. A diagnostic reporting no data received is almost always a firing order or consent problem, not hashing. And the recorded percentage is not a match rate: it says data reached Google, not that an account matched. The web variant does not expose the second figure.
Interpreting that gap alongside the rest of the setup is a large part of a tracking audit.
What changes in the reported conversion numbers
Enhanced conversions add conversions that were happening but could not be tied to a click, credited on the date they occurred. Historical rows restate: last week's export will not tie to the same range pulled today. Warn anyone keeping a manual performance sheet.
The recovered conversions feed Smart Bidding, the substantive reason to bother. A bid strategy blind to a segment of genuine conversions bids down the campaigns producing them.
What does not change is longer:
- GA4 numbers. This is a Google Ads matching mechanism; nothing reaches Analytics.
- CRM totals.
- What actually happened. Nothing is invented; every conversion counted occurred and was already recorded.
- A conversion tag that is not firing. There is no conversion to enhance.
One second-order effect: the Google Ads and GA4 gap widens, since the two now differ on attribution model and matching. Expected and explainable, but somebody will ask.
The size of the effect depends on four things:
- how many conversions already had a usable click identifier
- the consent rate
- the proportion of customers signed in to a Google account
- whether the email captured is the one they actually use
Any specific percentage quoted without those four is guesswork.
Where it sits against server-side tagging and offline imports
These three are routinely discussed as alternatives, and they address different failures.
- Server-side tagging deals with how the event reaches the platform. An endpoint on the site's own domain extends cookie lifetimes past Safari's limits on script-set cookies and keeps collection off the blocklists. More conversions recorded; nothing about who converted.
- Enhanced conversions are about identity. They improve the odds of connecting a conversion Google has already received to a click. No new infrastructure, no DNS change.
- Offline conversion import carries results that occur days or weeks after the click back into the account. The leads variant keys on a hashed identifier, with no stored GCLID required.
I would fix the conversion tag and the consent wiring first; everything downstream depends on both. Enhanced conversions come next: one variable, one checkbox and a data layer push for most accounts. Server-side tagging is the larger commitment and earns its cost at higher spend. The order reflects effort against return, not importance.
All three are written up separately in the same set of guides, because the decisions behind them are separate.
Worth doing, variants, and the consent gate
Are enhanced conversions worth it?
For most Google Ads accounts, yes: the effort is one variable, one setting on the conversion action, and a push of the customer data if it is not already on the page. The return scales with how many conversions reach Google without a usable click identifier. An account where nearly everything already matches has little to gain.
What is the difference between enhanced conversions for leads and for web?
Timing, mostly. The web version matches while the visitor is still in the browser. The leads version keeps a hashed identifier from the form and waits for the sales outcome to be uploaded, which is how a deal closed weeks afterwards gets credited to the original click.
Do enhanced conversions require consent?
On UK and EEA traffic, yes. Hashing does not stop customer details being personal data, and Google gates them behind the ad_user_data signal. Where that signal is denied under an advanced implementation, the conversion request still goes out with no user data attached. Under a basic implementation the tag does not load, so nothing is sent at all.