Hashed email audiences, without the mystery.

Ad platforms let you upload a list of people you already have a relationship with, so you can show them ads, exclude them, or find similar people. Meta calls these custom audiences; Google calls the feature Customer Match. Instead of uploading plain addresses, you upload a hash of each one.

A hash is a fixed-length fingerprint produced by a one-way function. SHA-256, the function these platforms use, always turns the same input into the same 64-character hex string, and a tiny change in the input produces a completely different output. The platform hashes its own users' addresses the same way and looks for matching fingerprints.

Because the hash only matches if the input is exactly the same, character for character. Jane@Acme.com and jane@acme.com are the same mailbox but produce different hashes. So both sides agree to normalise addresses before hashing:

• Trim leading and trailing spaces.
• Lowercase the whole address.
• Google only: for gmail.com and googlemail.com addresses, remove the dots in the part before the @, because Gmail ignores them. jane.doe@gmail.com becomes janedoe@gmail.com before hashing.

Get one rule wrong and those rows simply do not match. Nothing errors; your audience is just smaller than it should be. Check each platform's current documentation before an upload, since the rules are theirs to change.

Keep the hashes in a consistent form too: SHA-256 output written as lowercase hex. Do not hash an address twice, and do not hash a column that has already been hashed by another tool. A double-hashed row looks fine and matches nothing.

It also pays to clean the list first. Hashing a typo produces a perfectly valid hash that matches nobody. Running the list through an email verification API removes dead and mistyped addresses before they waste rows.

No. This is the most common misunderstanding. A hash of an email address is pseudonymised data: it no longer shows the address, but anyone with a list of addresses can hash them and see which ones match. That is exactly what the ad platform does. Email addresses are not random enough to be protected by hashing alone, so a determined party can often reverse common ones by guessing.

Under laws like the GDPR, pseudonymised data is still personal data. All the usual rules apply: you need a lawful basis to process it, you need to have told people how their data is used, and you must honour objections and deletion requests. Hashing reduces risk in transit and storage. It does not change what you are allowed to do.

The platforms' own terms require that you have the right to share the data for advertising, which usually means the people on the list are your customers or subscribers and your privacy notice covers ad matching. In many places, including the EU and UK, using personal data for targeted advertising needs consent. In US states with privacy laws, sharing data for cross-context behavioural advertising can trigger opt-out rights.

In practice: only upload people who gave you their address directly, whose consent or notice covers this use, and who have not opted out. Remove unsubscribes and deletion requests before every upload. Never upload bought or scraped lists. The compliance page covers how Ravn handles opt-outs, and the compliance guide explains the main laws.

Not as ready-made lists. Ravn doesn't sell bulk lists of people, and mobile advertising ID audiences aren't available yet. The audience command only reshapes and hashes a file you already have, on your own computer. Your list is your data, and the consent behind it is yours to manage.