IAB Tech Lab has opened a set of technical guidelines that tell advertisers how to package conversion events for data clean rooms, covering encryption, Parquet layout, partitioning and file metadata. Comments close on September 4, 2026.

The document, titled ECAPI Guidelines for Data Clean Rooms, extends the Event and Conversion API standard into a workflow that the standards body says implementers kept raising during the rollout of the core specification. It is published in the ECAPI repository on GitHub, alongside the core specification, a changelog and an examples file. According to the repository, the file was created two weeks before this article and the accompanying public comment issue was opened on the same timescale.

The guidelines do not create a new standard. According to IAB Tech Lab, the data clean room use case does not warrant one, because the events needed for measurement and optimization in a clean room workflow are the same events already defined for the server-to-server integration described in the core specification. What differs is packaging. According to the organisation, there were enough nuances in the way event data is bundled for clean room workflows that separate guidance seemed useful.

The stated purpose is narrow. According to IAB Tech Lab, the goal of the guidelines is to help scale and expedite these integrations, and the scope is limited to data moving between systems rather than how data is stored inside any given system.

What the guidelines require

The first requirement concerns protection of identifiers before they leave the advertiser environment. According to the guidelines, if the ECAPI v1.0 standard designated a value as SHA-256 hashed, that value must be either hashed under the standard's normalization rules or encrypted through Parquet Modular Encryption or application-layer encryption before it is uploaded to a clean room. Values that are neither hashed nor encrypted nor otherwise appropriately protected must not appear in any Parquet file delivered to a clean room.

That is a prohibition written in the language of specifications, using the capitalised MUST NOT convention. It matters because hashing has repeatedly been treated in the industry as a sufficient privacy control, a position the Federal Trade Commission rejected in July 2024 when it warned that hashed identifiers remain identifiers. The commission followed that in November 2024 with guidance on clean rooms themselves, stating that the environments are not privacy-preserving by default.

Compression is treated differently. According to the document, it is not strictly required, but it is described as a highly recommended practice for batch transfers because it reduces payload sizes and therefore transfer latency, network bandwidth use, egress costs, disk input and output, and storage footprint.

Two Parquet layouts, and a warning about row explosion

Parquet is a columnar file format widely used for analytical workloads, and it is the format the guidelines assume. The complication is structural: an ECAPI event can carry multiple email addresses, multiple items and multiple postal addresses, and a flat table does not represent nested, variable-length data without a choice being made.

The document describes two options. The recommended layout is nested structs, using Parquet's native nested types under Dremel encoding, with child collections stored as a LIST of STRUCT and one row produced per event. The worked example in the guidelines shows a purchase event with a value of 149.99, two hashed email addresses and two line items, producing a single row.

The alternative is a fully denormalized single wide table, in which every child array is exploded into the parent row. The guidelines are direct about the arithmetic. A generate_lead event for a user with two email addresses and two phone numbers on file produces four rows, one for each combination. According to the document, this layout is most practical when row multiplication comes from identity signals rather than from cart contents, and events carrying item arrays are better served by the nested approach because it avoids combinatorial explosion.

The distinction is not academic for anyone paying for clean room compute. Duplicate rows inflate scan volumes, and in a denormalized layout the value field repeats across every row generated by the same event, which creates a double counting risk in any query that does not deduplicate on the event identifier first.

Partitioning and the done marker

The guidelines call for Hive-style directory partitioning, though no single scheme is mandated. Three are listed: day only, for a single campaign or low volume; campaign plus day, described as the most common arrangement for clean room uploads because it isolates campaigns for independent attribution queries; and data set plus day, for multi-partner uploads where the same events are sent to more than one clean room from a single pipeline.

The operational detail sits in what happens after upload. According to the document, once all files for a partition are written, the uploading party must write an empty marker file named done in the partition directory. Without that signal, a reader polling the directory cannot tell an in-progress upload from a finished one, and processing an incomplete partition produces missing events and wrong aggregates with no error raised. Clean rooms must not process a partition until the marker is present, and re-uploads require deleting the marker, replacing the files and writing a new one.

