Чистая комната данных для ритейл-медиа сети или рекламной платформы: использовать ту, что предлагает ваше облако, лицензировать продукт или построить свою

Чистая комната данных (data clean room) — это общее рабочее пространство, обычно в облаке, где две компании сопоставляют данные своих клиентов и выполняют только тот анализ, о котором договорились. При правильной настройке ни одна из сторон не видит сырых записей другой. С её помощью ритейл-медиа сеть может сообщить бренду, сколько покупателей увидели его рекламу, а затем купили его товары. Бренд получает итоговую цифру, а не список имён. Можно использовать чистую комнату, которую предлагает ваше облако или хранилище данных, лицензировать готовую чистую комнату у вендора или построить свою. Выбор зависит от того, где лежат ваши данные и данные ваших рекламодателей и является ли чистая комната частью того, что вы продаёте.

Что чистая комната данных делает для ритейл-медиа сети или рекламной платформы?

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

Сотрудники Федеральной торговой комиссии США (FTC) писали о чистых комнатах в ноябре 2024 года в посте в технологическом блоге комиссии. Они описали их как «облачные сервисы обработки данных, которые позволяют компаниям обмениваться данными и анализировать их в рамках правил, ограничивающих использование данных».

Interactive Advertising Bureau (IAB), американская отраслевая организация цифровой рекламы, 29 сентября 2026 года опубликовала фреймворк о чистых комнатах в коммерции. На странице фреймворка перечислены такие сценарии использования, как «пересечение аудиторий, обогащение данных, таргетинг, исключение». Проще говоря: сколько у вас общих клиентов, что ещё вы о них узнаёте и кому показывать рекламу, а кого исключить.

Паблишеры и рекламные платформы используют ту же схему. Паблишер может сопоставить своих авторизованных читателей с клиентами рекламодателя. DSP (demand-side platform) — система, через которую рекламодатели покупают рекламу, — может сопоставить людей, которые видели её рекламу, с продажами рекламодателя.

Чего чистая комната не решает?

Чистая комната защищает данные ровно настолько, насколько хорошо она настроена. Сотрудники FTC написали в том же посте: «По умолчанию большинство сервисов, которые предоставляют DCR, не защищают приватность». DCR — сокращение от data clean room, то есть чистой комнаты данных. Дальше они пишут: «Вместо этого компании должны целенаправленно настраивать и развёртывать каждое ограничение, чтобы оно было эффективным».

Правила для запросов ловят не все уловки. Документация Google по BigQuery data clean rooms предупреждает, что правила анализа «могут не полностью предотвращать извлечение несанкционированных данных с помощью сложных запросов». Документация AWS Clean Rooms описывает одну такую уловку: узнать что-либо об одном человеке, «добавляя или удаляя записи о конкретном лице и наблюдая за разницей в результатах запросов».

Хеширование не делает данные анонимными. Сотрудники FTC написали в том же блоге в июле 2024 года: «Компаниям не следует действовать или заявлять так, будто хеширование персональной информации делает её анонимной». Европейская комиссия пишет, что персональные данные, которые были «деидентифицированы, зашифрованы или псевдонимизированы, но могут быть использованы для повторной идентификации человека, остаются персональными данными». Поэтому на них распространяется GDPR, основной закон ЕС о защите данных. Псевдонимизированные — значит, имена заменены кодами, которые всё ещё можно связать с людьми.

Юридические обязанности остаются за каждой компанией. IAB Tech Lab разрабатывает технические стандарты для цифровой рекламы. Её руководство по чистым комнатам называет соблюдение законодательства о приватности «ответственностью поставщика данных», то есть компании, которая приносит данные. В нём сказано, что партнёры должны доверять друг другу в том, что каждый приносит «полные и точные (не поддельные/не подправленные/не завышенные) данные». Там также отмечается, что доля совпадений (match rate), то есть доля записей, которые находят пару на другой стороне, «может отличаться от ожидаемой».

Иногда чистая комната вообще не нужна. Во фреймворке IAB для коммерции сказано, что чистые комнаты — «верное решение не для каждой задачи, связанной с данными или измерением».

Все источники в этой статье открывались 3 ноября 2026 года. Цитаты FTC взяты из постов сотрудников комиссии в её блоге, а не из правил FTC. По законодательству о приватности статья цитирует только источники из ЕС и США. В других странах действуют свои правила.

Какие облака и хранилища данных предлагают чистую комнату?

AWS, Google Cloud, Snowflake и Databricks предлагают её — каждая внутри своего сервиса. Хранилище данных — это база данных, в которой компания держит свои записи для анализа. Чем они различаются для покупателя:

