Enhanced conversions in Google Ads: web and leads setup

What enhanced conversions do

Your conversion tracking works. Orders and enquiries arrive in the ads account. Still, part of the attribution is missing, because Google does not always see the same identifier at the click and at the order. That gap is what enhanced conversions are meant to narrow.

The feature adds customer data the visitor gave you themselves to the existing conversion tag: email address, phone number, name and address. Those values are normalised, hashed with SHA-256 and sent to Google in that form. Google compares the hash with the data of users who were signed in to their Google account when they clicked your ad. If the hash matches, the conversion can be attributed to the ad even when the cookie or click identifier was lost on the way. Google describes this in the overview of enhanced conversions.

There are two variants:

Variant	What for	Where the data comes from
Enhanced conversions for web	Orders and enquiries completed directly on the website	The order or thank-you page at the moment of conversion
Enhanced conversions for leads	Deals that only close later in the CRM, for example a qualified lead or a signed contract	The website form supplies the identifier, the closed deal is uploaded later from the CRM

---

What enhanced conversions do not do

Three misunderstandings show up in almost every project.

• They do not replace the conversion event. The base is still a working conversion tag or a clean upload. If the base is broken, customer data does not heal it. How to build the base is covered in Google Ads conversion tracking setup.
• They do not bypass the cookie banner. Sending customer data for advertising purposes depends on the ad_user_data signal in consent mode. When it is denied, the consent mode overview states that no hashed first-party data is sent for enhanced conversions. There is no path around consent.
• They do not produce more conversions, only better attribution. Google now credits conversions that previously stayed unattributed to the right ad. Anyone expecting a jump in the total is measuring the wrong thing.

---

What changed in 2026

Until early 2026 you had to pick one implementation route in the ads account: Google tag, Tag Manager, API or partner. That is over. Google rebuilt the feature in two steps, documented in the announcement on changes to enhanced conversions:

When	Change
April 2026	Google Ads accepts customer data from website tags, Data Manager and API connections at the same time. Choosing between methods is no longer necessary.
June 2026	Enhanced conversions for web and for leads are merged into one setting with a single on and off switch.
15 June 2026	New integrations for offline conversions and enhanced conversions for leads run through the Data Manager API. The Google Ads API no longer accepts new adopters of this feature.

Accounts that had already accepted the customer data terms need to do nothing, according to Google. New accounts turn the feature on at account level or per conversion action.

For developers the third point is the one that counts. The post on the Google Ads Developer Blog from 15 May 2026 is explicit: from 15 June 2026 the Google Ads API no longer accepts new adopters of offline conversion imports, enhanced conversions for leads included. Anyone already using the feature there is allowlisted by developer token and can keep uploading while moving to the Data Manager API. Everyone else receives the error CUSTOMER_NOT_ALLOWLISTED_FOR_THIS_FEATURE.

---

Prerequisites

Before you build anything, three things have to be in place.

1. Accept the customer data terms. In the ads account the setting sits under Goals, Conversions, Settings. There you turn on enhanced conversions and confirm the customer data terms. Without that acceptance Google discards the data no matter how clean the tag is. The steps are in the Google Tag Manager setup guide.

2. Consent mode with ad_user_data. Your cookie banner has to set the ad_user_data signal and only switch it to granted after consent. Which banner category maps to which signal is a documented decision. The guide Consent Mode Basic vs Advanced covers the four signals in detail.

3. A working conversion action. For web you need a conversion action of type Website, for leads one of type “Website (Import from clicks)”. Auto-tagging must be on so the click identifier (GCLID) reaches your site.

---

What data Google expects and how it is normalised

Normalisation is where most setups fail quietly. A hash of “Anna.Muster@Example.com” and a hash of “anna.muster@example.com” are two different strings. Google can only match when both sides apply the same rules. The rules are in the Google tag setup guide and in more detail in the Data Manager API formatting guide:

Field	Normalisation	Hashed
Email address	Lowercase, remove whitespace. For gmail.com and googlemail.com also remove all dots before the @	Yes
Phone number	E.164 format: plus sign, country code, then digits only	Yes
First name	Lowercase, trim whitespace at the edges, no prefixes such as “Mrs”	Yes
Last name	Lowercase, trim whitespace at the edges, no suffixes such as “Jr”	Yes
Street	Lowercase, remove symbol characters	Yes
City	Lowercase, remove symbol characters	No
Region	Abbreviation or full name, lowercase	No
Postal code	Trim whitespace at the edges	No
Country	Two-letter code per ISO 3166-1 alpha-2, for example DE	No

