Skip to content
whitead

Enhanced Conversions

glossary google ads updated 2026.04.29 5 min read
// contents · 9 sections
  1. What Enhanced Conversions recovers
  2. EC for Web vs EC for Leads
  3. How to enable Enhanced Conversions
  4. Common misconceptions
  5. What are the privacy implications?
  6. Where does the hashing happen?
  7. Does EC replace the standard conversion tag?
  8. Related concepts
  9. Sources

Enhanced Conversions is two products: EC-for-Web hashes PII at conversion fire; EC-for-Leads matches GCLID with hashed email at offline close. B2B needs both.

What Enhanced Conversions recovers

Enhanced Conversions (EC) supplements the standard conversion tag with first-party customer data — email, phone, name, address — hashed SHA-256 in the browser and matched against signed-in Google accounts to recover conversions lost to cookie loss, cross-device journeys, and consent gaps. Google reports advertisers see +5% incremental conversions on Search on average after enabling EC (Google Ads Help, 2026-01-15), with mature deployments reaching +25% on YouTube (Conversios, 2025-09-12). Stacked with Consent Mode v2 Advanced and server-side tagging, combined recovery hits 30-50% of otherwise-lost conversions (Conversios, 2025-09-12). Hashing happens client-side, so raw PII never reaches Google.

EC for Web vs EC for Leads

The two variants share a name and a hashing standard but solve different problems. EC-for-Web supplements an on-site conversion; EC-for-Leads matches an offline closed-won event back to the original click — the standard play for B2B where conversion happens in a CRM weeks later.

Dimension EC for Web EC for Leads
Trigger On-site conversion (form submit, purchase) Offline event from CRM (closed-won, MQL)
Identifier Hashed user-provided data (email, phone, name, address) GCLID or hashed email/phone tied to original click
Implementation Google Tag, GTM, or server-side tagging Upload via Google Ads UI, OCI API, or CRM connector
Best for E-commerce, same-session lead-gen B2B, long sales cycles, multi-touch deals
Privacy First-party data hashed pre-transmission; not used for targeting Same hashing standard; raw PII never leaves CRM in plaintext

A typical B2B account needs both: EC-for-Web for real-time form-fill recovery, EC-for-Leads to feed Smart Bidding the closed-won signal that predicts revenue.

How to enable Enhanced Conversions

For EC-for-Web with Google Tag, navigate Goals → Conversions → Summary, open the conversion action, expand Enhanced conversions, toggle on, and choose Google tag as the source. For GTM, install Conversion Linker and enable user-provided data on the Google Ads tag. Verify in Tag Assistant: confirm the enhanced_conversions_data payload contains hashed em, ph, or addr fields, and that Match status shows ≥70% within 7 days. For EC-for-Leads, enable the same toggle but select Customer data, then upload conversions via the Google Ads UI, OCI API, or a CRM connector. Google began migrating Salesforce-native OCI to Google Ads Data Manager in 2025 — new Salesforce integrations should use Data Manager (Google Ads Help, 2025-10-08).

In Whitead audits, the most common EC failure is a missing one. EC-for-Web sits disabled on roughly half the accounts we onboard, and EC-for-Leads is absent from B2B accounts in ~70% of cases, even where the CRM exposes closed-won events trivially. The second failure is silent: EC is on, Google reports "Recording", but match rate sits at 30-40% because dataLayer pushes raw email_address into a field the tag is not reading. Healthy deployments show ≥70% match on Web, ≥85% on Leads. Anything below is a configuration bug — and the fix lives in the Tag Assistant payload, not the EC settings page.

Common misconceptions

EC supplements rather than replaces the standard conversion tag, and it does not push raw PII to Google. As Google's documentation states:

"Enhanced conversions uses a secure one-way hashing algorithm called SHA256 on your first-party customer data, such as email addresses, before sending to Google." (Google Ads Help, 2026-01-15)

What are the privacy implications?

EC uses first-party data the customer provided to you. Client-side SHA-256 hashing means Google receives only the hash. Hashes are matched against Google's own hashed signed-in user data; unmatched hashes are discarded. EC data is not used for ad targeting — only for attribution. If the user denies ad_storage under Consent Mode v2, no EC payload is sent.

Where does the hashing happen?

Client-side, in the browser, by the Google Tag or GTM container before the network request. For server-side tagging, the hash happens in your server container before forwarding to Google. Plaintext PII never reaches Google's edge. SHA-256 is the only accepted algorithm.

Does EC replace the standard conversion tag?

No. EC is layered on top of an existing conversion action. The base tag fires the conversion; EC enriches it with hashed user data. Disable the base tag and EC has nothing to enrich.

See Conversion Tracking for the base tag EC supplements, Consent Mode v2 for the consent layer gating EC transmission, and Smart Bidding for the strategy that consumes the recovered signal.

Sources

← Back to Wiki