What is Enhanced conversions?

Enhanced conversions is Google Ads' feature for attaching hashed first-party identifiers to a conversion event so that the platform can match it to a user account it recognises.

The distinction worth holding onto is that it improves matching rather than measuring anything new. The conversion already happened and the advertiser already knew about it. What was missing was the connection between that conversion and the advertising click that preceded it.

That connection used to be carried by the browser. Where it is not — a different device, a blocked script, an in-app browsing context, storage that expired — the conversion is recorded and credited to nothing. Sending a hashed email address or phone number with the event gives the platform a second route to the join.

The advertiser collects an identifier the customer supplied: the email address on an order, a phone number on a lead form, a name and address at checkout.

That identifier is normalised — lower-cased, whitespace trimmed, formatted to a specified standard — and hashed, so what leaves the advertiser is a fixed-length string rather than the value itself.

The platform hashes its own records the same way and compares. Where the hashes agree, the conversion is matched to a signed-in account, and the advertising that account interacted with can be credited.

Nothing about that process transmits the raw address or number, which is a real protection and a narrow one: it secures the data in transit and at rest, and it says nothing about whether the advertiser was entitled to send it.

An identifier at the point of conversion. A purchase with an email address, a lead with a phone number. A conversion with no identifier cannot be enhanced.

Correct normalisation and hashing. The specification is precise and a deviation produces hashes that never match. This is the most common implementation fault and its symptom is no improvement at all, which is easily mistaken for the feature not working.

A consent position. Whatever lawful basis applies in the market has to exist and has to be honoured. Hashing is not a substitute for it, and an implementation that sends identifiers regardless of consent state has a compliance problem rather than a measurement improvement.

A delivery route. Either a browser-side implementation that reads the identifier from the page, or — more reliably — a server-side path that sends it from the system that recorded it.

The reported conversion count rises with no change in delivery, because conversions that were previously unmatched are now credited.

That has three consequences worth anticipating.

Historical comparisons break. A period before and a period after the implementation are measured differently, and the improvement in every derived figure — cost per acquisition falls, return on ad spend rises — is a measurement change rather than a performance one.

Automated bidding adjusts. A conversion-based strategy is now learning from more complete data, which is the real benefit and which also means a period of adjustment while the model rebuilds against a fuller picture.

Modelled conversions may fall. Where the platform was estimating conversions it could not observe, some of those estimates are replaced by observed matches. The total may rise less than the count of newly matched conversions suggests, because part of the gap was already being filled with an estimate.

That last point is worth understanding before somebody is disappointed by it. Better matching partly substitutes for modelling rather than adding on top of it, and the gain is in reliability as much as in volume.

It only helps where an identifier exists. Anonymous purchases, guest checkouts with no contact details, and conversions recorded without customer data are unaffected.

It depends on the customer being identifiable to the platform. A person who bought using a work address and uses a personal one on their account will not match.

It is still attribution. A conversion matched more reliably is still credited by a convention, and the platform's claim about what its advertising caused is exactly as strong as it was.

It does not remove the case for server-side collection. The two are complementary: server-side delivery gets the event there reliably, and enhanced identifiers get it matched once it arrives.

For an account improving its measurement, the ordering that produces the most benefit for the least work is fairly consistent.

Get the conversion definition right first, because everything downstream inherits it. Confirm the count reconciles against the business's own records. Add server-side event delivery so events arrive whatever the browser did. Then add hashed identifiers so those events match. Then send the downstream outcomes — the lead that closed, the order that shipped — which is where the improvement to bidding rather than to reporting actually lives.

Doing them in the other order produces a well-matched, reliably delivered stream of the wrong event.

The feature can be implemented in two places, and the choice is worth making deliberately.

From the page. The identifier is read from the conversion page — a confirmation screen showing the email address, or a field captured earlier in the flow — and hashed in the browser before being sent. It is the faster implementation and it inherits the browser's fragility: a blocked script or a page that does not expose the identifier produces nothing.

From the server. The identifier is sent from the system that recorded the conversion, which is where it reliably exists. It requires the engineering that a server-side path always does, and it works regardless of what the browser did.

The second is better in every respect except effort. For an account already sending events server-side, adding the identifiers is a small extension rather than a new project, which is the argument for doing them in that order.

The implementation fails silently when the hashing or normalisation deviates from the specification, and the symptom — no improvement — looks identical to the feature simply not mattering much.

Three checks separate them. The platform's own diagnostic for the feature, where one is offered, reports whether identifiers are being received and matched. The reported conversion count should rise at the implementation date and stay risen. And the share of conversions the platform describes as modelled should fall, because matched observations are replacing estimates.

If none of the three moves, the implementation is not working rather than not helping.