Important in practice: if you hand the Google tag or Tag Manager plain values, the tag takes care of normalisation and hashing itself. Only when you supply pre-hashed values do you have to apply the rules yourself. Doing both at once is the classic mistake, more on that below.

According to the Google tag guide at least one of these fields must be present: the email address (preferred), the address with first name, last name, postal code and country or the phone number combined with email or a full address. You can pass up to three values for email and phone and two addresses to raise the chance of a match.

---

Route 1: Google tag with user_data in gtag

If the Google tag sits directly in the source code, this is the shortest route. On the order or thank-you page you set the customer data with gtag('set', 'user_data', ...) before the conversion event is sent. The field names are fixed:

gtag('set', 'user_data', {
  "email": yourEmailVariable,
  "phone_number": yourPhoneVariable,
  "address": {
    "first_name": yourFirstNameVariable,
    "last_name": yourLastNameVariable,
    "postal_code": yourPostalCodeVariable,
    "country": yourCountryVariable
  }
});

gtag('event', 'conversion', {
  "send_to": "AW-XXXXXXXXX/XXXXXXXXXXXX",
  "value": 89.90,
  "currency": "EUR",
  "transaction_id": "ORDER-12345"
});

Fill the variables server-side from the order, not from the form in the browser, otherwise typos and empty fields end up in the hash. If your system already outputs hashed values, use the fields sha256_email_address and sha256_phone_number instead. Order matters: set before event, otherwise the conversion event goes out without customer data.

---

Route 2: Google Tag Manager with the “User-provided data” variable

In Tag Manager everything runs through a variable of type “User-provided data”. First you have to enable “Allow user-provided data capabilities” in the Google tag. The variable has three modes, described in the Tag Manager setup guide:

Mode	How it works	When it fits
Automatic collection	The tag scans the page for fields that look like email, phone or address	Fast start, little control, risky with several forms on one page
Manual configuration	You specify CSS selectors or JavaScript variables for each field	When the values are in the DOM and the selectors are stable
Code	You pass an object from the data layer or a custom variable	The cleanest option when a developer fills the data layer

For the code mode your page writes the customer data into the data layer before the conversion tag fires:

window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
  event: "purchase",
  transaction_id: "ORDER-12345",
  value: 89.90,
  currency: "EUR",
  user_data: {
    email: "anna.muster@example.com",
    phone_number: "+49151XXXXXXX",
    address: {
      first_name: "anna",
      last_name: "muster",
      postal_code: "24937",
      country: "DE"
    }
  }
});

In Tag Manager you create a data layer variable user_data, choose the Code mode in the “User-provided data” variable and point it at that data layer variable. In the Google Ads conversion tracking tag you enable the inclusion of user-provided data and select the variable. Then you check in preview mode that the request to Google contains the hashed values.

---

Route 3: Shopify through the Google & YouTube app

On Shopify you do not build anything by hand. The Google & YouTube app handles conversion tracking and, if you want, sends the customer data along. According to the Google & YouTube app guide it takes three steps: open the Settings tab in the app, find “Enhanced conversions” under the Google Ads settings and select Turn on, then review and agree to the customer data terms. The prerequisite is a linked ads account and active conversion tracking through the app.

Do not add your own conversion tag with customer data in the theme or in custom pixels on top. Then the same order counts twice. One route per shop.

---

Enhanced conversions for leads

With leads the deal does not close on the website. The flow has two halves, described in the enhanced conversions for leads guide:

Half 1: The form on the website. On submit a tag captures the prospect’s identifier. At least one of these fields has to be included: the email address (recommended because it is unique) or the phone number with country code. Address data helps on top. In Tag Manager you need the Conversion Linker and a tag of type “Google Ads User-Provided Data Event”, which has the same three modes as above. Google also recommends storing the GCLID on submit.

Half 2: The upload from the CRM. When the enquiry turns into a deal, you upload the conversion with the hashed value of the same identifier. Each record contains the name of the conversion action, the time and at least one identifier. Google names three routes: Data Manager in the ads account (recommended), the API and third-party integrations such as Zapier, HubSpot or Salesforce.

