# Why Your Ad-Platform Match Rate Is Low

> The upload worked, the audience is tiny. Work through these causes in order – most low match rates are one formatting mistake, found in under ten minutes.

- Source: https://www.8apps.co/blog/customer-list-match-rate-low
- Markdown: https://www.8apps.co/blog/customer-list-match-rate-low.md
- Published: 2026-09-02
- Author: 8apps Team
- Language: en

---
## 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](/google-workspace/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.

## Sources

- [Google Ads API – Get started with Customer Match](https://developers.google.com/google-ads/api/docs/remarketing/audience-segments/customer-match/get-started) – read 2026-08-20
- [Google Ads Help – Format your customer data file](https://support.google.com/google-ads/answer/7659867) – read 2026-08-20
- [Meta – Conversions API customer information parameters](https://developers.facebook.com/docs/marketing-api/conversions-api/parameters/customer-information-parameters/) – read 2026-08-20