Google Ads

Google Ads Enhanced Conversions Leads Hashing Normalization

HandL WP Engineering·Jul 5, 2026

Enhanced conversions for leads need user-provided data normalized before hashing. Email case, Gmail dots, plus tags, phone formats, whitespace, and consent fields can all affect match quality and upload eligibility.

Use this for WordPress lead forms, Elementor Forms, Gravity Forms, CRMs, server-side uploads, and Data Manager API workflows that send first-party user identifiers to Google Ads.

Quick answer

Google Ads Enhanced Conversions Leads Hashing Normalization should be handled with a narrow evidence-first workflow: trim and lowercase, normalize email rules, format phone numbers, then verify the result before making broader changes.

What to check first

Trim whitespace, lowercase email values, and apply Google-specific Gmail and googlemail normalization before hashing where required.
Normalize phone numbers to E.164 where possible and keep country assumptions explicit.
Separate raw fields, normalized fields, hashed fields, consent state, suppression reason, and upload status.
Do not hash blank, placeholder, test, or denied-consent values into the upload payload.
Log accepted, rejected, and skipped rows with enough detail to debug match quality later.

Diagnostic table

Use this table to keep the work practical. It connects the symptom to evidence and a verification step.

Action	Evidence to collect	How to verify
Trim and lowercase	Trim whitespace, lowercase email values, and apply Google-specific Gmail and googlemail normalization before hashing where required.	Normalized values are produced before hashing and before upload payload creation.
Normalize email rules	Normalize phone numbers to E.164 where possible and keep country assumptions explicit.	Denied or unknown-consent leads are suppressed with a reason.
Format phone numbers	Separate raw fields, normalized fields, hashed fields, consent state, suppression reason, and upload status.	Rejected rows distinguish bad formatting from policy suppression.
Apply consent	Do not hash blank, placeholder, test, or denied-consent values into the upload payload.	Accepted uploads reconcile to CRM qualified lead counts and Google Ads diagnostics.

Why this usually happens

A form stores `John.Doe+Quote@gmail.com` and the upload hashes it exactly as entered.
Phone numbers are uploaded with local formatting and no country normalization.
Consent logic runs in the browser but the server upload queue does not read it.
A CRM export includes test leads, duplicates, or placeholder emails.
Teams save only the hash and cannot prove which normalization rule produced it.

Field notes

Keep raw values only where policy and retention rules allow it. If raw values are sensitive, document the normalization step before hashing.
Never add a salt to data meant for Google matching unless the destination explicitly supports it.

Useful command or data shape

Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.

identifier_normalization:
  lead_id: EL-22104
  email_raw: John.Doe+Quote@gmail.com
  email_normalized: johndoe@gmail.com
  phone_raw: (312) 555-0199
  phone_normalized: +13125550199
  consent_ad_user_data: granted
  hash_algorithm: SHA256_HEX
  upload_status: eligible

Safe fix order

Do the work in a sequence that makes each result easy to prove. Stop if a step produces new evidence that changes the incident scope.

Trim and lowercase
Normalize email rules
Format phone numbers
Apply consent
Log skipped rows

What to tell the client or owner

Explain to the marketing team that match quality depends on both consent eligibility and identifier normalization, not only whether hashing is turned on.

Production verification checklist

Normalized values are produced before hashing and before upload payload creation.
Denied or unknown-consent leads are suppressed with a reason.
Rejected rows distinguish bad formatting from policy suppression.
Accepted uploads reconcile to CRM qualified lead counts and Google Ads diagnostics.

Mistakes to avoid

Do not judge the fix by one browser or the homepage only.
Do not delete evidence before recording usernames, file paths, timestamps, and response headers.
Do not add a cache, security, or tracking plugin while the original problem is still unclear.
Do not leave test users, temporary debug logs, or broad API keys active after verification.

When HandL WP should help

Bring in help when this affects leads, checkout, search visibility, malware risk, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.

If this is active on a production site, audit enhanced conversions for WordPress leads.

Related HandL WP guides

Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.

Helpful references

Google Ads Enhanced Conversions Lead Tracking