IAB Tech Lab on November 3, 2026 published the final version of its Guidelines for Providing ECAPI Events to Data Clean Rooms, which set out how advertisers should package server-side conversion data in Parquet files before loading it into a clean room. The final text departs from the draft opened for comment in August on a point that matters more than the file format: participants may now provide unhashed customer identifiers, without separate field-level or file-level encryption, where the delivery and execution environment enforces the same access restrictions through technical controls. Alongside the guidelines, the organisation opened a new hashing and encryption section of version 1.1 of the underlying ECAPI standard for public comment.

In Short

When advertisers want to know whether their ads led to sales, they often send records of purchases and sign-ups to a "clean room," a locked-down system where two companies can compare data without handing it to each other. An industry standards group has now finished a rulebook for how those records should be formatted and labelled, so that every company sends them the same way. The biggest change from the earlier draft is that companies may send customers' email addresses and phone numbers without scrambling them first, as long as the receiving system technically stops the other side from seeing the raw values.

What IAB Tech Lab published

The announcement came in a blog post under the byline of Jill Wittkopp, VP, Product at IAB Tech Lab, headed "Guidelines for Providing ECAPI Events to Data Clean Rooms Ready for Implementers." It opens on a familiar theme for the organisation this year: "Yes, we're still talking about outcomes and how specific events are critical from a measurement and optimization perspective for campaign performance."

ECAPI, the Event and Conversion API, is IAB Tech Lab's shared schema for sending marketing events such as purchases, leads and sign-ups from an advertiser's systems to ad platforms and partners. According to the post, "The first ECAPI standard was released in April 2026 and focused on server to server transmission of conversion data." The new document covers the other common route for the same data. "Another common use case in digital advertising for providing this data set is through data clean rooms," the post states, "So these guidelines were developed by the ECAPI Working Group to ensure a common object format and data schema are shared between collaborators."

The guidelines are published on GitHub, in the same repository as the ECAPI specification, where they run to 270 lines. During the comment period they sat on a separate branch named dcr-guidelines. The final version now sits on the repository's main branch.

The scope is deliberately narrow. According to the executive summary, "The guidelines focus on data moving between systems, not how the data should be stored or processed within any specific system." The document deals only with formatting for bulk input into a clean room, and it is built around Apache Parquet, a columnar file format, "as it's already an industry accepted standard for this method." Other delivery routes are named and set aside: "live tables, governed shares, catalog references, streams or APIs." Those methods, the document says, "may have different requirements and are not covered in this document."

Neither the blog post nor the guidelines name a contributor, a clean room operator or a company that has committed to implement the format. The post's headline describes the document as ready for implementers; it does not identify any. Its closing paragraph refers to an "eager reception for standardization around ECAPI events and integration methods" without giving figures.

From draft to final: the identifier question

When IAB Tech Lab opened the draft for comment, with a September 4 deadline, its rule on personal identifiers was strict. Values that ECAPI v1.0 designates for SHA-256 hashing - email addresses, phone numbers, names, street addresses and postal codes among them - had to be hashed under the standard's normalization rules or encrypted before upload. Values that were neither hashed, encrypted nor otherwise protected were not to appear in any file delivered to a clean room. Where no attested secure environment was involved, the draft added, values should be hashed as well, so that raw values would never be present even if encryption were bypassed or misconfigured.

The final version keeps the opening principle. "Per the ECAPI specification, fields designated SHA256 hashed should remain hashed or may be encrypted with technical controls in data clean room use cases," Section 1 states. The next paragraph has no counterpart in the draft as PPC Land reported it in August:

"For additional clarity regarding providing ECAPI events to data clean rooms, participants may provide unhashed identifiers without separate field-level or file-level encryption where the delivery and execution environment provides technical controls that enforce the same restrictions on access to the original values."

The document then defines its terms. "In this context, 'plaintext identifiers' means values that have not been hashed or separately encrypted at the field or file layer; it does not mean unprotected transmission or storage. Encryption in transit and at rest must still protect those values."

