Confidential matching в Google Ads 2026: шифрование первичных данных в Data Manager

Загрузка клиентской базы в Google Ads почти всегда упирается не в техническую сложность, а в один вопрос от юриста или безопасника: «А что именно вы отправляете Google и кто внутри Google это видит?». Раньше честный ответ звучал так: «Мы отправляем SHA-256-хеши email и телефонов, и дальше это вопрос доверия к платформе». С confidential matching ответ стал конкретнее: сопоставление происходит внутри аппаратно изолированной среды, доступ к которой не имеет даже персонал самого Google, а при желании вы можете дополнительно зашифровать данные своим ключом из Cloud KMS — так, что расшифровать их способен только подписанный и проверенный код внутри этой среды.

Эта статья — разбор того, как confidential matching устроен на самом деле, что он даёт и чего не даёт, и пошаговый порядок настройки шифрованной загрузки через Google Ads Data Manager. Без маркетинговых формулировок: что нажать, какие роли выдать, какие поля заполнить и где этот процесс обычно ломается.

Что такое confidential matching и какую задачу он закрывает

Confidential matching — это способ сопоставления ваших первичных данных (email, телефон, адрес) с аккаунтами Google, при котором само сопоставление выполняется в Trusted Execution Environment (TEE) — доверенной среде исполнения. На практике это означает три вещи.

• Данные изолированы на уровне процессора. Память, в которой лежат ваши записи во время обработки, зашифрована аппаратно. Операционная система хоста, гипервизор и администраторы инфраструктуры не могут её прочитать.
• Код внутри среды зафиксирован и подписан. Внутри TEE выполняется конкретный образ, проверенный и подписанный Google, с известным отпечатком. Подменить его на «чуть другой» незаметно нельзя.
• Это проверяемо снаружи. Механизм аттестации позволяет вашей стороне выдавать доступ к ключу шифрования только тому вызывающему, который доказал, что работает в Confidential Space с нужным отпечатком кода.

Для аудиторий Customer Match, создаваемых через Data Manager, confidential matching используется по умолчанию — отдельно включать его не нужно. Дополнительный слой, который включается по желанию, — это собственное шифрование данных вашим ключом до отправки. Именно он и есть то, что в интерфейсе называется «confidential matching with encryption», и именно его чаще всего требует служба безопасности в регулируемых нишах.

Коротко: TEE — это базовая защита, которая у вас уже есть. Шифрование своим ключом — это надстройка, которая переводит «мы доверяем Google» в «мы технически контролируем, кто может расшифровать».

Как это устроено технически

Trusted Execution Environment простыми словами

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

Google реализует это через Confidential Space — специализированную среду, в которой запускается только заранее подготовленный, подписанный образ. Для рекламодателя важна не сама технология, а её следствие: между «мы загрузили хеши» и «кто-то внутри платформы теоретически может их выгрузить» теперь стоит аппаратный барьер, а не только внутренний регламент.

Аттестация: как доказывается, что внутри именно нужный код

Аттестация — ключевая часть схемы, и именно её обычно пропускают при беглом чтении документации. Работает она так:

1. Сервис сопоставления запускается в Confidential Space и получает от платформы OIDC-токен с набором утверждений о себе: тип среды, отпечаток образа, статус поддержки.
2. Этот токен предъявляется вашему Workload Identity Pool (WIP) provider в Google Cloud.
3. Вы заранее описали в провайдере условие доступа: выдавать идентичность только если среда равна CONFIDENTIAL_SPACE, отпечаток подписанного образа совпадает с опубликованным Google, а статус поддержки — STABLE.
4. Только после выполнения условия сервис получает право обратиться к вашему ключу в Cloud KMS и расшифровать ключ данных.

То есть доступ к расшифровке даёт не договор, а криптографическая проверка. Если образ изменится и его отпечаток перестанет совпадать с условием, которое вы прописали, ключ просто не выдастся, и загрузка не пройдёт.

Конвертное шифрование: три слоя

Шифрование здесь построено по схеме envelope encryption. Слоёв три, и путать их не стоит — именно на этом ломается большинство первых попыток.

Слой	Что это	Где живёт	Что делает
KEK (Key Encryption Key)	Ключ шифрования ключей	Cloud KMS, ваш проект	Шифрует DEK. Из KMS не извлекается
DEK (Data Encryption Key)	Ключ шифрования данных	Генерируется вами, передаётся в зашифрованном виде	Шифрует значения полей алгоритмом XChaCha20Poly1305
Данные	Нормализованные PII	В файле загрузки	SHA-256 → Base64 → шифрование DEK → Base64