The guidelines place this in a lineage of established batch conventions, citing the _SUCCESS file written by Hadoop MapReduce after each job, the equivalent behaviour in Spark's FileOutputCommitter, and the done blob used by the World Federation of Advertisers cross-media-measurement project to gate processing of encrypted impression shards.

Rather than requiring a separate manifest, the guidelines use the key-value pairs that Parquet files can carry in their footer. According to the document, every ECAPI clean room Parquet file must include a set of keys prefixed with ecapi. to avoid collisions: the schema version, the layout in use, the advertiser identifier in the clean room, the data set identifier, a unique batch upload identifier expressed as a version 4 UUID, the uploading party, and a key recording whether the data was hashed, encrypted or both.

There is an inconsistency in the draft on this last point. The metadata table names the key ecapi.hash_encrypted, while the encryption section refers to ecapi.privacy_method as the key that declares whether values were hashed, encrypted through Parquet Modular Encryption, or both. Public comment periods exist to catch discrepancies of exactly that kind.

Encryption, enclaves and attestation

Where encryption is chosen instead of hashing, the guidelines point to Parquet Modular Encryption, which encrypts individual columns using AES and stores encryption metadata in the binary footer, in line with the Apache Parquet format specification. Two requirements follow. Columns holding encrypted rather than hashed values must use the mechanism, and the footer is to be written in plaintext footer mode so that ingestion pipelines can read column names and row counts without holding decryption keys.

The strongest recommendation in the document concerns trusted execution environments. According to IAB Tech Lab, encryption rather than hashing is strongly recommended when the clean room runs validation workflows inside a Trusted Execution Environment with key management service based key wrapping, following a key encryption key and data encryption key model, where the environment obtains decryption access through workload attestation. The stated effect is that raw values are accessible only inside the attested enclave and never exposed to the clean room operator.

Where no such environment is involved, or where any non-attested workflow might touch decrypted data, the guidelines call for values to also be SHA-256 hashed so that raw values are never present even if encryption is bypassed or misconfigured. Key management itself is left to the parties, with clean room operators expected to document their approach and supply advertisers with the writer configuration needed to produce compatible files.

Hardware-isolated processing has been moving steadily from research protocols into commercial infrastructure. IAB Tech Lab's PAIR protocol listed a single clean room using a trusted execution environment as one of three implementation patterns, and its ADMaP attribution protocol combined private set intersection with the same technology. LiveRamp's regulatory filing on the Publicis transaction named clean rooms, encryption, access controls and trusted execution environments as the mechanisms enforcing data separation after close.

Field-level mapping

The bulk of the document is a complete mapping of every field in ECAPI v1.0 to a Parquet schema in Dremel notation, using the nested structs option, with one row per event and one file per partition. Required and optional designations follow the core standard.

Because ECAPI transmits over JSON, which represents all numbers as IEEE 754 double-precision, the mapping specifies DOUBLE for value, price, discount, quantity, shipping and tax so that the original precision survives. String-valued enumerations such as event_type, source and cattax become STRING, since Parquet has no string enum type and relies on dictionary encoding to compress repeated values. Integer-valued enumerations, including age range, address type, agent type, availability, vehicle body style, condition, drivetrain, fuel type, listing type and transmission, map to INT32. Arrays become LIST, objects become STRUCT, and extension fields at every level are stored as JSON-encoded STRING columns. Column names match the core standard exactly, and all strings use UTF-8.

Three fields are required in the schema: data_set_id, which identifies the destination on the receiving system; timestamp, as Unix epoch seconds; and event_type. Fields designated for hashing remain STRING regardless of which privacy method was applied.