What the raw values are for

The guidelines give an example of why a clean room might want the original value rather than a hash: "original identifiers may be made available to an authorized workload for normalization, validation, tokenization, or identity resolution before hashing or another approved transformation."

The practical logic is that a hash cannot be repaired after the fact. ECAPI already requires email addresses to be lowercased and trimmed before hashing, and phone numbers to be stripped of symbols, letters and leading zeros and given a plus-prefixed country code. An advertiser that hashes an address with a stray capital letter or trailing space produces a value that will never match the same address hashed correctly elsewhere. With access to the original, an authorized workload inside the clean room can apply the normalization itself, and can run identity resolution across several identifiers before anything is hashed.

The permission comes with a limit on output. "Permission to process those identifiers does not authorize their disclosure through collaborator-visible results, exports, logs, or telemetry," according to the guidelines.

Two layers of protection, only one required

The final text also draws a distinction between the collaborating party and the company running the infrastructure. "Isolation from the infrastructure operator can provide additional assurance for these workflows," the document states. "Where that assurance is claimed, its scope and enforcement mechanisms must be documented and independently verifiable."

The following sentence settles what is mandatory: "Infrastructure-operator isolation is separate from collaborator access controls and is not a prerequisite for using the alternatives described above." Read literally, the plaintext route requires that the counterparty cannot reach the original values. It does not require that the clean room operator be technically unable to reach them. The guidelines do not say which parties the phrase "the same restrictions on access to the original values" is meant to cover.

That leaves one strong preference intact from the draft. "We strongly recommend encrypting rather than hashing when the DCR runs validation workflows in a Trusted Execution Environment (TEE) with KMS-based key wrapping (KEK/DEK model), where the TEE obtains decryption access via workload attestation," according to Section 4.2. "This ensures raw values are only accessible inside the attested enclave and never exposed to the DCR operator."

The draft's fallback instruction, to hash values as well whenever no attested environment is involved, does not appear in the final text. In its place is a broader sentence: "Sensitive plaintext data should always be protected before sharing with another party. Examples of protection include: hashing, trusted execution environments, query templates, redaction." Two of the four examples, query templates and redaction, are governance controls on what can be asked and returned, rather than transformations of the data itself.

Loose ends in the final text

The new allowance in Section 1 has not been carried through the rest of the document. Section 4.2 still opens with the draft's logic: "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 no longer says only that.

The metadata key that records how identifiers were treated has the same gap. Every file must declare ecapi.hash_encrypted, and the guidelines list three permitted values: "sha256", "encrypted" and "both." None describes a file carrying unhashed identifiers under environment-level controls, which is the route Section 1 now permits.

One inconsistency from the draft has been fixed. PPC Land's August report noted that the draft used two different names for that key, ecapi.hash_encrypted in its metadata table and ecapi.privacy_method in its encryption section. The final version uses only ecapi.hash_encrypted.

Another has appeared, or survived. The ecapi.layout key is described as recording "Which of the 3 layouts this file uses," and the schema appendix is headed "Option B (Nested Structs)." The document describes two layouts.

ECAPI 1.1 goes to comment

The blog post ties the release to a change in the core standard. "As part of the guidelines release, we've also made clarifications in the ECAPI standard regarding hashing and encryption," it states, adding that the new section is available for public comment as ECAPI 1.1.

The link leads to an issue in the GitHub repository titled "ecapi 1.1 Public Comment," opened by Wittkopp on October 28, 2026, six days before the blog post. The issue says a "Hashing & Encryption" section has been added and points to the specification on the repository's development branch. Neither the issue nor the blog post gives a closing date for comments, and the issue showed no public comments on November 4.

The ECAPI page on IAB Tech Lab's own site lagged behind both. As of November 4 it made no mention of version 1.1 and still listed the clean room guidelines as being in public comment, with a link to the draft branch.