Обратите внимание на порядок обработки значения: сначала нормализация (нижний регистр, обрезка пробелов, телефон в формате E.164), затем хеширование SHA-256, затем кодирование Base64, затем шифрование ключом DEK, и только затем ещё одно кодирование Base64 для передачи. Пропуск или перестановка любого шага даёт на выходе валидный с виду, но бессмысленный файл — и нулевой match rate без явной ошибки.

Что confidential matching даёт — и чего не даёт

Здесь важно не поддаться завышенным ожиданиям. Технология закрывает конкретную проблему и не трогает соседние.

Даёт	Не даёт
Аппаратную изоляцию обработки PII от персонала платформы и инфраструктуры	Не повышает процент совпадения аудитории — match rate зависит от качества и охвата базы
Техническое доказательство того, кто и каким кодом может расшифровать данные	Не заменяет правовое основание обработки и не отменяет согласие пользователя
Аргумент для внутреннего security review при загрузке базы в рекламную систему	Не делает загрузку допустимой там, где она запрещена политикой персонализированной рекламы
Контроль через собственный ключ: отозвали KEK — расшифровка невозможна	Не влияет на ставки, обучение алгоритма и структуру кампаний напрямую

Отдельно подчеркну первый пункт правой колонки, потому что его регулярно понимают неправильно. Confidential matching меняет способ обработки, а не результат сопоставления. Если ваша база даёт 40% совпадений, после включения шифрования она даст те же 40%. Рост охвата приходит из других мест — из полноты базы, свежести контактов и количества источников, и это тема работы с Customer Match и первичными данными, а не криптографии.

Пошаговая настройка шифрованной загрузки

Порядок ниже рассчитан на то, что аудитории вы уже создаёте через Data Manager и подключённые источники первичных данных, и теперь хотите добавить слой собственного шифрования.

Шаг 1. Подготовьте инфраструктуру в Google Cloud

Понадобится проект Google Cloud и две роли у того, кто будет настраивать:

• Cloud KMS Admin — чтобы создать keyring и сам KEK;
• IAM Workload Identity Pool Admin — чтобы создать пул и провайдера с условиями аттестации.

Создайте KEK в Cloud KMS и запомните его полный ресурсный идентификатор — он понадобится как значение kek_uri. Затем создайте Workload Identity Pool и в нём OIDC-провайдера, прописав условие атрибутов: среда CONFIDENTIAL_SPACE, совпадение отпечатка подписанного Google образа, поддерживаемый статус STABLE. Выдайте сервисному аккаунту сопоставления право на расшифровку этим KEK.

Шаг 2. Подготовьте данные

На этом шаге делается вся основная работа, и именно он требует кода на вашей стороне. Для каждой записи:

1. Нормализуйте значения. Email — в нижний регистр, без лишних пробелов. Телефон — в E.164 с кодом страны. Имя, фамилия, почтовый индекс и страна — по правилам Customer Match.
2. Посчитайте SHA-256 от нормализованного значения.
3. Закодируйте хеш в Base64.
4. Зашифруйте результат ключом DEK (XChaCha20Poly1305).
5. Закодируйте шифртекст в Base64 — это и есть значение, которое попадает в файл.

DEK вы генерируете сами, затем шифруете его вашим KEK и получаете encrypted_dek — его нужно будет передать вместе с данными.

Шаг 3. Доставьте файл в поддерживаемый источник

Data Manager принимает данные из нескольких типов подключений:

Источник	Когда удобен	На что обратить внимание
Google Cloud Storage	Регулярная автоматическая выгрузка из хранилища	Самый предсказуемый вариант, права выдаются на уровне бакета
SFTP	Когда выгрузку готовит внешний подрядчик или legacy-система	Следите за ротацией ключей и за тем, кто имеет доступ к каталогу
HTTPS	Разовые и редкие загрузки	Удобен для пилота, хуже подходит для ежедневного режима
CRM / база данных	Когда источник истины — ваша внутренняя система	Требует дополнительных шагов подключения и согласования доступов

Шаг 4. Сопоставьте поля в Data Manager

При настройке подключения, помимо обычного маппинга колонок, укажите два дополнительных поля: encrypted_dek (зашифрованный ключ данных) и kek_uri (ресурсный путь вашего KEK в Cloud KMS). Там же вводится имя WIP-провайдера, которое связывает загрузку с условиями аттестации, настроенными на шаге 1.

Шаг 5. Проверьте результат на малом объёме

Не начинайте с полной базы. Возьмите 1–2 тысячи записей, для которых вы точно знаете ожидаемый порядок величины совпадений, и сравните фактический результат. Если процент совпадений радикально ниже ожидаемого — почти наверняка проблема в конвейере подготовки данных, а не в платформе.