The guidelines also acknowledge that standardisation stops short of the platforms. ECAPI v1.0 carries an ext object on every object for platform-specific data, and according to the document, every major ad platform has proprietary fields that advertisers must include for that platform's matching and attribution to work. The advice offered is to consult the platform partner directly.

A dissenting comment

The public comment issue has already drawn opposition to the premise. A commenter posting under the handle newbiechris741 wrote that the conversion concept is "fundamentally flawed" and does not account for marketing principles associated with Les Binet, Peter Field and the Ehrenberg-Bass Institute, arguing that brand strength, size, price and promotions determine most conversions. According to the same comment, conversion APIs only link an identifier between some media exposure and sales that were often generated elsewhere, and clean rooms are unnecessary because cohorting and noise addition leave results close to probabilistic estimates in any case.

That view sits at the opposite end of the spectrum from the direction of platform investment. Meta reduced the setup burden for its conversion API in April 2026, X consolidated its developer tools into Events Manager in June 2026, and LiveRamp connected ChatGPT advertising to its hub in the same month.

A date that does not match

One detail in the source material conflicts with the published record. The blog post accompanying the guidelines states that the ECAPI standard was finalised in April this year, and the guidelines document opens by referring to the ECAPI standard release in April 2026. PPC Land reported the specification as finalised on May 3, 2026, after a public comment period that closed on February 20, 2026. The discrepancy is small, but it affects any timeline reconstruction of the standard's development.

Why this matters for marketers

Standardising the transport of conversion events solved one half of a problem. The other half is what happens when those events land in a shared analytical environment, and until now that step has been negotiated bilaterally between each advertiser and each clean room operator. Schema mismatches, unclear partition completion signals and inconsistent hashing conventions consume integration time that is measured in weeks rather than hours.

IAB Tech Lab research cited in earlier coverage found that 72% of publishers identified technical integration challengesas a major obstacle to conversion API adoption, and that two-thirds of advertisers reported improved return on ad spendafter implementing one. The gap between those two figures is where guidance of this kind operates.

The commercial stakes attached to clean room work have risen. New York Times Advertising disclosed its first clean room collaboration on June 21, 2026, reporting a 61% increase in international click-through rate against cookie benchmarks. Consent remains the unresolved layer underneath all of it: ECAPI standardises transmission, not the legal basis on which the underlying data was collected, a point PPC Land examined in coverage of IAB warnings on first-party data in May 2026.

The comment window follows the pattern the standards body has used through 2026, from the Content Monetization Protocol in March to bot management guidance in May and the Programmatic Auction Definitions document finalised in June. Feedback on the clean room guidelines is being collected in the GitHub issue attached to the ECAPI repository until September 4, 2026.

Timeline

Summary

Who: IAB Tech Lab, through its ECAPI Working Group, with the draft published by Jill Wittkopp, VP Product at the organisation. The guidelines address advertisers uploading event data, and the clean room operators receiving it.

What: ECAPI Guidelines for Data Clean Rooms, an extension document to the ECAPI v1.0 standard covering hashing and encryption requirements, two Parquet layouts, Hive-style partitioning with a mandatory done marker, seven required file metadata keys, Parquet Modular Encryption with trusted execution environments, and a complete field-level mapping of the standard to a Parquet schema in Dremel notation.

When: The file was committed to the ECAPI repository and opened for comment in late July 2026, with the comment period running until September 4, 2026. The underlying ECAPI standard was published as final on May 3, 2026, though the guidelines and the accompanying blog post date the release to April 2026.

Where: The InteractiveAdvertisingBureau ecapi repository on GitHub, where the document sits alongside the core specification, and the IAB Tech Lab website, where the announcement was posted. The scope is global.

Why: Conversion events standardised for server-to-server transmission are frequently analysed with partners inside data clean rooms, and the packaging of those events for that workflow has been handled case by case. According to IAB Tech Lab, the events themselves do not warrant a separate standard, but the way they are bundled for clean room transfer carries enough nuances to justify written guidance intended to speed up integrations.