For uploads via API the Data Manager API applies since 15 June 2026. Its guide for Google Ads conversions specifies: the conversion action must have the type UPLOAD_CLICKS, “Website (Import from clicks)” in the ads account. Every event needs an eventTimestamp. Identifiers such as email address, first name and last name must be hashed with SHA-256 and encoded as hex or Base64. As identifier the GCLID or at least one hashed user identifier is enough, both together is better.

The API accepts consent per event in a consent object. According to the Consent object reference it has the fields adUserData and adPersonalization with the values CONSENT_GRANTED, CONSENT_DENIED or CONSENT_STATUS_UNSPECIFIED. In the leads guide Google calls populating them highly recommended. So your CRM has to carry the consent state from the form all the way to the upload.

---

Verify: The diagnostics report

After the implementation you wait. Google names 48 hours in the Tag Manager guide and 72 hours in the Google tag guide before you evaluate the diagnostics report. You find it in the ads account under Goals, Summary, Diagnostics tab. The status of each conversion action leads there as well.

The diagnostics report for web has four states:

Status	Meaning
Excellent	Setup active, data arriving, nothing to do
Good	Setup active, more data fields would improve matching
Needs attention	Setup active but with errors such as missing fields or wrong formatting
No recent data	No enhanced conversions recorded in the last 7 days

The diagnostics report for leads adds the status “Urgent” for an inactive setup, such as a tag that does not fire on the form. The most important alerts there:

• “Importing limited user-provided data”: You only upload events that have both user data and a Google identifier such as the GCLID. Google wants to see all events with user data, including those without a GCLID.
• “Tag is missing user-provided data”: The tag fires but the fields are empty. Usually a wrong selector or a thank-you page where the value is no longer in the DOM.
• “No user-provided data matches”: The uploaded hashes match none of the hashes from the form. Almost always a normalisation that runs differently on one side than on the other.

According to Google the alerts refer to the last day or, if there is too little data there, to the last 7 days. Uplift metrics appear in the report only after 30 days of ongoing transmission. Anyone looking for an effect after two days is looking too early.

---

Common mistakes

1. Hashing already-hashed data again. The tag hashes plain values itself. A hash in the email field becomes a hash of a hash and never matches. Hashed values belong in sha256_email_address and sha256_phone_number.
2. Wrong normalisation. Uppercase letters, a trailing space, a dot in a Gmail address: each case produces a different hash. This matters most when you hash yourself or upload from the CRM.
3. Phone number without country code. “0151 1234567” is not E.164. It has to be “+491511234567”.
4. Sending data without consent. If ad_user_data is not granted, the tag must not transmit customer data. Firing the tag before the banner or mapping the signal wrongly sends data you are not allowed to send.
5. Expecting more conversions. Enhanced conversions improve attribution. The total number of orders does not change. The right comparison is the share of attributed conversions before and after.
6. Two routes at once. Google tag in the theme plus Tag Manager plus shop app: every order is reported several times. One route per conversion action.
7. Uploading only records with a GCLID for leads. That triggers the “Importing limited user-provided data” alert and throws away the benefit of the feature.

---

Checklist

1. The base conversion fires correctly, with a transaction identifier and without duplicates.
2. The customer data terms are accepted in the ads account and enhanced conversions are switched on.
3. The cookie banner sets ad_user_data and only switches it to granted after consent.
4. Exactly one route is chosen: Google tag, Tag Manager or shop app.
5. Normalisation is verified: lowercase, no whitespace at the edges, E.164 for phone, ISO country code.
6. Plain values go into email and phone_number, hashed ones into sha256_email_address and sha256_phone_number, never both at once.
7. In the network tab the request to Google contains the hashed values.
8. For leads: the form tag captures email or phone, the GCLID is stored, the CRM carries the consent state.
9. For leads: the upload runs through Data Manager or the Data Manager API, not through a new connection to the Google Ads API.
10. After 48 to 72 hours the diagnostics report shows “Excellent” or “Good” and open alerts are resolved.

---

Where FW Delta comes in

Enhanced conversions only pay off on a clean foundation: a correct conversion event, a documented consent mapping and, for leads, a CRM connection that carries identifier and consent all the way to the upload. The web tracking service builds that foundation, the tracking service also covers connections beyond the shop.

If you are not sure whether your setup transmits customer data cleanly at all, the Tracking-Check is the right starting point. It verifies the base conversion, the consent state and the actual content of the requests to Google.

FW Delta handles the technical implementation. Whether your legal basis and your banner text cover the transmission of hashed customer data is for your legal advisers to assess. This guide is a technical walkthrough, not legal advice.