• AWS Clean Rooms: по словам AWS, совместная работа «не требует переноса данных из AWS или их загрузки к другому провайдеру облачных услуг». Сервис может также читать данные, которые хранятся в Snowflake и Databricks. Тот, кто создаёт чистую комнату, выбирает, кто из партнёров платит за запросы.
• BigQuery data clean rooms в Google Cloud: по словам Google, средства контроля исходящих данных (egress controls) — правила о том, что может покидать комнату, — автоматически не дают партнёрам, которые делают запросы к данным, копировать и выгружать сырые данные.
• Snowflake Data Clean Rooms: в документации Snowflake сказано, что «поставщики данных должны использовать Snowflake Enterprise Edition» и «стоимость анализа несёт тот, кто его запускает», так что за запрос платит партнёр, который его выполняет.
• Databricks Clean Rooms: по словам Databricks, участники совместной работы «не могут видеть данные в таблицах, представлениях или томах других участников». По умолчанию каждый фрагмент кода анализа перед запуском должны одобрить остальные участники.

Когда стоит использовать чистую комнату, которую предлагает наше облако или хранилище данных?

Используйте её, если верно большинство из следующего:

• Ваши рекламные логи и данные о продажах уже лежат на этой платформе
• Большинство брендов, с которыми вы хотите работать, находятся на той же платформе, или она умеет читать их данные там, где они лежат
• Брендам нужно несколько стандартных видов анализа, например пересечение аудиторий и продажи после кампании
• У вас есть дата-инженеры, которые зададут правила, напишут одобренные запросы и помогут каждому новому бренду начать работу

Загвоздка — в брендах на других платформах: им, возможно, придётся открыть аккаунт на вашей или скопировать туда свои данные. Руководство IAB Tech Lab предупреждает, что «перенос данных между некоторыми платформами DCR может быть трудоёмким или дорогостоящим». Кроме того, облачная чистая комната — универсальный инструмент, а не продукт для ритейл-медиа. Интерфейсы и отчёты для ваших брендов и помощь каждому новому бренду вам придётся строить самим или обеспечивать вручную.

Когда стоит лицензировать готовую чистую комнату у вендора?

Лицензируйте продукт, когда:

• Бренды, с которыми вы хотите работать, держат данные во множестве разных облаков и хранилищ, и большинство из них нужны вам уже в этом году
• Вам нужны готовая аналитика и интерфейсы, которыми маркетинговая команда бренда может пользоваться без написания кода
• Команда по работе с данными у вас небольшая, и вы предпочитаете платить вендору за то, чтобы подключения работали

Некоторые продукты подключаются сразу ко многим платформам. В руководстве LiveRamp по началу работы для ритейлеров сказано, что можно настроить подключения к большинству облачных хранилищ, «включая AWS, GCS, Azure Blob, Snowflake, Google BigQuery и Databricks». В нём указано готовое решение Retail Intelligence, которое «соединяет бренд и RMN (плюс, по желанию, наложение данных паблишера)». RMN — это ритейл-медиа сеть (retail media network).

Расплачиваетесь вы за это платежами вендору и меньшим контролем над тем, что можно измерять. В руководстве IAB Tech Lab сказано, что «структура цен на DCR может кардинально различаться», и предлагается выяснить, нужна ли каждому участнику собственная лицензия. Если позже вы уйдёте, вам, возможно, придётся заново создавать аналитику и заново подключать каждый бренд.

Когда собственная чистая комната оправдана?

Собственная разработка окупается в таких случаях:

• Чистая комната — часть того, что вы продаёте, и вам нужны собственные правила для измерения и аудиторий
• Аудитории должны попадать в ваш аукцион спонсируемых товаров и в ваш ad-сервер — систему, которая выбирает и считает рекламу, — так, чтобы списки покупателей не покидали ваши системы
• Плата за запрос или за партнёра превысила стоимость команды, которая эксплуатировала бы вашу собственную систему

Собственная разработка не обязательно означает новый движок защиты приватности. Amazon Ads называет Amazon Marketing Cloud, свою чистую комнату для рекламодателей, «облачным решением для чистой комнаты данных» и пишет, что она «построена на AWS Clean Rooms». Ваш собственный слой поверх облачной чистой комнаты может взять на себя сопоставление, одобренные запросы, интерфейсы для брендов, логи и связь с вашим ad-сервером.

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

Что мы решаем сами, какой бы путь мы ни выбрали?

Софт обеспечивает соблюдение этих правил, но устанавливает их ваша команда:

