When you activate first-party data, customer identifiers leave your systems and travel to ad platforms. Two techniques protect them on that trip: hashing and encryption. They get used interchangeably in marketing conversations, and they should not be, because they do different jobs and fail in different places.
Two techniques, two jobs
Hashing is one-way. A hash function like SHA-256 turns an email address into a fixed-length string, and there is no key that turns it back. Encryption is two-way. It scrambles data into ciphertext that only a holder of the right key can read, which is exactly what you want for data that someone legitimate must eventually read.
That difference decides where each belongs in a marketing pipeline.
Hashing: protect the identifier itself
Meta, Google, Snap, and TikTok all match conversion events to people using identifiers like email and phone number, and all of them accept those identifiers as SHA-256 hashes. The platform hashes the identifiers on its side the same way, matches hash to hash, and never needs the raw value.
The practice that matters is hashing at source: the identifier is hashed on your infrastructure, before delivery, so the raw email or phone number never leaves your environment. Datahash hashes identifiers with SHA-256 at source, and no PII is stored on host servers in Datahash Cloud.
What hashing does not do: it is not anonymization. Anyone who already holds the same email can compute the same hash, which is precisely why matching works. Hashing protects the identifier from parties who do not already know it. It does not restrict what a matching party does after the match, and it does nothing for the rest of the payload, such as order values or event details, which are not hashed.
Encryption: protect the data in motion and at rest
Everything in the pipeline, hashed or not, should travel encrypted and sit encrypted. Encryption in transit, via TLS on every connection, means an intercepted transfer yields unreadable ciphertext instead of customer records. Encryption at rest means a copied disk or leaked storage bucket yields the same nothing. The strength of the approach is that it protects data without changing it: systems decrypt, process, and re-encrypt, and the data itself stays intact for the work it exists to do.
What encryption does not do: it stops protecting at the endpoint. Once a system with the key decrypts the data, encryption has done its job, and access controls take over. Encryption also says nothing about whether the party you sent the data to should have received it in the first place. That is a governance question, and no algorithm answers it.
Data does not flow in a vacuum
The original version of this post made a point that still holds. Data is processed, stored, copied, and transferred between many systems, and each hop adds exposure. The systems are the vulnerable part, not the data. So the useful question for any pipeline is: at every hop, is the identifier hashed, is the channel encrypted, is the storage encrypted, and who holds the keys?
That question is also how to evaluate any vendor that touches your customer data. Ask where hashing happens, what is encrypted in transit and at rest, and what certifications back the answers. Datahash is SOC 2 Type II certified, and our practices are documented on the security page. GDPR and CCPA both reward this discipline: the less raw PII that moves and rests in your pipeline, the smaller your breach surface and your compliance exposure.
Hash at source, encrypt everywhere, and know where each protection stops.
Talk to solutions engineering to review how identifiers move through your current setup.