Enhanced conversions

The feature does not create new tracking of unknown users. It works with data the company already receives inside the conversion process itself: the email someone types in when buying, the phone number left in a form, the billing address. That data is turned into irreversible fingerprints before it leaves the browser or the server.

There are two variants and they should not be confused. Enhanced conversions for web measure actions that end on the site, such as a purchase or a sign-up, and send the data at the very moment the conversion fires. Enhanced conversions for leads cover the opposite case: the form is filled in on the site, the sale closes weeks later by phone or in the CRM, and that close is uploaded afterwards to link it back to the original click.

One thing the feature is not: a substitute for consent. This is still personal data even when it travels hashed, and Google requires the advertiser to comply with its customer data policies and, where applicable, its EU user consent policy. Without that basis, the technical activation is not usable.

The path has four steps. First, normalisation: the value is lowercased, surplus whitespace is stripped and the phone number is brought into the international E.164 format. Second, hashing with SHA-256, a one-way algorithm, so that Google receives a string rather than the readable email. Third, transmission alongside the conversion. Fourth, matching: Google holds equivalent strings for its signed-in accounts and looks for matches in order to attribute the conversion to the click that produced it.

The accepted fields are the email address, which is preferred, the phone number in E.164 format, and the components of the postal address, meaning first name, surname, street, city, region, postcode and country. At least one valid combination is required: the email on its own, the full address, or the phone number together with an email or an address. The advertiser can hash the data before sending it or leave that to the tag.

There are three implementation routes. The Google tag receives the data by code on the conversion page. Google Tag Manager offers automatic collection, manual configuration with CSS selectors or JavaScript variables, and the data layer route. The third route is server side, via the Google Ads API and, for offline uploads, via Data Manager. Google has set two dates for 2026: from April it accepts data arriving by tag, by Data Manager and by API connection at the same time; on 15 June it merges the two variants into a single switch and moves offline uploads to Data Manager, blocking them in the Google Ads API.

The decision behind it is not technical but one of sequence: whether it is worth building now, or whether the consent layer has to be fixed first. Measured conversions feed automated bidding, so a gap in measurement translates into bidding decisions taken on incomplete data. That is the real argument in favour, and it does not depend on any published figure.

Before investing development hours, three things are worth checking. That first-party data exists at the conversion point at all, because a form that only asks for a free-text message is no use here. That the consent platform passes the advertising user data signal to Google, since without it no transmission happens even when the code is in place. And that someone with authority has accepted the terms of service in the Google Ads or Analytics account, because collection does not start until then.

On the expected gain there is no figure that transfers from one case to another. It depends on what share of your customers browse while signed in to a Google account and on your consent acceptance rate, two values that vary by country, sector and device. The percentages circulating in sales material are published without the methodology used to measure them.

• Sort out consent first. Check inside the platform itself that the advertising user data and personalisation signals reach Google, and only then switch the feature on.
• Normalise before hashing: lowercase, no surplus whitespace and phone numbers in E.164 format. A badly normalised value produces a fingerprint that will never match.
• Start with the email address, which is the preferred field, and add phone or address only if the form already asks for them out of business necessity.
• Verify transmission in the conversion diagnostics inside Google Ads, rather than assuming the setup is fine because the tag fires.
• Exclude conversions falling into sensitive categories, which Google does not accept for this feature or for store sales uploads.
• Document which fields you send, from which forms and on what legal basis, and review it whenever the form changes. That basis is determined by your legal advisers, not by the product documentation.

• Switching the feature on with a cookie notice that does not pass the consent signals. The code sits there installed and sends nothing.
• Sending the value unnormalised, or hashing a second time a value that arrived already hashed, which sinks the match rate without any error appearing.
• Confusing the two variants and expecting the web one to capture sales that close by phone weeks later.
• Promising a specific internal increase in measured conversions based on percentages published in sales material.
• Forgetting the June 2026 migration and leaving offline upload processes pointing at the Google Ads API.