Hashed customer data
Also known as: hashing, SHA-256 hashing, advanced matching, customer information parameters
Hashed customer data is the customer details attached to an event after they have been run through a one-way function, usually SHA-256, so the ad platform receives a fixed-length string rather than the email or phone number itself. The platform hashes its own records the same way and compares the two strings.
Why hash the data at all if the platform can still match it?
Matching and reading are different things. The platform can tell that two hashes are equal without being handed the address that produced them, and nothing readable crosses the wire or sits in a log. It narrows what a leak anywhere along the path would expose.
Why does normalisation decide whether hashing works?
Because hashing is exact. "Jane@Example.com " and "jane@example.com" produce completely different hashes, so a mismatch in trailing spaces or capitals is a match silently lost. The details have to be lowercased, trimmed, and phone numbers put in international format before hashing, every time, on both sides.
Is hashed data still personal data?
Treat it as though it is. A hash is not encryption and it is not anonymisation: the same input always gives the same output, so a hash still identifies a person to anyone holding the matching record. It reduces exposure; it does not remove the obligation to handle it carefully.
Sources
- Meta requires customer information parameters such as email and phone to be normalised and hashed with SHA-256 before they are sent to the Conversions API.Meta for Developers
- wesaw normalises and hashes on its own servers and never in the browser, and attaches fourteen match parameters per purchase where a default setup attaches four.wesaw, own test store
Last reviewed: