LanderKit

Templates written in French — fully translatable in minutes

Enhanced Conversions on a landing page: how Google Ads' SHA-256 hashing actually works

Published on 17 August 2026 · 8 min read

A visitor fills out your form, lands on the thank-you page, your Google Ads conversion tag fires — and yet the conversion never shows up in the account, or shows up days later as a "modeled" estimate. That's not a one-off glitch: it's the direct result of everything that blocks cookie-based tracking before Google can even count it — ad blockers, Safari trimming third-party cookie lifespans, and Consent Mode v2 itself, which denies ad_storage until the visitor answers the banner. Google's answer, pushed for several years and further simplified in 2026, is called Enhanced Conversions: instead of relying solely on a cookie, the landing page sends a hashed fingerprint of the email or phone number captured in the form, which Google can then match against signed-in accounts. Here's what that actually changes, and how to install it without getting it wrong.

What Google means by an "enhanced conversion"

The mechanism is distinct from Consent Mode, which it's often confused with. Consent Mode governs the right to send a signal; Enhanced Conversions improve the quality of that signal once the right has been granted. In practice, alongside the standard conversion tag (fired on the thank-you page, never on button click — the same logic used for the Meta pixel's Lead event), the landing page sends Google Ads one or more values captured in the form: email, phone number, or postal address. That data never leaves in plain text: it's hashed with SHA-256, a one-way function — there's no way to recover the original email from the hash. Google then compares that hash against the ones it already holds for its own signed-in user accounts, and when it matches, it links the conversion back to the originating ad click, even without a usable cookie.

For web or for leads: the distinction that decides who hashes what

This is the most commonly misunderstood part, and the most frequent source of broken implementations. Google Ads distinguishes two mechanisms with almost identical names:

  • Enhanced conversions for web — built for a standard conversion tag placed on the thank-you page. The form sends the data in plain text to the Google tag (via gtag or a GTM tag), and it's Google's own script, running in the visitor's browser, that performs the SHA-256 hashing before the data is sent. Never hash the data yourself on this path: double-hashing silently breaks the match.
  • Enhanced conversions for leads — built for offline conversions: a contact form that turns into a signed quote a week later, a sales call that converts into a customer three days after. Here, it's on you (or your CRM) to hash the data in SHA-256 before sending it to Google, through offline conversion imports or the Google Ads API.

For the vast majority of lead-generation landing pages — a template like real estate, coach-consultant, or saas-waitlistfor web is what applies, as soon as the Google Ads conversion fires directly on the thank-you page. For leads only becomes relevant if the lead turns into a customer later, offline, and that second event also needs to reach Google Ads so bidding can optimize on real value rather than just a filled-out form.

Implementing it on a Next.js landing page

On a dedicated thank-you page, the for web setup via gtag comes down to a single call, placed right before the usual conversion tag fires — the same pattern described in our GA4 tracking guide for its Analytics equivalent:

  1. Capture the data in the right format — at form submission, grab the email (and phone number, if collected) exactly as entered, without modifying it.
  2. Send it to Google in plain text — a gtag('set', 'user_data', { email: '...', phone_number: '...' }) call placed right before the standard gtag('event', 'conversion', {...}) call; that's the same gtag call that already drives Consent Mode, so it needs to follow the same ordering rule: never before the visitor has consented to advertising tracking.
  3. Or route it through Google Tag Manager — inside a GTM container, turn on "Enhanced Conversions" on the Google Ads conversion tag and point it to the form's fields (email, phone) via a data layer variable; GTM then handles the hashing automatically, with no code in the page itself, matching the approach in our GTM on a landing page guide.

Deploying on Vercel changes nothing here (see our Next.js deployment guide), but watch for one detail that often gets missed: if your form redirects the visitor somewhere other than a dedicated thank-you page before the tag fires, the user_data call simply doesn't have time to go out.

What changed in 2026: a single toggle