Version 1.0 followed a conventional path. Its public comment period closed on February 20, 2026, and IAB Tech Lab announced the final specification in a post dated April 28, 2026. PPC Land reported the finalized ECAPI 1.0 on May 3, 2026, listing contributors from Meta, Google, Walmart, TikTok, Roku, NBCUniversal and Paramount. The April 28 post explains the April release date the guidelines cite, which PPC Land's August report had flagged as earlier than its own May coverage.

The file format in detail

The rest of the document is an engineering specification, and it is specific.

ECAPI events contain what the guidelines call "nested, variable-length data: an event can have multiple email addresses, multiple items, multiple addresses." Parquet can store that in more than one way.

The recommended format is nested structs under Dremel encoding, Parquet's native method for hierarchical data. "Preserves the ECAPI hierarchy using Parquet's native nested types. One row per event. Children stored as LIST of STRUCT," the document states. Its worked example is a purchase event with a value of 149.99, two hashed email addresses and two line items, one priced at 99.99 and one at 50.00, each with a quantity of one. It produces one row.

The alternative is a fully denormalized single wide table, in which "Every child array is exploded into the parent row." The example is a generate_lead event for a user with two email addresses and two phone numbers on file. That event "produces 4 rows (2 emails × 2 phones)," each carrying the same event identifier, the same value of 50.00 and the same "High Spender" customer segment.

The guidelines say this layout "is most practical when the primary source of row multiplication is user identity signals (multiple emails, phones, or UIDs) rather than cart items." For events with item arrays, nested structs avoid "combinatorial explosion." The arithmetic shows why the choice matters for measurement. By PPC Land's calculation, a query that summed the value column across the four example rows would report 200.00 in lead value rather than 50.00, unless the rows were first collapsed on the event identifier through deduplication. Add three cart items to the same event and the row count rises to 12.

Partitioning and the done marker

Files should use Hive-style directory partitioning, in which folder names carry key-value pairs. The guidelines do not mandate a scheme - "advertisers choose based on their data volume and query patterns" - but list three:

  • Day only (event_date=2026-05-14/), for a single campaign or low volume, described as the simplest.
  • Campaign plus day (campaign_id=camp-123/event_date=2026-05-14/), for multi-campaign advertisers. The document calls this "Most common for DCR uploads," because it "isolates campaigns for independent attribution queries."
  • Data set plus day (data_set_id=acme-meta-001/event_date=2026-05-14/), for "Multi-partner uploads where the same events go to multiple DCRs from a single upload pipeline."

One rule in this section is mandatory for both sides. Once all files for a partition are uploaded, "the uploading party must write an empty marker file named done in the partition directory to signal that the partition is complete and ready for processing." Clean rooms, in turn, "must not process a partition until the done marker is present."

The guidelines explain the failure the marker prevents. "Without this signal, a reader polling the directory cannot distinguish between a partition that is still being uploaded and one that is finished. Processing an incomplete partition produces incorrect results (missing events, wrong aggregates) with no indication of error." The pattern is not new. The document cites the _SUCCESS file Hadoop MapReduce writes after each job, the same behaviour in Spark's FileOutputCommitter, and an identical done blob in the World Federation of Advertisers' cross-media-measurement project, where it gates processing of encrypted impression shards. Corrections follow a set order: the uploader deletes the marker, replaces the files and writes a new marker.

Parquet files carry a footer that can store arbitrary key-value pairs, and the guidelines use it as the manifest: "no external manifest file is required." Every ECAPI clean room file must include seven keys, each prefixed with "ecapi." to avoid collisions:

  • ecapi.version, the ECAPI schema version, for example "1.0"
  • ecapi.layout, the layout the file uses
  • ecapi.advertiser_id, the advertiser's identifier in the clean room
  • ecapi.data_set_id, the data set identifier
  • ecapi.upload_id, a unique batch upload identifier in UUID version 4 format
  • ecapi.uploading_party, who created the upload
  • ecapi.hash_encrypted, how the data was processed: "sha256", "encrypted" or "both"

