The platform will not tell you what went wrong
Google's API documentation states the failure mode outright: incorrectly formatted data is still accepted – "but it can't be matched with a customer." Accepted and unmatched looks exactly like uploaded and ignored. So diagnosis is on you, and the causes below are ordered by how cheap they are to check.
1. You reused one hashed column across platforms (30 seconds)
Google Ads documents E.164 phones with the +; Meta documents digits-only with country code – its example is 16505551212. The same number, hashed both ways, gives two unrelated digests, and only one platform can match each. If one platform matches fine and the other barely at all, this is almost certainly it.
2. You hashed the display value (1 minute)
(650) 555-1212 is not 16505551212, and John@Example.com – capital letters, trailing space – is not john@example.com. Both platforms document lowercase and trimmed; check one cell's actual content against what you think you hashed. Watch for the non-breaking space: TRIM() does not remove it, and CSV exports plant it invisibly.
3. Double-hashing or truncation (1 minute)
A SHA-256 hex digest is exactly 64 characters. =LEN(B2)=64 down the column catches a formula run over already-hashed values (128 characters of nonsense in, digest of a digest out) and truncated cells in one pass.
4. Wrong encoding (5 minutes)
Base64 output, or uppercase hex where lowercase is specified – Meta documents lowercase hex explicitly. The clean test: hash Meta's published test value john_smith@gmail.com and compare against its published digest (62a14e44…f62f). Wrong shape or wrong case out of that test means the tool, not the list.
5. The spreadsheet destroyed the data first (10 minutes)
Leading zeros dropped, long numbers in scientific notation, +44 cells parsed as formulas – all silent, all before hashing. Scroll the raw column looking for E+ and suspiciously short numbers. This one is not fixable in place: re-import into a plain-text column and rebuild.
6. Platform-specific rules skipped (10 minutes)
Google documents Gmail-specific email cleanup – dots and + suffixes stripped for gmail.com/googlemail.com addresses only. A list heavy in Gmail addresses, normalised generically, underperforms on exactly those rows.
7. It was never a formatting problem
Honest last section: matching happens against the platform's signed-in users. A stale list, a small list, or a list of role addresses (info@, accounts@) matches poorly no matter how perfect the hashing. If steps 1–6 all pass, the fix is list quality – recency and real personal addresses – not another formatting pass.
Where Hash Data fits
Most of the failures above happen in the gap between "normalise correctly" and "hash correctly". Hash Data closes that gap inside the sheet – =HASHPHONE() normalises a number to E.164 and hashes it in one step, and the algorithm functions output the standard hex form the platforms expect.
→ Hash Data on the Google Workspace Marketplace
Sources
- Google Ads API – Get started with Customer Match – read 2026-08-20
- Google Ads Help – Format your customer data file – read 2026-08-20
- Meta – Conversions API customer information parameters – read 2026-08-20