Until recently, turning on Enhanced Conversions meant choosing among several implementation methods that didn't fully line up with each other — the site tag, Google Tag Manager, data import via the API. Over 2026, Google rolled out a unification of these settings: accounts are moving to a single conversion-level toggle that accepts submitted data regardless of the technical path chosen (site tag, Data Manager, or API connection), and the long-standing split between the "for web" setting and the "for leads" setting has itself been merged into one switch. The underlying technical mechanism described above — automatic browser-side hashing for a standard tag, manual hashing for an offline import — stays the same; it's the interface configuration that's been simplified. If your account still shows the old, separate settings, there's nothing urgent to do: the migration happens automatically, without breaking a tag that was already wired correctly.

GDPR: the same rule as for any advertising signal

SHA-256 hashing doesn't exempt anything on the GDPR side: a hashed email remains personal data as long as it can, through matching, identify a person — which is precisely its purpose here. The user_data call therefore follows the same rule as the rest of the advertising tracking covered in our Consent Mode v2 article: it must never fire before explicit consent to ad_storage and ad_user_data, collected through a compliant cookie banner. Our GDPR form compliance guide covers what the form itself needs to satisfy, independent of the tracking that follows from it.

What research says about these "privacy-preserving" mechanisms

Enhanced Conversions belong to a broader family of tools that Google, Meta and Apple each market as "privacy-preserving" measurement solutions. A study by McGuigan, Sivan-Sevilla, Parham and Shvartzshnaider, published in the journal New Media & Society, examined the technical documentation of all three companies to understand what "privacy-preserving" actually means in their implementations: the authors show these solutions frame privacy chiefly as statistical anonymity and limiting access to raw data — hashing is a textbook example — rather than as meaningful control handed to the user over how the data is used, and they offer a critical reading of these mechanisms through the lens of contextual integrity theory (see the study on Google Scholar). A useful nuance before installing these tools without a second thought: hashing protects the data in transit, but it doesn't change the fact that a visitor's email, once matched on Google's side, becomes a full-fledged advertising identifier — which is exactly why the consent requirement still stands.

Common mistakes

  • Hashing the data yourself before sending it via for-web gtag — Google's script already does it; double-hashing produces a hash that can never be matched again.
  • Confusing for web and for leads — using offline import (pre-hashed data) for a conversion that already fires on the thank-you page, or the reverse.
  • Sending user_data before consent — the same mistake as with Consent Mode v2, with the same legal consequences.
  • Sending poorly normalized fields — an email with stray spaces or inconsistent casing lowers the match rate with no error message to flag it.
  • Forgetting to re-check after a redesign — a renamed form field or a moved thank-you page silently breaks the user_data call, the same way it breaks the rest of the tracking covered in our Meta pixel article.

On a landing page running a real ad budget, a few extra points of match rate translate directly into a lower cost per lead, because Google Ads' bidding algorithm finally gets a complete signal to learn from. The 10 LanderKit templates ship with a dedicated thank-you page out of the box — the exact spot where this user_data call belongs — on a Next.js base clean enough that wiring it up takes a few lines of code, not a project: €89 per template, €229 for the full bundle.

FAQ

Frequently asked questions

Do Enhanced Conversions replace Consent Mode v2?

No, the two are complementary and apply one after the other. Consent Mode v2 governs the right to send an advertising signal based on the visitor's choice on the cookie banner; Enhanced Conversions, once that right is granted, improve the quality of the signal sent by adding a hashed fingerprint of the email or phone number. Without consent, the user_data call should simply never fire.

Do I need to hash the email myself before sending it to Google Ads?

It depends on the method. For "for web" Enhanced Conversions via gtag or Google Tag Manager, no: the data is sent in plain text and Google's own script, running in the browser, performs the SHA-256 hashing. For "for leads" Enhanced Conversions (offline conversion import, API), yes: you need to hash the data yourself before sending it.

Which method applies to a standard landing page form?

For web, in most cases: as soon as the Google Ads conversion fires on the thank-you page at the moment the form is submitted, that's the mechanism that applies. For leads only becomes relevant if the lead turns into a customer later, offline, and that delayed conversion also needs to reach Google Ads.

What does the 2026 unification actually change on the Google Ads side?

It simplifies configuration in the interface — a single toggle instead of several separate implementation methods to choose from — without changing the underlying technical mechanism: automatic browser-side hashing for a standard tag, manual hashing for an offline import. A tag that was already wired correctly before this change keeps working; the migration to the new setting happens automatically on the account side.

Read next

Related articles