Enhanced conversions for leads: what it recovers and what it can't
It rejoins a lead to the click that produced it — for people who handed over their details. For everyone else it does nothing, which is not a tracking fix.
On this page
- The identifier is hashed in the browser, and Google matches it to a signed-in account
- Consent isn't a footnote here, because the thing being sent is personal data
- It doesn't recover the people who never identified themselves
- Whole categories of lead generation aren't allowed to use it
- Since 15 June 2026 the upload path is Data Manager, with an allowlist for existing senders
- What to settle before you build it
Short answer: enhanced conversions for leads recovers attribution for people who gave you their email or phone number, by hashing that identifier and matching it against signed-in Google Accounts. It recovers nothing for anyone who didn't hand over details, and nothing for anyone whose consent state says you can't send their data. So it improves the accuracy of conversions you were already partly measuring. It does not replace a tag that isn't firing, and it is not a route around a denied consent state — the people it can help are, by definition, the ones you already have a relationship with.
That distinction decides whether it's worth building. Below is what actually moves across the wire, what Google's own policies forbid, and what changed in the upload path in June.
The identifier is hashed in the browser, and Google matches it to a signed-in account
The mechanism is narrower than the marketing around it suggests. Google's help documentation describes it as an upgraded offline conversion import that uses user-provided data — an email address, typically — "to supplement imported offline conversion data" (Google Ads Help, checked 8 September 2026). The hashing algorithm is named: SHA-256, applied to the first-party data before it leaves the page, with the resulting hash compared against the hashed data of signed-in Google Accounts.
The Data Manager API reference is more precise about the format. Email addresses and phone numbers must be hashed with SHA-256 after normalisation, address matching requires given name, family name, region code and postal code, and a single event carries at most ten identifiers. Normalisation is the part teams get wrong: two systems that disagree about trimming whitespace or lower-casing produce two different hashes for the same person, and a non-matching hash fails silently.
Three collection methods exist in Tag Manager, and they are not equivalent:
| Method | What it does | The risk |
|---|---|---|
| Automatic detection | "Inspects the page for strings matching configured data types" | Picks up whatever looks like an email on the page, including one that isn't the lead's |
| CSS selectors / JS variables | You name the element or variable holding the value | Breaks quietly when the front end changes |
| Code snippet | You pass the value deliberately, and Google says code-snippet data is always prioritised | Requires a developer, and is the only one that knows which person it's describing |
There's a fourth wrinkle worth knowing before anyone signs off the design. If you use the user-provided data event tag — the variant that collects details from a page before the conversion page — Google's own documentation says you authorise it to use an ads cookie to collect that hashed data on your behalf and connect it to a later conversion in the same session, and that "all data that isn't connected to a conversion is deleted". That cookie is subject to the ad_storage consent state where Consent Mode is implemented. So the earlier-page variant introduces a storage dependency the on-page variant doesn't have.
Consent isn't a footnote here, because the thing being sent is personal data
The signal that governs this is ad_user_data, which Google's gtag reference defines in one line: it "sets consent for sending user data to Google for advertising purposes". A hashed email being sent to Google for matching is exactly that. If the state is denied, the identifier shouldn't go.
Hashing doesn't get you out of the question, and it's worth being blunt about why, because "it's hashed" is the most common answer to a consent objection in this space. The ICO's position on pseudonymisation is that it "is effectively only a security measure. It does not change the status of the data as personal data" — Recital 26 puts pseudonymised data squarely inside UK GDPR (ICO guidance, checked 8 September 2026). A SHA-256 digest that Google can match to an identified account holder is doing the job of an identifier, which is the whole point of sending it.
Google's own contracts say the same thing in commercial language. The customer data policies that govern enhanced conversions require you to disclose that you share customer information with third parties for ad measurement, to "obtain customer consent for such sharing and use where legally required", and to comply with the EU user consent policy for users in the EEA, the UK and Switzerland. Failure has a stated consequence in that policy: Google may limit or suspend your use of the product.
The practical version: your consent record has to be per-person and it has to reach the point of upload. Consent captured at the banner and then lost before the CRM is the same as no consent, because you can't demonstrate it against the row you're sending. If you're still deciding how the signal reaches Google in the first place, that choice is Basic versus Advanced Consent Mode, and it sits upstream of everything here.
It doesn't recover the people who never identified themselves
Here's the arithmetic that stops most disappointment. Enhanced conversions for leads works on a population that has already done two things: clicked your ad, and given you a contact detail. Everyone else is untouched by it.
That rules out three failure modes people expect it to fix:
- A tag that isn't firing. If the conversion event never reaches Google, there is no conversion for a hashed identifier to be attached to. The identifier supplements an imported conversion; it doesn't create one.
- A denied consent state. Where the user declined, the correct behaviour is not to send the identifier. A system that sends it anyway isn't recovering data — it's ignoring the answer it was given.
- Anonymous traffic. People who browsed, converted nowhere and left are outside the mechanism entirely. Nothing about hashing reaches them.
Match rate is the number everyone asks for, and it's the number nobody has. Google publishes no match-rate benchmark for enhanced conversions for leads, and we haven't found an independent study that measures one; the closest the product gives you is the diagnostics report and the impact results in the conversion action table, which the help documentation says appear about 30 days after a successful implementation. Anyone quoting you a percentage recovery for your account before you've run it is quoting a figure that has no published source.
Whole categories of lead generation aren't allowed to use it
This is the part that gets discovered late, usually after the build. Google's customer data policies state that conversions related to sensitive categories "can't be used for measurement in enhanced conversions, or shop sales (uploads)". The list is specific, and it covers a lot of what the UK lead-generation market consists of:
- health or medical information, including purchases of medical services, prescription drugs or medical devices
- negative financial status or situation, such as a low credit rating or high debt load
- the commission or alleged commission of any crime
- sexual behaviour or orientation, racial or ethnic information, political affiliation, religion, trade union membership
- divorce, and status as a child under 13
A private clinic, a debt advice service, a criminal defence solicitor: each of them has a lead pipeline that would benefit from better attribution, and each of them is looking at a conversion action that Google's policy says can't carry this. Read the sensitive-categories list before you scope the work, not after. Where it applies, the honest answer is that this feature isn't available to you and the attribution gap has to be closed another way.
Before enabling this, check what your site is currently telling Google about consent. Our Google Ads consent checker loads your domain in a real browser, detects your AW- and GTM- IDs, and reports whether ad_user_data and ad_personalization are actually being signalled — the two states an upload is supposed to reflect.
Since 15 June 2026 the upload path is Data Manager, with an allowlist for existing senders
The plumbing moved this year, and the detail matters more than the headline. Google's help page for enhanced conversions for leads states that from 15 June 2026, offline conversion import and enhanced-conversions-for-leads uploads are migrated to the Data Manager API and blocked in the Google Ads API, and that developer tokens which sent no request between January and June 2026 will not be allowlisted for legacy access.
The Google Ads API documentation puts the same rule from the other side, and it's the more useful phrasing for anyone inheriting an account: from 15 June 2026, UploadClickConversion requests fail "if the developer token hasn't previously sent requests to upload offline conversions or enhanced conversions for leads". So this is not a universal switch-off. A pipeline that was already running on a qualifying token keeps working; a new integration on a fresh token has no legacy path at all and routes through Data Manager instead. If you're auditing an account, the question to ask is which token it uses and whether that token was active in the qualifying window.
One more change is in flight. Google's documentation carries a notice that enhanced conversions for web and leads are being combined into a single on/off setting, with Google Ads accepting user-provided data from website tags, Data Manager and API connections simultaneously from April 2026, and existing users migrated automatically. Until that is fully rolled out, the older warning still applies on the setup pages: data sent by a method other than the one selected in the interface may not be processed. Check which method your account has selected before assuming an API upload is landing.
The relationship between this feature and plain offline conversion import — which one changes your bidding, and which one only changes attribution — is a separate decision, covered in enhanced conversions versus offline import.
What to settle before you build it
- Decide where the value comes from. A code snippet that passes the lead's own email deliberately beats automatic detection scraping the page, and it's the only method that knows whose address it captured.
- Fix normalisation once, centrally. The same function should hash on the website and in the upload, or the two hashes won't meet.
- Store consent against the lead record, not just in the banner's own log, so the state travels with the row you upload.
- Check the sensitive-categories list against the conversion action you're measuring, before development starts.
- Keep importing GCLIDs. Google's guidance is to include them wherever possible; the hashed identifier supplements deterministic matching rather than replacing it.
- Reconcile against closed business. The diagnostics report tells you the upload was accepted. It doesn't tell you the leads were real.
Enhanced conversions for leads is a good mechanism aimed at a narrow problem: the click identifier went missing but the person left their details. Treated that way, it earns its place. Treated as a repair for consent or for a broken tag, it produces a modest lift in reported conversions and a quiet increase in the amount of personal data you're sending to a third party — which is the trade nobody writes down.
If your reported conversions and your actual pipeline stopped agreeing some time ago, working out where the chain breaks is what we do. The wider question of what counts as first-party data in the first place is the definition most vendors skip.
Sources
- 1.Google Ads Help — About enhanced conversions for leads · Checked 2026-09-08
- 2.Google Ads Help — Set up enhanced conversions for web using Google Tag Manager · Checked 2026-09-08
- 3.Google Ads Help — Set up enhanced conversions for web using the Google tag (SHA256) · Checked 2026-09-08
- 4.Google Advertising Policies — Customer data policies · Checked 2026-09-08
- 5.Google — Data Manager API, UserData reference (SHA-256 after normalisation, max 10 identifiers) · Checked 2026-09-08
- 6.Google Ads API — Import offline conversions (UploadClickConversion warning, 15 June 2026) · Checked 2026-09-08
- 7.Google — gtag.js consent reference (ad_user_data, ad_storage) · Checked 2026-09-08
- 8.Google — EU user consent policy · Checked 2026-09-08
- 9.ICO — What is personal data? (pseudonymisation is only a security measure) · Checked 2026-09-08