Also called: SHA-256 hashing, advanced matching, hashed email, PII hashing
Normalisation must happen before hashing, and the rules are platform-specific but broadly consistent: lowercase everything, trim whitespace, format phone numbers as E.164 with a leading plus, strip formatting characters. "User@Example.com " and "user@example.com" produce completely different hashes, so an un-normalised pipeline silently matches nothing.
Hashing constrains what the recipient can do with the value; it does not make the value non-personal. Under GDPR a hashed email that can be linked back to an individual is still personal data, and it still requires a lawful basis to share.
Hashing must happen before transmission. Sending a raw email to a vendor and relying on them to hash it defeats the purpose entirely and is a reportable disclosure in most privacy frameworks.
Hashed identifiers are how conversion measurement survives the loss of cookies — and un-normalised hashing is the failure that looks like it is working (events send, no errors) while matching essentially zero users.
Generally yes. European regulators treat hashing as pseudonymisation rather than anonymisation, because the hash still singles out an individual and can be matched. It reduces risk; it does not remove the need for a lawful basis.
Almost always normalisation. Case, leading or trailing whitespace, and Gmail dot variants each produce a different hash. Normalise to lowercase, trim, then hash — and verify against a known-good test hash before shipping.
TagEasy's free auditor checks any URL for Consent Mode v2 signals, PII in tracking, duplicate pixels, and 10 other tracking-quality faults. No signup.