Section 4 frames the purpose in terms of the identifier rules: "Delivery mechanisms must convey the metadata needed to interpret ECAPI data and apply the identifier protections required by Section 1."

Encryption inside the file

When identifiers are encrypted rather than hashed, the guidelines name Parquet Modular Encryption, defined in the Apache Parquet format specification. It "encrypts individual columns using AES and stores encryption metadata in the Parquet binary footer." Two requirements follow. "Columns containing values that are encrypted rather than hashed must use PME," and the footer "should use plaintext footer mode so ingestion pipelines can read column names and row counts without decryption keys." Hashed fields are stored as text in every case: according to the conventions, fields designated for SHA-256 hashing "are always STRING regardless of privacy method (hashed, PME-encrypted, or app-layer encrypted)."

Compression is optional but "highly recommended." According to the guidelines, it "significantly reduces payload sizes which directly minimizes: transfer latency, network bandwidth utilization, egress costs, disk I/O, and storage footprints, while optimizing downstream ETL pipeline throughput." Egress fees, which cloud providers charge for moving data out of their networks, are one of the few cost items the document names.

Mapping every ECAPI field

The appendix, "ECAPI v1.0 DCR Extension: Parquet Schema," maps each field of the ECAPI v1.0 standard to a Parquet type. "Column names match ECAPI v1.0 field names exactly," and all text uses UTF-8 encoding.

The type choices follow from the source format. "ECAPI transmits over JSON, which represents all numbers as IEEE 754 double-precision," the document notes, so value, price, discount, quantity, shipping and tax are stored as DOUBLE to preserve the original precision. Quantity, as a result, can hold fractional amounts. String enumerations such as event_type, source and cattax are stored as STRING, because "Parquet has no string-enum type." Integer enumerations - age range, address type, agent type, availability, vehicle body style, condition, drivetrain, fuel type, listing type and transmission - are stored as INT32. Arrays become Parquet lists, and the user_data and properties objects become nested groups. Platform extensions at each level are kept as JSON-encoded text columns, such as event_ext_json and item_ext_json.

By PPC Land's count, the schema names 101 fields across the event, user data, user identifier, address, properties and item objects. Three are required: data_set_id, which "identifies data destination on receiving system"; a timestamp in Unix epoch seconds; and event_type. The event identifier, id, is optional in the schema, even though it is the key on which duplicates are recognised.

The schema comments show which personal fields ECAPI expects to be hashed. By PPC Land's count, nine are marked SHA-256: the customer identifier, email addresses, phone numbers, gender, user identifiers in the uids array, first name, last name, street and postal code. Several others that can identify or locate a person are not marked for hashing: city, state, country code, the event and landing-page IP addresses, browser user agents, the device advertising identifier (ifa), click IDs and impression IDs.

Privacy signals travel with each event. The user_data object carries the Global Privacy Platform consent string (gpp_string), the applicable section IDs (gpp_sid) and an mmt_only flag, annotated in the schema: "if true, use for attribution only, not optimization."

The properties object is where ECAPI's vertical ambitions show. Alongside transaction ID, page URL, referrer, coupon, shipping, tax and payment type, it holds lead fields (lead source, status and reason), gaming fields (character level, post score, achievement ID), travel fields (arrival and departure dates, destination airport as an IATA code) and an automotive block running from make, model and exterior color to VIN, lease start and end dates, drivetrain (an enumeration from 1 to 7) and fuel type (1 to 9). Each item in a cart can carry 15 fields, from SKU, name, price and discount to brand, category, list placement and a physical location ID.

Where standardization stops

Section 3 is two paragraphs long and the most candid in the document. "ECAPI v1.0 includes an ext (extension) object on every object. These can be used for platform-specific data," it states. "In practice, every major ad platform has proprietary fields that advertisers must include for that platform's matching and attribution to work." For those values, advertisers are told to consult their platform partner. The guidelines do not list any of those fields.

Why this matters for the marketing community

