Технологии, деньги и рынки — первымиНаписать в редакциюСтудия Dilami LabDilami Lab

IAB Tech Lab разрешил передавать незахешированные идентификаторы в clean room при технических ограничениях доступа

IAB Tech Lab 3 ноября опубликовал финальную версию руководства по передаче событий ECAPI в data clean room. Главное изменение по сравнению с августовским черновиком: рекламодатели могут передавать незахешированные клиентские идентификаторы без отдельного шифрования полей и файлов, если среда доставки и выполнения технически ограничивает доступ к исходным значениям для второй стороны.

IAB Tech Lab разрешил передавать незахешированные идентификаторы в clean room при технических ограничениях доступа
Иллюстрация: ppc.land

Главное в цифрах

  • Дата публикации финальной версии руководства ECAPI: 3 ноября 2026 года
  • Первый стандарт ECAPI v1.0 выпущен в апреле 2026 года
  • Срок общественного обсуждения черновика: 4 сентября
  • Объём руководства в репозитории GitHub: 270 строк

Документ задаёт формат Parquet-файлов для загрузки серверных конверсий в clean room: покупок, лидов и регистраций. Руководство опубликовано на GitHub в том же репозитории, что и спецификация ECAPI, и занимает 270 строк. Во время обсуждения оно находилось в отдельной ветке dcr-guidelines, финальная версия перенесена в основную ветку.

Область применения ограничена намеренно. По словам авторов, руководство описывает перемещение данных между системами, а не то, как их хранить и обрабатывать внутри конкретной системы. Документ касается только массовой загрузки в clean room и построен на Apache Parquet. Другие способы передачи, такие как live tables, governed shares, catalog references, потоки и API, в документ не входят.

Что изменилось по сравнению с черновиком

В черновике, открытом для комментариев до 4 сентября, правило о персональных идентификаторах было строгим. Значения, которые ECAPI v1.0 предписывает хешировать по SHA-256, включая email, телефоны, имена, адреса и почтовые индексы, нужно было захешировать по правилам нормализации стандарта или зашифровать перед загрузкой. Если защищённой среды не было, значения предписывалось хешировать в любом случае.

В финальной версии исходный принцип сохранён, но добавлено исключение. Участники могут передавать незахешированные идентификаторы без отдельного шифрования на уровне полей или файлов, если среда доставки и выполнения обеспечивает технический контроль того же ограничения доступа к исходным значениям. При этом шифрование при передаче и хранении остаётся обязательным. Обработка идентификаторов не даёт права раскрывать их через результаты, экспорты, логи или телеметрию, доступные партнёрам.

Зачем нужен исходный идентификатор

Хеш нельзя исправить задним числом. ECAPI требует приводить email к нижнему регистру и убирать пробелы до хеширования, а телефоны очищать от символов, букв и ведущих нулей и добавлять код страны с плюсом. Если рекламодатель захешировал адрес с лишней заглавной буквой или пробелом в конце, значение никогда не совпадёт с тем же адресом, захешированным правильно. Авторизованная задача внутри clean room может выполнить нормализацию сама и провести идентификацию по нескольким идентификаторам до хеширования.

За компанию, которая управляет инфраструктурой, отвечает отдельное положение. Изоляция от оператора инфраструктуры может дать дополнительную гарантию, но её объём и механизмы должны быть задокументированы и поддаваться независимой проверке. Изоляция от оператора не является обязательным условием для альтернатив, но сам текст документа в источнике обрывается на этом месте.

Нашли ошибку или есть что добавить? Напишите редакции
Источник: ppc.land
Рекламный кабинет
Такие новости первыми, в Telegram
Подписаться
0 новых новостей