• Сопоставление идентификаторов: по каким данным вы сопоставляете людей, например по адресу электронной почты или номеру карты лояльности, и как каждая сторона их подготавливает. Протокол PAIR (Publisher Advertiser Identity Reconciliation) от IAB Tech Lab «опирается на коммутативную криптографию». Каждая сторона шифрует идентификаторы своим секретным ключом, и дважды зашифрованные значения можно сравнивать, причём никому не приходится их расшифровывать. PAIR пришёл на смену более ранней спецификации OPJA, которую IAB Tech Lab объявила устаревшей в июле 2025 года. Для измерения того, какие продажи последовали за какой рекламой, IAB Tech Lab в феврале 2025 года утвердила окончательную версию ADMaP (Attribution Data Matching Protocol).
• Согласие: запись о том, на что согласился каждый покупатель. Руководство IAB Tech Lab просит каждую компанию, которая приносит данные, «предоставлять подтверждение согласия, где это применимо/требуется».
• Разрешённые запросы: заранее написанные и одобренные виды анализа, которые может запускать каждый бренд. AWS называет их шаблонами анализа (analysis templates), а Google — шаблонами запросов (query templates).
• Минимальный размер аудитории: каждая строка результата должна охватывать столько людей, чтобы никто из них не выделялся. Руководство IAB Tech Lab конкретного числа не задаёт. Ads Data Hub — инструмент Google для анализа данных о рекламе в Google — в режиме «difference checks» (проверка различий) требует около 50 уникальных пользователей на строку результата. В режиме «noise injection» (добавление шума) он требует около 20, а если запрос читает только данные о кликах и конверсиях — около 10. AWS отбрасывает строки ниже минимума, и «в выводе запроса не видно, что результаты удалены из-за ограничения на вывод». Объясните брендам, почему итоговые суммы могут не сходиться.
• Шум и лимиты запросов: дифференциальная приватность добавляет к каждому ответу немного случайного шума, так что результат почти не меняется от того, есть в данных конкретный человек или нет. В AWS каждый запрос расходует часть бюджета приватности. Бюджет и шум, добавляемый к каждому запросу, ограничивают, сколько запросов может выполнить партнёр.
• Логи: кто какой запрос выполнил и когда. Руководство IAB Tech Lab говорит, что эти записи «должны быть прозрачно видны всем поставщикам данных».
• Передача результатов: аудитория должна попадать в ваш ad-сервер или в DSP бренда в виде, который может использовать рекламная система, а не как список адресов электронной почты для скачивания.
• Удаление: когда совместная работа заканчивается, руководство предусматривает «оперативное удаление и уничтожение данных, предоставленных поставщиком данных, а также любых результатов DCR».

Что проверить до подписания договора с облачным провайдером или вендором?

• Остаются ли наши данные в нашем собственном аккаунте или где-то создаётся их копия?
• Нужен ли каждому бренду аккаунт или лицензия на той же платформе и кто за это платит?
• Кто платит за каждый запрос и как меняется счёт, когда число брендов удваивается?
• Можем ли мы добавлять собственные одобренные запросы и задавать для каждого бренда минимальный размер аудитории, шум и лимиты запросов?
• Можем ли мы видеть каждый запрос, выполненный на наших данных, с указанием того, кто и когда его выполнил?
• Как запросы на удаление и отзыв согласия применяются к данным, которые уже находятся в чистой комнате?
• Что мы сможем забрать с собой, если уйдём: одобренные запросы, логи и таблицы сопоставления, которые связывают идентификаторы наших покупателей с идентификаторами партнёров?

Кому принадлежат код, запросы и данные?

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

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

Что спросить у компании, которая будет это строить?

• Будете ли вы строить на чистой комнате нашего облака или напишете ядро сами — и почему?
• По каким данным вы будете сопоставлять покупателей и будете ли следовать PAIR при сопоставлении и ADMaP при измерении?
• Как будут одобряться запросы каждого бренда и где контролируется минимальный размер аудитории?
• Как вы помешаете бренду узнать что-либо об одном покупателе, сравнив два результата?
• Как аудитории попадают в наш ad-сервер и наш аукцион и сколько времени это занимает?
• Что записывается в логи, кто может их читать и сколько они хранятся?
• Как запрос на удаление или отзыв согласия дойдёт до данных, которые уже были сопоставлены?
• Можете показать это в действии в системе, которая работает сегодня?

Где здесь место amBrain?

amBrain ведёт этот блог. Две из его строк описывают системы по обе стороны чистой комнаты: рекламные события, которые в неё поступают, и ad-сервер, который использует выходящие из неё аудитории. Одна звучит так: «amBrain строит пайплайны событийной аналитики для AdTech: сбор и обработка событий показов и кликов и отчётность по ним». Другая: «amBrain строит ad-серверы: таргетинг, ограничение частоты показов и отчётность». Третья строка гласит: «RTBBidder, demand-side платформа, которую мы построили для клиента».

amBrain делает софт с 2019 года. О том, как компания работает с клиентами, она говорит: «Три формата: полная разработка, выделенная команда или инженеры внутри вашей команды». О владении у неё такая строка: «Клиент сохраняет полное владение продуктом и кодом, кроме наших переиспользуемых компонентов». До подписания попросите поимённый список этих компонентов.

Эта статья — не кейс. Кроме упоминания RTBBidder, работа для клиентов в ней не описывается. В ней не утверждается, что amBrain строил, лицензировал или настраивал чистую комнату данных для какого-либо клиента, и в ней нет цен и сроков amBrain. Другие названные здесь организации цитируются по их опубликованным страницам, и статья не утверждает, что между amBrain и кем-либо из них есть какие-либо отношения.

Это и не юридическая консультация. Как законодательство о приватности применяется к вашим данным, проверьте у юриста. Если amBrain в вашем шорт-листе, задайте ему те же вопросы, что и любой другой компании.