Enhanced conversions for WordPress leads can under-match when email, phone, name, and address fields are hashed before they are normalized. Build test cases so the form, CRM, and upload job transform fields consistently.
Use this for Google Ads enhanced conversions, Data Manager API uploads, Elementor, Gravity Forms, Contact Form 7, WPForms, and custom CRM integrations.
Quick answer
Enhanced Conversions User Data Normalization Test Cases should be handled with a narrow evidence-first workflow: create test cases, normalize before hashing, match client and server, then verify the result before making broader changes.
What to check first
- Create test leads with uppercase email, spaces, phone punctuation, country codes, accent marks, and empty optional fields.
- Normalize fields before hashing and store a non-personal test result for QA.
- Check whether browser-side and server-side normalization rules match.
- Suppress restricted user data when consent or policy does not allow upload.
- Compare upload diagnostics before and after normalization fixes.
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 |
|---|
| Create test cases | Create test leads with uppercase email, spaces, phone punctuation, country codes, accent marks, and empty optional fields. | Each synthetic test lead produces the expected normalized field values. |
| Normalize before hashing | Normalize fields before hashing and store a non-personal test result for QA. | Client and server code do not hash different versions of the same field. |
| Match client and server | Check whether browser-side and server-side normalization rules match. | Denied consent suppresses user data before hashing or upload. |
| Respect consent | Suppress restricted user data when consent or policy does not allow upload. | Upload diagnostics improve without changing the meaning of the conversion action. |
Why this usually happens
- Different plugins normalize phone numbers and names differently.
- A CRM may trim fields after the website already captured the original value.
- Hashing too early hides the source field mistake.
- Consent and normalization are often handled in different code paths.
Field notes
- Use synthetic test data, not real customer personal data, for normalization QA.
- Log pass or fail for each field class without storing raw sensitive values in shared files.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
test_case:
raw_email: ' Test.User+Lead@Example.COM '
normalized_email: 'test.user+lead@example.com'
raw_phone: '(512) 555-0199'
normalized_phone: '+15125550199'
consent_state: granted
expected_upload: allowed
field_owner: form_tracking
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.
- Create test cases
- Normalize before hashing
- Match client and server
- Respect consent
- Compare diagnostics
What to tell the client or owner
Give marketing the test cases and explain which field format was limiting enhanced conversion matching.
Production verification checklist
- Each synthetic test lead produces the expected normalized field values.
- Client and server code do not hash different versions of the same field.
- Denied consent suppresses user data before hashing or upload.
- Upload diagnostics improve without changing the meaning of the conversion action.
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, fix enhanced conversion matching.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references