Enhanced Conversions in GTM: Recovering Lost Conversions with First-Party Data and the dataLayer

Conversion tracking has a quiet accuracy problem. Cookie restrictions, Safari’s tracking prevention, ad blockers, consent refusals, and people switching between phone and laptop all conspire to break the link between an ad click and the conversion it eventually produced. The result is undercounting: real sales and leads that your conversion tag never gets credit for, which in turn starves Google’s bidding algorithms of the data they need. Enhanced conversions are Google’s answer to this, and when you wire them through Google Tag Manager with a properly populated dataLayer, they recover a meaningful slice of those missing conversions.

What Enhanced Conversions Actually Do

The idea is straightforward. When a conversion happens, you send along first-party data the user already gave you, typically their email address, and optionally phone, name, and address. That data is hashed before it ever leaves the browser, using the SHA-256 algorithm, so Google never receives the raw email. Google then matches the hashed value against the hashed data of signed-in Google accounts. When a match is found, the conversion is attributed to the original ad interaction even if the cookie that would normally have carried that link is long gone.

The privacy mechanics matter here, because this is customer data. The hashing is one-way, so the plaintext email cannot be recovered from the hash. The data is first-party, meaning the user provided it to you directly. And Google requires you to accept its customer data terms before the feature will work, plus you remain responsible for having a lawful basis and consent to use the data this way. None of this is optional fine print; it is the foundation the feature stands on.

There are two flavours worth knowing. Enhanced conversions for web improves measurement of online conversions like purchases and sign-ups that happen on your site. Enhanced conversions for leads is the offline cousin: it captures a hashed email at the point of lead submission so that when that lead later closes in your CRM, you can import the offline conversion and Google can match it back to the original click. This article focuses on the web case, which is the one driven by GTM and the dataLayer.

Before You Touch GTM

Two prerequisites live outside the container. First, enhanced conversions must be turned on in Google Ads itself, under the conversion action’s settings, where you also accept the customer data terms. Second, your container needs the Conversion Linker tag firing on all pages, because it manages the first-party cookies that the conversion tracking relies on. Without the Conversion Linker, enhanced conversions and ordinary conversion tracking both degrade, so confirm it is present before anything else.

Three Ways to Supply the Data, and Why One Wins

Google gives you three methods for telling GTM where the user data is, and they are not equally reliable.

The first is automatic collection, where Google attempts to scan the page and find email and phone fields on its own. It needs no setup, which is its only real virtue. It is also the most fragile, because it guesses, and it misses data that loads dynamically or sits in places it does not expect.

The second is manual configuration with CSS selectors, where you point GTM at specific page elements that contain the email and phone. This is more reliable than automatic, but it shares the weakness of any DOM-based approach: the day a developer renames a class or restructures the confirmation page, your selectors silently stop matching and the data quietly disappears.

The third is the code, or dataLayer, method, and it is the one to use whenever you can. Instead of scraping the rendered page, your developers push the user data into the dataLayer as structured values, and GTM reads it from there. This is robust for the same reason a dataLayer is always preferable to DOM scraping: it is an explicit contract between the application and your container rather than a guess about the HTML. It survives redesigns, it works regardless of how the page renders, and it puts the data exactly where GTM expects it.

Implementing It Through the dataLayer

The flow has three parts: the developer push, a GTM variable that reads it, and the conversion tag that consumes it.

On the conversion page, the confirmation or thank-you page where the user’s details are known, the site pushes the user data to the dataLayer. The cleanest pattern bundles it under a single object alongside the conversion event:

window.dataLayer = window.dataLayer || [];
dataLayer.push({
  event: 'purchase',
  user_data: {
    email: 'jane.doe@example.com',
    phone_number: '+447700900123',
    address: {
      first_name: 'Jane',
      last_name: 'Doe',
      postal_code: 'SW1A 1AA',
      country: 'GB'
    }
  }
});

Inside GTM, you then create the dedicated variable type for this. Go to Variables, create a new variable, and choose User-Provided Data. Set it to manual configuration, and map each field to a Data Layer Variable that reads from the object above, so email points to user_data.email, phone to user_data.phone_number, and so on. This single User-Provided Data variable now packages everything the conversion needs.

Finally, open your Google Ads Conversion Tracking tag, enable the option to include user-provided data, and select the User-Provided Data variable you just built. When the conversion fires, GTM passes the data through, hashes it, and sends it with the conversion.

Let GTM Handle the Hashing, but Mind the Formatting

A common worry is whether you need to hash the data yourself. For a standard GTM web container, you do not. When you supply plaintext through the User-Provided Data variable, GTM normalizes and hashes it with SHA-256 automatically before sending, so the raw values never leave the browser.

What you do need to get right is the formatting, because normalization affects whether a match is found. Email addresses should be trimmed of whitespace and lowercased. Phone numbers should be in E.164 format, meaning a plus sign and country code with no spaces or dashes, like the example above. Country should be a two-letter code. GTM applies its own normalization, but feeding it already-clean values reduces the chance of a near-miss that fails to match. Garbage or inconsistently formatted data simply will not match a Google account, and you lose the recovery you were trying to gain.

Consent Is Not Optional

Because enhanced conversions transmit hashed personal data, they must respect consent. Under GDPR and similar regimes you should not collect or send this data before the user has granted the relevant consent, and in GTM the right way to enforce that is through Consent Mode and trigger conditions, so the conversion tag with user data only fires when marketing consent is present. This is the same discipline that runs through any serious tracking setup: the data should be structurally unable to send before permission exists, not merely discouraged. If you want a practical sense of how to verify this kind of gating actually holds, the approach in my guide to QA-ing a consent implementation applies directly, and the broader pattern of feeding clean structured data to tags is covered in the enhanced ecommerce guide.

Testing What You Built

Verification happens in a few places. In GTM Preview, fire a test conversion and confirm the User-Provided Data variable resolves to the expected values and the conversion tag fires once. In the browser Network tab, you can confirm the conversion request goes out, though the user data within it will already be hashed, so you are checking that it sends rather than reading the values. The most authoritative check is in Google Ads itself: the conversion action’s diagnostics report whether enhanced conversions are receiving data and recording matches, and it flags formatting problems. Give it a day or two to populate, because the diagnostics are not instant.

The Mistakes to Avoid

A handful of errors account for most failed setups. Forgetting the Conversion Linker tag undermines the whole thing. Relying on automatic or CSS-selector collection on a page where the data loads dynamically leaves you with empty fields. Sending poorly formatted data, an email with stray capitals or a phone number with spaces, produces non-matches that look like the feature simply is not working. Pushing the user data to the dataLayer after the conversion tag has already fired means a race the tag loses, so the push must happen before or as part of the conversion event. And firing the tag with user data before consent is both a compliance problem and, depending on your Consent Mode setup, a reason the data is withheld anyway.

Conclusion

Enhanced conversions recover conversions that cookie loss and consent gaps would otherwise hide, by sending hashed first-party data that Google matches to signed-in accounts. Turn the feature on in Google Ads and accept the customer data terms, keep the Conversion Linker firing everywhere, and feed the user data through the dataLayer rather than scraping the page, because the dataLayer is the only source that survives a redesign. Build a User-Provided Data variable that maps email and phone from your dataLayer push, attach it to the conversion tag, let GTM hash the values, format them cleanly, and gate the whole thing behind consent. Done properly, your conversion counts climb back toward reality, and the bidding algorithms that depend on them start making better decisions.

See you soon.