Где этот процесс ломается чаще всего

Ниже — ошибки, которые дают не явный отказ, а «тихий» нулевой или околонулевой результат. Именно они съедают недели.

• Нормализация после хеширования. Хеш считается от уже нормализованного значения. Если сначала посчитать SHA-256 от Ivan@Mail.ru с пробелом и заглавными, совпадений не будет никогда.
• Лишний или пропущенный Base64. В схеме два кодирования Base64: после хеширования и после шифрования. Одно лишнее или одно пропущенное — и на выходе бессмыслица.
• Неверный телефонный формат. Номер без кода страны, с пробелами, скобками или дефисами — это другое значение, а значит другой хеш.
• Рассинхрон ключей. Ротация KEK без обновления настроек подключения останавливает расшифровку. Заведите регламент ротации до продакшена, а не после первого сбоя.
• Слишком узкое условие аттестации. Если условие жёстко привязано к устаревшему отпечатку образа, загрузки перестанут проходить после планового обновления. Проверяйте актуальность отпечатка при настройке.
• Забытое согласие. Шифрование не отменяет требований к правовому основанию. Загружать можно только те контакты, по которым у вас есть корректно собранное согласие — и здесь по-прежнему работает связка с Consent Mode v2 и режимом приватности.

Как встроить в общий контур измерения

Confidential matching — один кирпич в стене, а не отдельно стоящее решение. Чтобы он давал отдачу, вокруг должны быть собраны остальные элементы.

1. Сбор идентификаторов на сайте. Без качественного сбора email/телефона на стороне сайта загружать будет нечего. Базовый слой здесь — расширенные конверсии, которые дополняют событие хешированными данными пользователя.
2. Устойчивость доставки событий. Блокировщики и ограничения браузеров срезают часть сигналов. Эту дыру закрывает серверный трекинг на sGTM и Google tag gateway как first-party-слой измерения.
3. Офлайн-данные. Если продажа завершается не на сайте, подключайте Store Sales и загрузку офлайн-покупок через Data Manager API.
4. Заплатки на пробелы тега. Там, где тег сработал, но часть данных потерялась, помогают дополнительные источники данных конверсий, которые дополняют тег-события выгрузкой из CRM.
5. Оценка эффекта. Чтобы понять, что вся эта работа что-то дала, смотрите на метрику Data Strength Uplift, а не на субъективное ощущение «стало лучше».

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

Как пройти внутренний security review

На практике внедрение упирается не в код, а в согласование. Ниже — три вопроса, которые задают почти всегда, и формулировки, которые на них отвечают по существу.

«Куда физически уходят персональные данные?» В загружаемом файле нет исходных значений: там зашифрованные представления хешей. Для расшифровки нужен ваш ключ из Cloud KMS, а доступ к нему выдаётся только вызывающему, прошедшему аттестацию. Сам процесс сопоставления выполняется в изолированной среде, содержимое памяти которой зашифровано аппаратно.

«Кто внутри платформы может это прочитать?» Техническая конструкция устроена так, что доступа нет ни у администраторов инфраструктуры, ни у персонала: ключ выдаётся не людям, а коду с проверенным отпечатком, запущенному в Confidential Space. Это отличается от «есть внутренний регламент, запрещающий доступ» — здесь запрет реализован криптографически.

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

Хорошая практика — зафиксировать ответы на эти три вопроса в коротком внутреннем документе вместе со схемой данных и списком ответственных. Это экономит недели при следующем аудите и при смене людей в команде.

Альтернативы и когда они уместнее

Шифрованная загрузка — не единственный способ работать с первичными данными. Сравните варианты честно, прежде чем строить инфраструктуру.

Подход	Что даёт	Цена вопроса
Загрузка через Data Manager без своего ключа	Защита TEE по умолчанию, минимум настройки	Подходит большинству, но не закрывает формальное требование шифрования
Загрузка с собственным шифрованием	Контроль ключа, проверяемая аттестация	Инфраструктура в Cloud, конвейер подготовки, регламент ротации
Только расширенные конверсии, без списков	Улучшает атрибуцию без выгрузки базы	Не даёт аудиторий для таргетинга и исключений
Офлайн-загрузка результатов сделок	Переносит в систему реальную ценность, а не факт лида	Нужен стабильный идентификатор клика и дисциплина в CRM

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

Чек-лист перед запуском

