Enhanced Conversions

Enhanced conversions is a Google Ads feature that supplements ordinary conversion tracking with hashed first-party customer data, so that conversions which cookies alone would miss can still be matched to the ad click that caused them. Google describes it as a way to “improve the accuracy of your conversion measurement” — and more accurate conversion data is what automated bidding strategies run on. The customer data — email address, name, home address, phone number — is hashed with SHA256 before it leaves the browser or server, and the hash, never the raw value, is what Google matches against signed-in Google accounts. This entry covers the two variants, what data qualifies, how the hashing works, the setup routes, and the conditions under which the feature produces nothing.

What Problem It Solves

Classic conversion tracking depends on a cookie surviving from ad click to purchase. That chain breaks constantly: the visitor declines consent, switches from phone to laptop, returns after browser storage has been cleared, or completes the purchase in a different browser entirely. The conversion happens, but the ad platform never learns about it, so the campaign that produced the revenue looks unprofitable.

Enhanced conversions closes part of that gap using something more durable than a cookie — the email address or phone number the customer typed at checkout. If that hashed identifier matches a signed-in Google account that saw or clicked the ad, the conversion is credited even though the cookie chain broke.

The Two Variants

Google splits the feature in two, and they are configured differently:

• Enhanced conversions for web — for advertisers, in Google’s words, “who want to track sales and events that happen on a website.” The conversion completes online: a checkout, a subscription, a booking. Customer data is collected from the conversion page itself.
• Enhanced conversions for leads — for advertisers “who want to track sales that happen off a website,” originating from a website lead. The form submission is captured online, the deal closes later by phone, email or in person, and the outcome is imported back.

The distinction matters when planning: the web variant improves the accuracy of a number you already report, while the leads variant reports revenue the ad platform previously never saw at all. For a business whose sales cycle runs weeks, the second is usually the larger change.

What Data Is Sent, and How

Google accepts first-party customer data including “email addresses, name, home address, and/or phone number.” Email is the workhorse; the others improve match rates when supplied together.

Before transmission the values are hashed with SHA256, which Google describes as a “secure one-way hashing algorithm.” One-way means the hash cannot be reversed into the original address. Google receives a fingerprint and compares it against fingerprints of its own signed-in account data; a match credits the conversion, a miss produces nothing.

Two practical consequences follow from the hashing being literal:

• Normalisation before hashing is mandatory. User@Example.com and user@example.com produce completely different hashes. Values must be trimmed and lowercased first, and phone numbers converted to E.164 format. Getting this wrong does not throw an error — it silently produces a match rate near zero.
• Nothing degrades gracefully. A typo’d or partially collected field is not a weaker signal; it is no signal.

How It Gets Implemented

There are three usual routes, in ascending order of control:

• The Google tag on the page. The tag reads the customer data from the conversion page — from form fields or a JavaScript variable you expose — and hashes it in the browser before sending.
• Google Tag Manager. The same idea, wired through a container, with the values supplied via the data layer or CSS selectors. Selector-based capture is the fragile option: a redesign of the confirmation page silently breaks it.
• The Google Ads API or an offline import. Data is sent from your server or CRM rather than the browser, which sidesteps ad blockers and consent-blocked tags entirely. This is the route for the leads variant, where the outcome is not known until long after the visit.

Server-side sending is the more reliable of the three for the same reason it is more work: nothing about it depends on what happens in the visitor’s browser.

Enhanced Conversions and Consent

Hashing is not anonymisation, and it does not remove a legal basis requirement. A hashed email is still personal data under GDPR, because it identifies a person to anyone holding the matching table — which is precisely what makes the feature work. Sending customer data to an ad platform therefore needs the same consent and disclosure footing as any other ad-measurement processing, and your privacy policy has to say it happens.

This is also where the feature meets Consent Mode: when a visitor declines advertising consent, the conversion data should not be sent enriched. Configuring enhanced conversions to fire regardless of consent state is a common and consequential implementation mistake.

How to Tell Whether It Is Working

The signal to watch is the diagnostics report in Google Ads for the conversion action, which reports whether enhanced data is being received and at what match rate. Two failure patterns dominate:

• Data arrives, matches do not. Almost always normalisation: unlowercased email, phone numbers in local format, whitespace from a copy-paste field.
• No data arrives at all. The tag is firing before the customer data exists on the page — a common outcome when the confirmation page renders asynchronously and the tag runs first.

Because both failures leave ordinary conversion tracking intact, neither shows up as an error. The conversion count simply does not improve, and the feature is quietly assumed to be working.

What It Does Not Fix

Enhanced conversions improves matching for conversions where a customer identifier exists. It does nothing for anonymous outcomes — a phone call from a visitor who never filled anything in, a walk-in, a purchase made by someone with no Google account. It is a recovery mechanism for a specific gap, not a replacement for attribution modelling or for having reliable tag management in the first place. If your base conversion tracking is misfiring, enhanced conversions layered on top will faithfully enrich the wrong numbers.

Frequently Asked Questions

Related Terms

• Conversion — the outcome being measured
• Attribution — how credit is assigned across touchpoints
• First-party cookie — the mechanism this feature backs up
• Data layer — where customer values are usually exposed
• GDPR — the framework governing this data
• Purchase event — the common web conversion being enriched