IAB's ECAPI rules let clean rooms take unhashed emails

IAB Tech Lab published the final guidelines for sending ECAPI events to data clean rooms on 3 November 2026. ECAPI, the Events and Conversion API, is the industry’s standard format for the conversion data an advertiser sends to ad platforms server to server. Its main spec requires email addresses and phone numbers as SHA-256 hashes. The new guidelines let you send them unhashed into a clean room, if the clean room enforces the same access limits by other means.

What the guidelines say

The guidelines cover one job: a bulk upload of ECAPI events into a clean room as Parquet files. They do not cover live tables, data shares, streams or APIs.

• Hashing becomes one option of several. Fields the spec marks as hashed “should remain hashed or may be encrypted”. Participants “may provide unhashed identifiers” without field or file encryption where the environment “provides technical controls that enforce the same restrictions on access”. Encryption in transit and at rest is still required.
• Raw values can be processed, not shown. An authorised workload can read the original email to normalise, validate, tokenise or match it. It cannot expose it in results, exports, logs or telemetry.
• Encryption is preferred over hashing in some cases. When the clean room validates data inside a Trusted Execution Environment with managed keys, the guidelines “strongly recommend” encryption, so the raw value exists only inside the enclave and the operator never sees it.
• The spec changes too. IAB Tech Lab put ECAPI v1.1, with clarifications on hashing and encryption, out for public comment the same day.

The read

The protection moves from the file to the room. A SHA-256 hash of an email or phone number was never strong protection. We hashed every US and Canadian phone number on one cloud machine in under six minutes. The guidelines accept that: what limits access is the environment, not the hash. So “we only send hashed data” stops being the answer to a privacy review. The question becomes what the clean room can show about who and what reads the raw values. Where an operator claims it is isolated from the data, the guidelines require that claim to be documented and “independently verifiable”. Ask for that document.

Match rates can go up, for a reason you can test. Hashing forces both sides to normalise the same way before the hash, or the same customer does not match. A clean room that receives the raw value can normalise it once, in one place. If you have a low match rate on hashed uploads, a raw upload inside a controlled environment is a test worth running, with your legal team in the room before the file is.

Two layout rules can change your numbers without an error. These are easy to miss:

• Row counts can overstate value. In the flat, one-wide-table layout, every combination of emails and phones becomes its own row. The guidelines’ own example is a $50 lead with two emails and two phones: four rows, each carrying 50.00. A query that sums the value column reports $200 for one $50 lead, a 4× overstatement, and nothing flags it. The recommended nested layout keeps one row per event. If you use the flat one, deduplicate on the event id before you sum anything.
• A partial upload looks like a slow week. The uploader must write an empty done file when a partition is complete, and the clean room must wait for it. Without it, the guidelines say, an incomplete partition gives “missing events, wrong aggregates” with no error. An attribution query that runs before the upload finishes undercounts.

One format, still not one integration. ECAPI standardises the shape of the data, not each platform’s requirements. The guidelines say “every major ad platform has proprietary fields” that matching and attribution depend on, and send you to each platform for them. The IAB post names no platform or clean room that has adopted the format.

What to do

1. Ask your clean room provider how it enforces access to raw identifiers, and whether that is documented and independently verified. That answer, not the hash, is your privacy position.
2. Check your upload layout. Flat files with several emails or phones per event multiply rows. Deduplicate on the event ID before any sum, and add a done marker to every partition.
3. Read ECAPI v1.1 while it is in public comment if your team builds conversion pipelines. The hashing rules are the part that changes.

Most of this rests on one point: a hash on its own does not make an email or phone number anonymous. How little protection does SHA-256 give a phone number, and why does a regulator still treat the hash as personal data? We tested it in a hashed phone number is a phone number with an extra step.