Server-side event feeds, usually sold as a conversions API, have become a common way for advertisers to report outcomes as browser signals weaken, and each major platform has built its own. Meta made its one-click Conversions API available in April 2026, with no developer work required for web events. Microsoft's version is gated behind per-account pilot approval, with its own endpoint, batch limit and consent field. On September 10, 2026, Google said its Data Manager API had become universal and was built on the ECAPI standard.

The cost of that fragmentation was documented before ECAPI existed. In a report released on October 30, 2025, the IAB found that 72% of publishers named technical complexity as a major obstacle to conversion APIs, while two-thirds of advertisers that adopted one reported improved return on ad spend. The clean room guidelines extend the same argument to batch uploads: one file layout, one set of metadata keys, one completion signal, regardless of which clean room receives the data.

The identifier change is the part with wider consequences. Hashing has long been the industry's standard answer to the question of how personal data can be shared, even as regulators have disputed its value. The Federal Trade Commission's technology staff said in July 2024 that hashing does not make data anonymous, and in November 2024 warned that most clean room services are not privacy-preserving by default and that unlawful data use remains unlawful inside one. The final guidelines take a different route around the same problem. They accept raw identifiers into clean rooms where controls are strong enough, and they shift the burden of protection from the data itself to the environment's configuration. Whether a given environment's controls "enforce the same restrictions" is something the guidelines ask operators to assert, and, where operator isolation is claimed, to document and make independently verifiable. The guidelines name no body or process to carry out that verification.

The question has also surfaced in merger review. When the FTC accepted a proposed consent order allowing Publicis to close its $2.2 billion acquisition of LiveRamp, the order included four guarantees specific to clean room services among five years of conditions. Clean room operators are being asked, from several directions at once, to prove what their systems prevent.

The IAB's own framing has also been more restrained than the market's. Its Data Clean Rooms in Commerce framework, published in September 2026, found that nine of 14 common commerce use cases can often be handled without a clean room, and stated that using one does not by itself establish a legal basis for processing data. The ECAPI guidelines do not address legal basis at all. Nor does the ECAPI standard, which leaves it with each implementer.

For advertisers already sending conversion data to several platforms, the guidelines offer a single packaging target, with the platform-specific fields still to be handled one partner at a time. For clean room operators, they set obligations that are concrete and checkable: read the footer, wait for the done marker, honour the hashing declaration. What neither the guidelines nor the blog post supplies is a named implementer. More than six months after ECAPI 1.0 was finalized, the clean room guidelines arrive without a single implementer identified, and with the hashing rules beneath them open for revision.

Timeline

Summary

Who: IAB Tech Lab and its ECAPI Working Group, with the release announced by Jill Wittkopp, VP, Product. The guidelines affect advertisers sending conversion data, the ad platforms and publishers receiving it, and the companies operating data clean rooms. No contributors or implementers are named.

What: Final Guidelines for Providing ECAPI Events to Data Clean Rooms, which set a Parquet format for bulk uploads of ECAPI v1.0 events: nested structs as the recommended layout, Hive-style partitioning, a mandatory empty "done" marker before processing, seven required footer metadata keys, Parquet Modular Encryption for encrypted columns and a field-by-field schema. The final text adds an explicit allowance for unhashed identifiers where technical controls enforce the same access restrictions. A new hashing and encryption section of ECAPI 1.1 is open for public comment.

When: Published November 3, 2026. Comments on the draft closed on September 4, 2026, and the ECAPI 1.1 comment issue was opened on October 28, 2026, with no closing date stated.

Where: On IAB Tech Lab's website and in the InteractiveAdvertisingBureau/ecapi repository on GitHub. The guidelines carry no geographic limit.

Why: According to IAB Tech Lab, clean rooms are a common destination for the same conversion data that ECAPI standardizes for server-to-server transmission, and collaborators need a shared object format and schema. For the market, the change on unhashed identifiers moves protection from the data to the environment, at a time when regulators have questioned both hashing and clean room privacy claims, while platform-specific fields remain outside the standard.