IAB Tech Lab’s final ECAPI data clean room guidelines keep hashing or encryption as the default for fields the standard marks as SHA-256, then add another route. Participants “may provide unhashed identifiers without separate field-level or file-level encryption” where the delivery and execution environment has technical controls “that enforce the same restrictions on access to the original values”. The final text was committed to GitHub on October 28 and announced on November 3 as ready for implementers. On that route the identifiers in the file are neither hashed nor separately encrypted, yet the required label ecapi.hash_encrypted still offers only “sha256”, “encrypted” or “both”.
Can you send unhashed emails to a data clean room under IAB Tech Lab’s guidelines?
Conditionally, yes. The final text lets participants send unhashed identifiers without separate field-level or file-level encryption, but only where the delivery and execution environment enforces the same restrictions on access to the original values. Encryption in transit and at rest still applies, and processing them does not authorize their disclosure through collaborator-visible results, exports, logs or telemetry.
In its announcement, IAB Tech Lab says the guidelines cover data moving between systems, in Parquet files, “not how the data should be stored or processed within any specific system”. IAB Tech Lab calls them guidance, and the post names no company committed to implement it.
| Route | What the text says | What must be true |
|---|---|---|
| Hashed (SHA-256) | Fields “should remain hashed” | ECAPI v1.0 normalization first |
| Encrypted | “may be encrypted with technical controls” | Encrypted columns must use PME (section 4.2) |
| Unhashed | No “separate field-level or file-level encryption” | Environment enforces “the same restrictions”; encrypted in transit and at rest |
What changed in the ECAPI data clean room guidelines since July?
This is our own diff of the two commits: the July draft (3aab836, July 23) and the October update, “updates from public comment feedback” (October 28).
The July section 1 was titled “Hashing/Encryption Requirement”. It said a SHA-256 field “MUST be either SHA256 hashed” or encrypted before upload, and that values not encrypted, hashed “or otherwise appropriately protected MUST NOT appear in any Parquet file”. Both sentences are gone. So is the July fallback in section 4.2: with encryption but no TEE, values “SHOULD also be SHA-256 hashed” (ecapi.privacy_method = "both"), “so that raw values are never present even if encryption is bypassed or misconfigured”.
The October section 1 is titled “Identifier Protection and Collaboration Controls”. New text defines “plaintext identifiers” as values “that have not been hashed or separately encrypted at the field or file layer”, not “unprotected transmission or storage”. It adds that isolation from the infrastructure operator “is not a prerequisite”, and that “Sensitive plaintext data should always be protected before sharing with another party”, with hashing, trusted execution environments, query templates and redaction as examples. Several uppercase MUST and SHOULD also became lowercase.
Where does the final text contradict itself?
PPC Land spotted these leftovers, and we re-checked each against the file. Section 4.2 still says section 1 “requires that values designated for SHA-256 hashing by the ECAPI v1.0 standard be either hashed or encrypted before upload”. Section 1 now also permits the unhashed route.
The second is the metadata key. ecapi.hash_encrypted describes how the data was processed, and its values are “sha256”, “encrypted” and “both”. None describes unhashed identifiers delivered under environment controls. PPC Land also flagged a smaller slip: ecapi.layout asks which of “the 3 layouts” a file uses, while the document describes two (nested structs and a denormalized wide table).
Which ECAPI fields are hashed, and which are not?
By our count the schema designates nine fields for SHA-256: customer_identifier, email_address, phone_numbers, gender, uids.id, first_name, last_name, street and postal_code. IP addresses, user agents, ifa, click_id, impression_id, city and country_code are not designated.
The comparison with the ChatGPT Measurement Pixel’s unhashed fields needs care. That pixel documents nine user fields, five hashed and four unhashed geography fields (country, city, region, postal code). ECAPI leaves city and country unhashed too, but it designates postal_code for SHA-256. The pixel does not hash postal code.
How does this compare with the Google Ads Data Manager change?
Read it as a parallel; we do not claim either change follows the other. A Google Ads email says that from November 16 Data Manager stops requiring SHA-256 and supports encrypted data by default, decrypted, normalized and matched inside a hardware-isolated trusted execution environment. We covered Google Ads Data Manager’s move away from required SHA-256 hashing last month.
The email’s stated reasons are that the change “improves match accuracy” and “minimizes errors caused by formatting discrepancies prior to hashing”. IAB Tech Lab states no reason, but its example overlaps: original identifiers may go to an authorized workload for normalization, validation, tokenization or identity resolution “before hashing or another approved transformation”. Its “strongly recommend” line, encrypting rather than hashing when the clean room runs validation in a TEE, resembles the model in the Google email. The new plaintext route needs no field- or file-level encryption at all, while the email, as we reported it, describes encrypted data as the default.
What should teams uploading to clean rooms check?
- Get the clean room to state in writing which technical controls enforce the access restrictions, and which
ecapi.hash_encryptedvalue to use, since none fits. - Keep encryption in transit and at rest. “Plaintext” here means no separate field or file encryption.
- Permission to process is not permission to disclose. Processing the identifiers does not authorize showing them in collaborator-visible results, exports, logs or telemetry.
- In the wide layout, the guide’s example of 2 emails and 2 phones makes 4 rows, each showing value 50.00. Summing them gives 200.00 (our arithmetic; PPC Land ran the same sum). Send the event
idand deduplicate on it; the schema marks it optional. - Write the empty
donemarker; clean rooms “must not process a partition until the done marker is present”.
What is still open?
The announcement says the clarified hashing and encryption section is “available for public comment” as ECAPI 1.1. A GitHub issue for it was opened on October 28 and, when we checked on November 4, had no comments. No closing date is stated, and no implementers are named.
One question stays unanswered: whom do “the same restrictions on access” protect against? The text does not say explicitly; it says isolation from the infrastructure operator is not a prerequisite.