A phone number such as 020 7946 0958 cannot be normalized safely without country context. Removing punctuation and hashing the remaining digits can produce an invalid identifier, especially for trunk prefixes, extensions, shared forms, and users who type an international prefix inconsistently.
Use this for WordPress lead forms, WooCommerce checkout, CRM imports, call funnels, and server-side Google Ads enhanced conversion uploads that accept phone numbers from more than one country.
Quick answer
Capture or infer country before normalization, parse the number with a proven phone library, remove extensions from the match identifier, produce a valid E.164 value, then hash that exact normalized value with SHA-256. Reject or quarantine ambiguous numbers instead of inventing a country code.
What to check first
- Identify whether country comes from a required field, selected dial code, billing address, or trusted market context.
- Parse national prefixes, plus signs, IDD prefixes, spaces, punctuation, and extensions with a maintained library.
- Validate that the result is possible for the selected country before producing E.164.
- Hash only after normalization and keep raw phone access tightly controlled.
- Test representative countries, short codes, malformed input, extensions, and already hashed values.
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Add a reliable country source to the form or checkout contract. | Identify whether country comes from a required field, selected dial code, billing address, or trusted market context. | Every accepted fixture produces the expected E.164 value before hashing. |
| Parse and validate with a maintained international phone library. | Parse national prefixes, plus signs, IDD prefixes, spaces, punctuation, and extensions with a maintained library. | Ambiguous and malformed fixtures are rejected without a fabricated country code. |
| Separate extensions from the Google Ads match identifier. | Validate that the result is possible for the selected country before producing E.164. | The Google Ads payload contains the SHA-256 hash in the correct identifier field. |
| Hash the final E.164 value once and label already hashed inputs. | Hash only after normalization and keep raw phone access tightly controlled. | Logs expose reason codes and hash prefixes for QA, not raw phone values. |
Why this usually happens
- Frontends display a country flag without submitting the actual dial code or ISO country.
- String cleanup removes punctuation but does not understand national trunk prefixes.
- A pipeline hashes too early, making format defects impossible to diagnose or correct.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
input: '(020) 7946 0958 ext 42'
country_source: form_country_field
country: GB
extension: '42'
normalized_e164: '+442079460958'
sha256_input: '+442079460958'
upload_field: hashed_phone_number
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| US national format | (800) 555-0200 with US country | +18005550200 then SHA-256 |
| UK national format | 020 7946 0958 with GB country | +442079460958 then SHA-256 |
| International input | +49 30 901820 with DE context | Valid E.164 preserved then hashed |
| Ambiguous input | Local digits without country | Quarantined with reason, not guessed or uploaded |
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Add a reliable country source to the form or checkout contract.
- Parse and validate with a maintained international phone library.
- Separate extensions from the Google Ads match identifier.
- Hash the final E.164 value once and label already hashed inputs.
- Run fixture uploads with partial-failure logging and rejection counts.
Decision rule
Upload only when the parser produces a valid E.164 value from explicit country context. Quarantine ambiguous or invalid values with a reason code. Never guess a country from language or IP when the business needs reliable matching.
Production verification checklist
- Every accepted fixture produces the expected E.164 value before hashing.
- Ambiguous and malformed fixtures are rejected without a fabricated country code.
- The Google Ads payload contains the SHA-256 hash in the correct identifier field.
- Logs expose reason codes and hash prefixes for QA, not raw phone values.
Field notes
- Keep an explicit normalization version so changes can be compared over time.
- Do not log raw phone numbers in analytics or general application logs.
- Store rejection reason and country source separately from the normalized hash.
Questions teams ask during testing
Does Google Ads require E.164?
Google's API guidance says phone numbers should be formatted according to E.164 before SHA-256 hashing.
Can the billing country be used?
It can be a useful explicit source when the form contract and business workflow make it trustworthy for that phone.
What happens to extensions?
Keep them for call operations if needed, but exclude them from the normalized phone identifier sent for matching.
Mistakes to avoid
- Do not strip punctuation and assume the remaining digits are E.164.
- Do not include an extension in the hashed phone identifier.
- Do not hash before country-aware parsing and validation.
- Do not upload the same value once raw and once hashed.
What to tell the client or owner
Provide country source, parser version, normalization version, accepted and rejected fixture counts, reason codes, and upload partial-failure results without exposing raw phone data.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, security, 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 phone matching.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references