Передача cookie ID, мобильных рекламных идентификаторов, хешированных e-mail и внутренних user ID в рекламную цепочку способна создать риск сразу в нескольких юрисдикциях. Вопрос, можно ли передавать идентификаторы рекламодателям, нельзя решать по формуле «в идентификаторе нет имени, значит это не персональные данные». Для GDPR и многих американских режимов решающим будет не внешний вид строки, а реальная возможность выделить пользователя, связать события между собой или сопоставить запись с иными сведениями.
Для SaaS-сервиса, маркетплейса или владельца агрегатора ошибка часто начинается на уровне продуктовой архитектуры. Команда отправляет в рекламную платформу постоянный ID пользователя вместе с событием покупки, а юристы проверяют только текст Privacy Policy. Но законность операции зависит также от роли каждой стороны, основания обработки, механики получения согласия, географии аудитории и договорного распределения ответственности.
Какие идентификаторы считаются персональными данными
GDPR определяет персональные данные широко — как информацию, относящуюся к идентифицированному или идентифицируемому физическому лицу. Это правило закреплено в статье 4(1). Если cookie ID позволяет отслеживать поведение одного браузера, а рекламная сеть или ваш сервис располагает средствами для связывания этого ID с профилем, идентификатор попадает в периметр регулирования.
К этой категории обычно относятся cookie ID, рекламные идентификаторы мобильных устройств, пиксельные идентификаторы, IP-адреса, идентификаторы аккаунтов и псевдонимизированные e-mail. Отдельный риск создают комбинации: внутренний ID сам по себе может быть случайным числом, но в паре с датой заказа, городом, товарной категорией или IP он становится инструментом устойчивого профилирования.
Хеширование не равно анонимизации. Хешированный адрес электронной почты остается персональными данными, если его можно сопоставить с тем же адресом через повторное хеширование или иную информацию. Псевдонимизация прямо описана в статье 4(5) GDPR и снижает риск, но не выводит сведения из-под действия регламента.
Анонимными могут считаться лишь данные, для которых идентификация субъекта стала необратимо невозможной с учетом доступных средств. Простое удаление имени из выгрузки, сокращение IP-адреса или замена e-mail на технический ключ такого результата обычно не дают.
Передача идентификаторов рекламодателю: от чего зависит законность
Правовой ответ начинается с карты потока данных. Необходимо зафиксировать, какой именно идентификатор уходит, кому, с какой целью, на каком этапе пользовательского пути и получает ли получатель возможность использовать его для собственной аудитории или измерения рекламы.
При работе с пользователями из ЕЭЗ наиболее чувствительная зона — рекламное профилирование и кросс-сайтовое отслеживание. Теоретически контролер может ссылаться на законный интерес по статье 6(1)(f) GDPR, однако для передачи трекинговых идентификаторов рекламным партнерам эта конструкция часто не выдерживает балансировки интересов. Ожидания пользователя, масштаб наблюдения, возможность объединения источников и использование третьей стороной обычно говорят в пользу предварительного согласия.
Согласие должно отвечать требованиям статьи 7 GDPR: быть свободным, конкретным, информированным и однозначным. Предустановленная галочка, общее упоминание «партнеров» без их категорий или доступ к сервису только при согласии на необязательную рекламу могут сделать механизм уязвимым. Пользователь также должен иметь столь же простой способ отозвать согласие.
Для жителей Калифорнии потребуется отдельно оценить правила CCPA, дополненные CPRA. Передача идентификаторов за ценное встречное предоставление может быть квалифицирована как sale, а передача для кросс-контекстной поведенческой рекламы — как sharing. В таких случаях применяются право на отказ и обязанность предоставить понятный механизм opt-out по California Civil Code § 1798.120. Называть получателя «поставщиком услуг» недостаточно: важны фактические полномочия и договорные ограничения на использование информации.
Российский контур требует оценки ФЗ-152. Персональные данные определены статьей 3, а обработка допускается при наличии основания из статьи 6. Когда передача не укладывается в законный объем согласия или иной предусмотренный законом случай, нужно получить надлежащее согласие субъекта. Если сведения направляются за пределы России, дополнительно проверяется режим трансграничной передачи по статье 12 ФЗ-152 и применимое право страны получателя.
Почему DPA не всегда решает проблему
DPA нужен, когда одна сторона обрабатывает сведения исключительно по документированным инструкциям другой. Это типичная модель «контролер — обработчик» по статье 28 GDPR: например, поставщик аналитики хранит и обрабатывает события только для вашего сервиса, не определяя самостоятельные цели.
Рекламодатель нередко действует иначе. Он может строить собственные аудитории, сопоставлять полученный ID со своей базой, измерять конверсии в разных каналах и определять дальнейшее использование данных. В таком сценарии рекламодатель, скорее всего, является самостоятельным контролером, а в отдельных операциях стороны могут быть совместными контролерами. Обычный DPA здесь не заменяет прозрачного распределения целей, обязанностей по информированию и порядка обработки запросов субъектов.
Договор с рекламным партнером должен отражать фактическую модель. В нем следует определить допустимые категории идентификаторов, цели и срок использования, запрет на повторную идентификацию, запрет на обогащение сторонними источниками без согласованного основания, требования к безопасности, порядок привлечения субподрядчиков и уведомления об инцидентах. Для международной передачи из ЕЭЗ также анализируются гарантии главы V GDPR, включая применимость стандартных договорных положений и необходимость дополнительной оценки мер защиты.
Три ситуации, где риск обычно недооценивают
Первый сценарий — e-commerce передает рекламной сети хешированные e-mail покупателей для создания аудитории. Если люди не были ясно уведомлены о такой цели и не предоставили применимое согласие, хеширование не защитит компанию от претензий. Особенно рискованна передача сведений о покупках, из которых можно вывести чувствительные предпочтения.
Второй сценарий — SaaS-платформа передает клиентскому рекламодателю постоянный идентификатор посетителя и историю действий в личном кабинете. Даже при B2B-модели субъектом данных остается физическое лицо — сотрудник клиента или пользователь сервиса. Следует отделить технически необходимую обработку от поведенческой рекламы и проверить, кто отвечает на запросы об удалении и возражении против обработки.
Третий сценарий — агрегатор собирает публичные данные и добавляет к ним идентификаторы из собственных логов, после чего передает сегменты рекламодателям. Публичная доступность первичного источника не создает автоматического права на последующее профилирование и коммерческое распространение. Помимо privacy-риска, нужно проверить условия доступа к источнику, права на содержание базы данных, договорные запреты API и основания для создания производной базы.
Как выстроить контролируемую передачу
Начните не с формы согласия, а с инвентаризации. Техническая команда должна показать все SDK, пиксели, серверные интеграции, журналы событий и экспортные файлы, где присутствуют устойчивые идентификаторы. Для каждого потока зафиксируйте получателя, страну размещения, цель, правовое основание и возможность обратного сопоставления с человеком.
Далее проведите классификацию получателей. Если контрагент использует идентификаторы только по вашим инструкциям, оформляется модель обработчика с договорными требованиями статьи 28 GDPR. Если он формирует собственные сегменты и принимает решения о целях, потребуются иная договорная конструкция, отдельная прозрачность для пользователей и проверка самостоятельных обязанностей сторон.
В продукте нужны работающий центр управления согласиями, журнал его получения и отзыва, а также техническое прекращение выгрузок после отзыва. Privacy Policy и cookie-политика должны объяснять категории получателей и цели без скрытых формулировок. Для высокорискового масштабного профилирования следует оценить необходимость DPIA по статье 35 GDPR.
Полезны и технические ограничения: передавать не полный пользовательский журнал, а минимальный набор полей; задавать короткий срок жизни идентификаторов; исключать чувствительные сегменты; отделять сервисные события от рекламных; запрещать получателю связывать данные с другими источниками без отдельного основания. Минимизация по статье 5(1)(c) GDPR снижает не только регуляторный риск, но и масштаб последствий при утечке.
Нарушение этих правил может привести к предписаниям остановить обработку, требованиям удалить аудитории, конфликтам с корпоративными заказчиками и санкциям. По статье 83 GDPR максимальный уровень штрафов достигает 20 млн евро или 4% мирового годового оборота — в зависимости от того, какая сумма выше. Для быстрорастущего бизнеса критична и коммерческая цена: инвестор или крупный клиент почти всегда запросит документы, подтверждающие контроль рекламных потоков.
Дата-юристы могут провести аудит идентификаторов и рекламных интеграций, определить роли сторон, подготовить DPA, договоры передачи данных, Privacy Policy и регламент реакции на инциденты. До запуска новой выгрузки разумнее проверить архитектуру и документы: исправить поток до первой кампании значительно дешевле, чем останавливать его после жалобы пользователя или запроса регулятора.