• Правовое основание обработки контактов зафиксировано, согласие собирается корректно.
• KEK создан в Cloud KMS, ресурсный путь сохранён.
• WIP-провайдер создан, условие аттестации прописано и проверено.
• Роли Cloud KMS Admin и IAM Workload Identity Pool Admin выданы ответственному.
• Конвейер подготовки данных воспроизводит порядок: нормализация → SHA-256 → Base64 → шифрование DEK → Base64.
• Поля encrypted_dek и kek_uri сопоставлены в настройках подключения.
• Пилот на 1–2 тысячах записей проведён, порядок величины совпадений соответствует ожиданиям.
• Регламент ротации ключей описан и назначен ответственный.
• Настроен мониторинг: падение числа успешных загрузок до нуля должно порождать алерт, а не обнаруживаться через месяц.

Нужно ли это именно вам

Честный ответ: не всем. Если вы загружаете небольшую базу, у вас нет внутреннего требования по шифрованию и security review проходит без возражений — встроенной защиты TEE, которая применяется по умолчанию, достаточно. Настройка собственного шифрования добавляет реальную операционную сложность: ключи, роли, конвейер подготовки, регламент ротации.

Слой с собственным ключом оправдан, когда выполняется хотя бы одно условие: у компании есть формальное требование шифровать PII при передаче третьим сторонам; вы работаете в регулируемой отрасли и проходите внешние аудиты; база большая и её утечка была бы серьёзным инцидентом; либо решение о загрузке блокируется именно службой безопасности, и нужен технический аргумент, а не обещание.

FAQ

Confidential matching нужно включать отдельно?

Нет. Для аудиторий Customer Match, создаваемых через Google Ads Data Manager, это техника по умолчанию. Отдельно включается только дополнительное шифрование данных вашим собственным ключом.

Повысит ли это match rate моей аудитории?

Нет. Способ обработки не влияет на долю совпадений. Match rate определяется качеством, свежестью и объёмом вашей базы, а также корректностью нормализации значений перед хешированием.

Чем шифрование отличается от обычного хеширования SHA-256?

Хеш необратим, но одинаковое значение всегда даёт одинаковый хеш, поэтому по словарю популярных email хеши теоретически сопоставимы. Шифрование ключом, который контролируете вы, добавляет слой, где без доступа к вашему KEK данные не превращаются даже в хеши.

Какие роли в Google Cloud нужны для настройки?

Cloud KMS Admin для работы с ключами и IAM Workload Identity Pool Admin для создания пула и провайдера с условиями аттестации. Выдавать их стоит точечно и временно, а не постоянным широким доступом.

Что произойдёт, если я отзову KEK?

Расшифровка новых загрузок станет невозможна, и загрузки перестанут проходить. Это ожидаемое поведение и, по сути, ваш рубильник: контроль над ключом означает контроль над возможностью обработки.

Можно ли загружать данные без согласия, раз они зашифрованы?

Нет. Шифрование — это техническая мера защиты, а не правовое основание. Требования к сбору согласия и ограничения политики персонализированной рекламы действуют в полном объёме.

Какие источники данных поддерживаются?

Google Cloud Storage, SFTP, HTTPS и подключения к CRM или базам данных. Последний вариант требует дополнительных шагов настройки на стороне источника.

Почему после включения шифрования совпадений стало почти ноль?

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

Нужно ли что-то менять в кампаниях после внедрения?

Непосредственно в кампаниях — нет. Меняется источник и защищённость данных, а не структура аккаунта. Но если аудитории станут полнее и свежее, имеет смысл пересмотреть стратегии и наблюдения, где эти списки используются.

Как доказать аудитору, что данные защищены?

Опирайтесь на схему аттестации: доступ к расшифровке выдаётся только при выполнении проверяемых условий — среда Confidential Space и совпадение отпечатка подписанного кода. Это проверяемое техническое утверждение, а не декларация.

Есть ли смысл внедрять это маленькому рекламодателю?

Обычно нет. Для небольших баз выгоднее сначала добиться полноты сбора контактов и корректного измерения, а уже потом усложнять контур шифрованием.

Что читать дальше, чтобы собрать картину целиком?

Начните с Data Manager и первичных данных, затем посмотрите, как закрываются пробелы измерения в материале про расхождение конверсий Google Ads и GA4, и чем заменяется исчезающий кросс-сайтовый сигнал — в разборе сторонних cookie и Privacy Sandbox.

Главный вывод: confidential matching не делает рекламу эффективнее сам по себе. Он снимает возражение, из-за которого первичные данные годами лежат в CRM и не доходят до рекламной системы. Ценность появляется в тот момент, когда после снятия этого возражения вы наконец доводите данные до платформы — и дальше уже работаете над их полнотой и свежестью.

Если упираетесь не в данные, а в инфраструктуру — подходящие рекламные аккаунты и корректно пройденная верификация решаются отдельно: в PPC Rebels это агентские аккаунты Google Ads и верификация рекламодателя.