How hashing works
An algorithm, usually SHA-256 in advertising, takes any input and produces a fixed-length string of characters. The same input always produces the same output, and the process cannot be run backwards to recover the original. That combination is what makes matching possible: you hash your customer’s email address, the platform hashes the address it holds, and if the two strings are identical it is the same person — without either side handing over anything readable.
Everything depends on doing exactly the same preparation on both sides. Trim spaces, convert to lower case, remove dots and plus-tags where the platform’s specification says to, and put phone numbers into the international format it asks for. Miss one step and the same person produces two different strings and never matches. Exported lists from local systems are a frequent culprit, because phone numbers are often stored without the country code.
Why hashing matters
It is what makes customer-list features work at all. Customer Match in Google Ads, custom audiences in Meta, and enhanced conversions all rely on it, which means it sits underneath most retention, exclusion and lookalike work. It also limits the damage if a file goes astray, because a hashed column is far less useful to anyone who finds it than a column of addresses.
But it is important to be precise about what it does not do. A hash of an email address still points to one person and is treated as personal data under most privacy laws. It is pseudonymisation, not anonymisation, so consent, notice, retention and deletion obligations all continue to apply to the hashed file exactly as they did to the original.
Where hashing goes wrong
The belief that hashing removes legal duties is the costly one, and it usually surfaces when someone asks for deletion and nobody can find them in the uploaded audience.
The technical faults are duller. Hashing without normalising first, which quietly destroys match quality. Hashing an already-hashed value because two tools in the chain both did the job. Uploading raw data on the assumption the platform will hash it, when some interfaces do that in the browser and others do not. Hashing the wrong field, such as a display name instead of the address. And treating a weak match as proof the customer list is bad, when formatting is the usual explanation.
How to act on it
Read the receiving platform’s normalisation specification before you touch the file, because the details differ between them and a rule copied from one will fail on another. Do the hashing in your own system or with the platform’s official upload tool rather than a random web page, since pasting customer addresses into an unknown site defeats the purpose entirely.
Test with a small list of records you can verify before you upload the whole database, keep your own readable source securely so you can honour deletion requests, and check that your privacy notice tells people their details may be shared in hashed form with advertising platforms. If matching stays poor, look at formatting before you blame the data.