Enhanced Conversions Setup with GTM: 4 Easy Steps

Hey there! If your conversion numbers have felt lower than reality lately, especially on browsers that block third party cookies, this one's about a real fix Google Ads itself recommends.

Enhanced conversions setup sits apart from the rest of this series: it isn't a free automatic feature with a documented gap, it's a genuine system you turn on yourself that hashes first party data like an email address so Google Ads can match more real conversions than cookies alone ever could. Getting it right depends on a handful of quiet, easy to miss mechanical details, which is exactly what this guide walks through with real, working proof for each one.

Google's own enhanced conversions reference confirms the core idea: on a conversion page, you capture first party data the visitor already gave you, like an email address, hash it, and send that hash alongside the normal conversion event so Google Ads can match it against its own hashed advertiser data, even when a cookie never survived the click.

Enhanced conversions setup through Google Tag Manager runs through the same "Google tag" you likely already have deployed for other conversion tracking, per Google's own accelerate resource walkthrough, rather than a separate standalone tag type, which is the detail that trips people up first: there's no single obvious "Enhanced Conversions" tag to search for in the GTM gallery.

The reason enhanced conversions setup is worth the extra work in the first place comes down to how much conversion tracking has changed. Safari and Firefox both restrict third party cookies by default, and even Chrome's own cookie behavior keeps shifting, so a conversion that depends entirely on a cookie surviving from ad click to purchase can quietly go unmeasured. Hashed first party data gives Google Ads a second, independent way to recognize the same real customer.

Per Google's own field reference, the supported fields are an email address, a phone number formatted to the E.164 standard, and a full address made of first name, last name, postal code, and country as required pieces, with street, city, and region optional on top. At minimum you need one complete combination: an email alone is enough, or a phone number paired with a name and address.

You get a real choice in how the data gets hashed: hand Google raw, unhashed values and let the Google tag normalize and hash them automatically, or normalize and hash the values yourself first and send already hashed hex SHA256 strings. Google's own GTM setup guide covers both paths, and which one you pick matters a lot more than it first sounds like, covered fully in the normalization section below.

Inside GTM itself, the mechanism is a real variable type called User-Provided Data, attached to your Google tag's Event Parameters as a parameter literally named user_data. Analytics Mania's own enhanced conversions walkthrough is worth reading alongside Google's docs for a second, independent explanation of the same setup.

That variable offers three real configuration methods: automatic detection, which scans the rendered page for likely email and phone fields; CSS selectors or JavaScript variables, which point directly at specific form fields; or a code snippet, a custom JavaScript variable returning a structured object with keys like email, phone_number, and nested address fields.

For a checkout flow where the conversion itself happens on a later page than where the customer actually typed their email, Google's own documentation on the separate User-Provided Data Event tag covers capturing that data early and forwarding it, rather than requiring it to live on the exact same page as the conversion event itself.

Google's normalization rules are specific: trim leading and trailing whitespace, lowercase everything, format phone numbers to E.164, and, only for gmail.com and googlemail.com addresses, strip periods from the part before the @. Here's that logic proven with real code, plus a real SHA-256 hash computed from actual Node crypto rather than a fabricated string.

normalizeEmail('  John.Doe@Gmail.com  ')
// -> 'johndoe@gmail.com', periods stripped, gmail-only rule

normalizeEmail('  John.Doe@Yahoo.com  ')
// -> 'john.doe@yahoo.com', periods kept, non-gmail domain

sha256Hex('  John.Doe@Gmail.com  ')
// -> a completely different real hash than the normalized version below

sha256Hex('johndoe@gmail.com')
// -> the actual canonical hash Google's servers expect

The same email address, unnormalized versus correctly normalized, produces two totally different real SHA-256 hashes, since a single space or capital letter changes every character of the output. That's the real reason enhanced conversions setup depends so heavily on normalizing consistently: to Google's matching system, an unnormalized hash isn't a fuzzy near miss, it's simply a different value entirely.

The fix is simple once you know to look for it: pick exactly one hashing path. Either send raw, normalized values and let the Google tag hash them, which is Google's own recommended default, or hash the values yourself using a real SHA256 implementation, like MDN's own reference for the browser's SubtleCrypto.digest(), and turn the tag's automatic hashing off, but never both at once.

Enhanced conversions setup done through the underlying gtag() queue has one more real ordering rule that's easy to miss: a gtag('set', 'user_data', {...}) call only attaches its data to conversion events processed AFTER it runs, never to ones that already fired. Here's that exact behavior proven against a real, literal copy of the gtag.js queue mechanism in a real browser.

Set before event: the real conversion event carries the hashed user data.

Event before set: the same conversion event fires with no user data attached at all.

In a real GTM container this usually shows up as a tag sequencing mistake: the Google tag with the enhanced conversions variable attached needs to actually run, or at minimum have its user_data set call processed, before or as part of the same trigger firing the conversion event, not afterward on a separate later tag.

Enhanced conversions setup depends specifically on the ad_user_data consent signal, not ad_storage. One consent management vendor's own explainer describes ad_user_data as the signal that governs whether personal data can be transmitted to Google's advertising services at all, separate from whether cookies are allowed or whether that data gets used for ad personalization.

A privacy consent blog's own real walkthrough spells out the practical result: when a visitor denies ad_user_data, the hashed data is dropped entirely and never reaches Google, while the base conversion event's own behavior depends on your Consent Mode setup, either a cookieless modeling ping under Advanced Consent Mode or nothing at all under Basic Consent Mode.

That distinction matters because a site that only checks ad_storage before attaching enhanced conversions data is checking the wrong signal, and can end up sending hashed personal data to Google Ads even when a visitor specifically declined that transmission.

Before assuming the setup above is finished, actually confirm it's working. Google's own enhanced conversions for web tag diagnostics report flags real issues directly inside Google Ads, like missing fields or a low match rate, rather than leaving you to guess from the outside whether the hashed data is actually arriving.

For the tag sequencing issues that show up most often around any conversion setup, common GTM mistakes that break your tracking and the GTM data layer guide are worth a read alongside this one. And once enhanced conversions setup is handled, the rest of this series covers button clicks, PDF downloads, scroll depth, and outbound link clicks for the rest of a genuinely complete tracking setup.