Google Ads enhanced conversions: what they do and how to set them up
Enhanced conversions are a small amount of configuration sitting on top of the conversion tag that is already there. The feature is widely half-finished: switched on in the account, never wired to any actual customer data on the page. This covers what it sends, the two variants, the setup routes, and how to read the diagnostics.
What enhanced conversions actually are
A Google Ads conversion tag normally identifies the click behind a conversion through a cookie holding the GCLID. When that cookie is missing, expired or never written, the conversion still gets counted but Google cannot connect it to the click that produced it. Attribution drops out, and the campaign that earned the sale shows nothing.
Enhanced conversions add a second route to that connection. First-party customer data the advertiser already holds — email address, phone number, name, postal address — is hashed with SHA-256 in the browser and sent along with the conversion. Google hashes the details on its own signed-in accounts the same way and compares the two. Where a hash matches an account that clicked an ad, the conversion is attributed to that click.
It is worth being precise about the boundary, because this is where the feature 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 that is blocked before it fires. The same request goes to the same endpoint carrying more identifiers than it did before.
The feature exists on Google Ads conversion actions, with the equivalent available on Floodlight activities in Search Ads 360 and Campaign Manager 360.
Enhanced conversions for web and enhanced conversions for leads
The two variants solve different problems and are configured separately, which is a frequent source of confusion when an account has both switched on.
Enhanced conversions for web apply where the conversion completes online. Customer data is read at the moment of conversion, on the confirmation page or at the form submission, and travels with the conversion ping. Matching happens there and then, against accounts signed in to Google. This is the variant that suits ecommerce, sign-ups, and anything else that finishes in the browser.
Enhanced conversions for leads apply where the outcome arrives later, from a CRM. The hashed email or phone number is captured when the lead form is submitted and sent with the lead conversion. Weeks later, when the lead becomes a customer, the closed deal is uploaded to Google Ads keyed on that same hashed identifier. Google joins the upload back to the original lead event, and through it to the click.
The significance of the leads variant is what it removes. Classic offline conversion import requires the GCLID to be captured in a hidden form field, written into the CRM, kept intact through every integration between the form and the sales pipeline, and returned in the upload. Every step is a place it gets lost. Matching on a hashed email removes the dependency on a value nobody in the sales team understands or protects.
Lead generation businesses generally want both: the web variant on the form submission, the leads variant on the qualified or closed outcome.
What gets hashed, and what Google receives
The accepted fields are email address, phone number, first name, last name, street address, city, region, postcode and country. Email is the strongest single signal and the one most implementations stop at. Phone number is a useful second where the business captures it reliably.
Email, phone, names and street address are hashed. City, region, postcode and country are sent unhashed, since none of them identifies a person on its own and they only serve to disambiguate a name match.
Normalisation matters more than it sounds. Before hashing, values are trimmed of surrounding whitespace and lowercased, and phone numbers are converted to E.164 format with the country code and no punctuation. A hash of " [email protected] " and a hash of "[email protected]" are unrelated strings, so a normalisation mistake produces a well-formed request that matches nothing. The Google tag and Google Tag Manager handle normalisation and hashing automatically. Implementations that pre-hash the values in application code are the ones that get this wrong, and the failure is silent.
What leaves the browser is a set of 64-character hexadecimal digests. Google cannot reverse them, the comparison is hash against hash, and Google's documentation states that data which does not match is discarded. None of it surfaces in reporting; there is no view anywhere that shows which individual matched.
Setting it up through Google Tag Manager
This is the route I take by default, because 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 on the site will work 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 for likely user data, and manual configuration reads specified CSS selectors, both of which break quietly the next time a developer changes a template. The same discipline that goes into GA4 event design applies here: agree the fields, push them deliberately.
3. Build a user-provided data variable
Variables, new, user-provided data. Choose manual configuration and map each field to its data layer variable, or choose automatic collection if the page cannot be changed. One variable can serve 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 that should carry it.
5. Check the variable resolves before publishing
In preview mode, the variable must show real values on the event that fires the conversion tag. The common failure is a timing one: the conversion tag fires on a page view while the email arrives in a later data layer push, so the variable evaluates to undefined and the request goes out with nothing attached.
Setting it up with the Google tag, and through a server container
Where a site runs gtag.js directly with no container, the same feature is available by setting the method to Google tag on the conversion action. Automatic collection can then be enabled from the tag settings without touching the code. For explicit control, a gtag set call for user_data before the conversion event, or the user data passed as parameters on the event itself, gives the same result with the fields chosen deliberately. Values that have already been hashed by the application are accepted under the sha256-prefixed keys, provided they were normalised first.
A server container changes where the work happens. The web container or Google tag passes the customer data into the server container with the event, and the Google Ads conversion tracking tag there forwards it on. If the data arrives unhashed over the connection, the server-side tag hashes it before it goes to Google, which puts normalisation in one place under the implementer's control, not spread across whatever each front end happens to render. The server container can also read fields from the incoming request that were never in the page HTML.
That is a reason to run the two together, not a reason to treat them as the same thing. What server-side tagging changes is how the event reaches Google; enhanced conversions change what identity information it carries. 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 a UK or EEA site, customer data can only be sent to Google for advertising purposes where the visitor has consented, and in practice the gate is the ad_user_data consent signal.
Under Consent Mode in advanced implementation, tags load regardless and send cookieless pings while consent is denied. User-provided data is withheld from those pings and included once ad_user_data is granted. Under basic implementation the tags do not load at all before a decision, so a denied or ignored banner produces no conversion signal of any kind, enhanced or otherwise. Worth reading what Consent Mode sends in each state before drawing conclusions from a diagnostics figure.
The practical consequence is arithmetic. On a consented-traffic site, enhanced conversions can only ever apply to the consented share of conversions. A site where half of visitors accept marketing cookies has half its conversions eligible, and the reported effect will be roughly proportionate. Setting that expectation before switching the feature on avoids a difficult conversation afterwards.
Hashing does not discharge the data protection obligations either. The lawful basis, the privacy notice wording and the record of processing are the advertiser's responsibility, and a question for whoever advises them on data protection. 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 that simply carries nothing useful, so the check has to be deliberate.
Google Ads diagnostics
The diagnostics tab on the conversion action reports whether user data is arriving, the share of recent conversions recorded with it, and specific errors such as unhashed or malformed fields.
Preview mode
The user-provided data variable resolving to real values, on the same event that fires the conversion tag. Firing order problems show up here and nowhere else.
The network request
The outbound conversion request in developer tools should carry the user data parameters, each a 64-character hex string. A shorter value means something was passed through unhashed.
Leads upload results
Offline uploads return a match rate and a list of rows that failed. Failures usually mean the CRM holds a different address from the one entered on the form.
Two readings catch people out. A diagnostic reporting that no data was received is almost always a tag firing order or consent problem, not a hashing problem. And a high recorded percentage is not a match rate: it says the data reached Google, not that Google found an account to match it against. The web variant does not expose the second figure. Interpreting that gap alongside the rest of the setup is a large part of what goes into a tracking audit.
What changes in the reported conversion numbers
Enhanced conversions add conversions to Google Ads that were already happening but could not be tied to a click. Those conversions are credited on the date they originally occurred, so historical rows restate: a report exported last week will not tie to the same date range pulled today. Anyone maintaining a manual performance sheet needs warning about this.
The recovered conversions also feed Smart Bidding, which is the substantive reason to bother. A bid strategy blind to a segment of genuine conversions will bid down the campaigns producing them.
What does not change is longer. GA4 numbers are untouched, since the feature is a Google Ads matching mechanism and nothing about it reaches Analytics. CRM totals are untouched. No conversion is invented; every one counted actually occurred and was already recorded. A conversion tag that is not firing gains nothing, because there is no conversion to enhance.
One second-order effect is worth flagging early. Enhanced conversions widen the gap between Google Ads and GA4, which now differ on attribution model and on matching. That divergence is expected and explainable, but somebody will ask about it.
The size of the effect varies with how many conversions already had a usable click identifier, the consent rate, the proportion of customers signed in to a Google account, and whether the email captured is the one they actually use. Any specific percentage quoted without those four variables 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. Routing the calls through an endpoint on the site's own domain extends cookie lifetimes past what Safari allows a script to set, and keeps collection off the blocklists. It gets more conversions recorded, and it says nothing about who converted.
Enhanced conversions are about identity. They operate on a conversion Google has already received and improve the odds of connecting it to a click. No new infrastructure and no DNS change.
Offline conversion import handles outcomes that land later, carrying results that occur days or weeks after the click back into the account. The enhanced conversions for leads variant is the one that keys on a hashed identifier, with no stored GCLID required.
On sequencing, I would fix the conversion tag and the consent wiring first, because everything downstream depends on both. Enhanced conversions come next: for most accounts it is one variable, one checkbox and a data layer push, assuming the customer data is on the page at all. Server-side tagging is the larger commitment and earns its cost at higher spend. The order reflects effort against return, not importance.
Worth doing, variants, and the consent gate
Are enhanced conversions worth it?
For most Google Ads accounts the effort is small enough that the answer is yes: 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 currently reach Google with no usable click identifier. An account where nearly everything already matches has little left 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 finishing the action. The leads version keeps a hashed identifier from the form and waits for the sales outcome to be uploaded later, 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 to it. Under a basic implementation the tag does not load, so nothing is sent at all.