Two rules that appear to contradict
Every security primer says: never store an unsalted hash. Every ad platform's upload flow implies: give us plain SHA-256 of the normalised value. A developer meeting audience uploads for the first time reasonably asks which rule is wrong. Neither is – they are solving opposite problems.
What a salt is for
A salt is extra data mixed into the input before hashing, so that identical inputs produce different digests. That property is the whole point in credential storage: two users with the same password get different hashes, and precomputed lookup tables die. Salting is the standard because in that context, unlinkability is the goal.
Why matching needs the opposite
Audience matching works precisely because identical inputs produce identical digests. You hash john@example.com your way; the platform hashes its own record of john@example.com the same way; the digests collide; that collision is the match. Introduce a salt only you know and your digests match nothing on Earth – a perfectly secure list of zero matched users. Deterministic, unsalted hashing is not a platform being lazy about security; it is the mechanism doing its job.
The consequence you have to own
An unsalted digest of a small keyspace is weak by construction. Phone numbers especially: enumerate the national numbering plan, hash it all, and the "anonymised" column reads like plaintext to anyone with the table. This is not fixable – the weakness and the matching are the same property. So the handling rule follows: an upload file is transport formatting, not protection. Access-control it, share it deliberately, delete it when the campaign is done. (The longer argument is in our hashing-is-not-anonymisation guide.)
Where each rule applies, in one table
| Context | Salt? | Why |
|---|---|---|
| Passwords, credentials | Always | Unlinkability; kill lookup tables |
| Ad-platform audience uploads | No | Matching requires deterministic digests |
| Internal pseudonymised analytics | Keyed/salted | You control both sides, so use a secret key |
The third row is worth the aside: when you are both hasher and matcher – joining datasets inside your own systems – there is no platform to match against, and a keyed hash gets you real protection. Reserve bare SHA-256 for the uploads that require it.
Where Hash Data fits
Hash Data produces the standard digests audience uploads expect, inside Google Sheets – several algorithms as formulas, =HASHPHONE() normalising to E.164 and hashing in one step. What it cannot change is the physics above – which is why this page exists next to the product rather than pretending otherwise.
→ Hash Data on the Google Workspace Marketplace
Sources
- EDPB Guidelines 01/2025 on Pseudonymisation – read 2026-08-20