Your Google Ads conversion tag fires when a purchase happens — except when it doesn't. Safari's Intelligent Tracking Prevention shortens cookie lifetimes, ad blockers strip the tag entirely, consent banners suppress it, and a customer who clicks on their phone and buys on their laptop looks like two unrelated strangers. The click happened. The sale happened. The report shows nothing — and Smart Bidding, which learns from that report, starts optimizing against an incomplete picture of reality.
Enhanced Conversions is Google's answer to that gap. This guide covers what it actually is, how it recovers conversions the tag loses, the difference between the web and leads variants, exactly what data leaves your site, and the two setup paths — so you can pick the right one instead of the easy one.
What Enhanced Conversions Actually Is
Enhanced Conversions is a supplement to your existing conversion tag, not a replacement. The tag still fires the way it always did. Alongside it, you send Google a piece of first-party data the customer already gave you — typically the email address they typed at checkout or into a lead form — hashed with SHA-256 before it leaves your page or server.
Google takes that hash and matches it against its own hashed list of signed-in Google accounts. If the customer was signed in when they clicked your ad, the match reconnects the conversion to the click even when the cookie that would normally make the connection is long gone.
The key property: this is data your customer handed you on purpose, in a transaction with you. Enhanced Conversions does not collect anything new — it changes what happens to one field you already have (Google's documentation).
Where Your Conversions Go Missing
Four leaks drain tag-based measurement, and they compound:
- Browser cookie restrictions. Safari caps the lifetime of cookies set by ad-click landings. A customer who clicks Monday and buys the following week can come back with no cookie left to attribute against.
- Ad blockers and tracking protection. If
gtag.jsnever loads, the conversion never reports, regardless of cookies. - Consent banners. A visitor who declines tracking suppresses the tag for the whole session — including the purchase at the end of it.
- Cross-device journeys. Click on mobile, buy on desktop. Cookies live per device; the signed-in Google account is the only bridge, and Enhanced Conversions is what lets Google use it for your conversions.
The damage is not just cosmetic underreporting. As illustrative math — not a benchmark — imagine your campaigns drive 100 real conversions but the tag observes only 80. Your reported CPA looks 25% worse than reality, and Smart Bidding lowers bids on campaigns that were actually profitable. Missing data does not stay neutral; it actively steers budget wrong.
Web vs. Leads: One Name, Two Different Products
Google ships two variants under the same banner, and mixing them up wastes a setup week:
| Enhanced Conversions for Web | Enhanced Conversions for Leads | |
|---|---|---|
| Problem it solves | Online conversions the tag missed | Offline sales that close in your CRM |
| Conversion happens | On your website, same session or later | Days or weeks later — sales call, contract |
| Data captured at | The conversion page (checkout email) | The lead form submit (email/phone) |
| What it replaces | Degraded cookie-based measurement | GCLID-based offline conversion imports |
| Typical user | E-commerce, SaaS self-serve | Lead gen, B2B, high-ticket services |
Web is the one most advertisers mean: the purchase happens on your site, the tag might miss it, and the hashed email recovers the attribution. Leads flips the flow: you capture the hashed email when the form is submitted, and when that lead becomes revenue in your CRM weeks later, you report the sale back using the email as the join key — no GCLID spreadsheet gymnastics required.
If your revenue lands in a checkout, you want web. If it lands in a CRM after a human talks to the lead, you want leads. Some businesses legitimately need both.
What Actually Gets Sent
The payload is narrower than most privacy reviews expect:
- Email address — lowercased, whitespace trimmed, then SHA-256 hashed. This is the primary match key.
- Phone number — normalized to E.164 format (
+5511...), then hashed. - Name and address — optional, hashed field by field, used to improve match rates when email alone is weak.
The hashing happens before transmission — in the browser for tag setups, on your server for API setups. Google receives the hash, not the plaintext, and compares it against hashes it computed from its own signed-in users. A hash that matches no Google account matches nothing and attributes nothing.
Two honest caveats. First, hashing is not anonymization — Google can match the hash precisely because it holds the same emails on its side; that is the entire mechanism. Second, sending it still requires a lawful basis: your privacy policy must cover sharing hashed customer data with advertising platforms, and your consent management must gate it where regulations like GDPR or LGPD apply. Hashed does not mean exempt.
Two Setup Paths: Tag-Based vs. API
Tag-based is the fast lane. In Google Ads or Google Tag Manager you enable Enhanced Conversions on the conversion action, then either let automatic detection find the email field on your page or map it manually via CSS selectors or a dataLayer variable. You can be live in an afternoon. The fragility is structural: a checkout redesign that renames a field silently breaks the capture, and nothing alerts you.
API-based (server-side, through the Google Ads API) means your backend sends the hashed data after the order is actually confirmed. It is more engineering, and it is better in every way that matters at scale: it survives page redesigns, works when the checkout lives on another domain, lets you send only paid orders instead of attempted ones, and gives you a place to handle refunds. This server-side pattern — verified orders from your own checkout webhooks, pushed back to the platform — is the architecture Decisa uses for conversion pushback, because the order your payment provider confirmed is a strictly better signal than whatever a browser tag managed to observe.
Rule of thumb: tag-based to validate the value quickly, API-based as the destination.
Set It Up This Week
- Pick your variant — web for on-site checkouts, leads for CRM-closed revenue.
- Enable it on the conversion action in Google Ads and accept the customer data terms.
- Wire the data — map the email field in your tag setup, or have your backend send hashed data via the API on order confirmation.
- Check the diagnostics tab on the conversion action after a few days; it reports whether Google is receiving and matching your data.
- Update your privacy policy and consent flow so the hashed-data sharing is disclosed and gated properly.
Enhanced Conversions will not make your dashboard agree with your bank account — only first-party attribution does that. What it does is stop Google's bidding algorithm from flying half-blind on conversions that browsers ate. Feed it the truth, and it spends your money noticeably less wrong.