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.
Apply the normalization fixture to Elementor fields
For Elementor lead forms, use the Elementor enhanced conversions field test to map stable field IDs, preserve consent and lead IDs, compare hashes through the CRM path, and prove retry deduplication.
Normalize international phone numbers before hashing
Use the Google Ads international phone country normalization guide to capture country context, produce valid E.164, separate extensions, and hash the final value once.
Calculate the value of trend traffic before upload
The Outbid.lol CPC and qualified-lead calculator turns campaign cost, verified sessions, lead quality, contribution value, and tracking readiness into a maximum bid and written stop rule.
Add mailbox and digest-representation fixtures
Use the enhanced-conversions email plus-alias normalization test before adding provider-specific rules. If two SHA-256 implementations still disagree, run the hex versus Base64 digest mismatch test against the final serialized upload field.
Version the rule that owns normalization
Prevent the browser, WordPress, CRM, queue, and backfill code from drifting with the enhanced conversions email normalization contract version audit. It compares normalized UTF-8 bytes, digest representation, consent, and historical replay across every runtime.
Helpful references