Шифрование в Data Manager вместо SHA-256

Если вы грузите в Google Ads списки Customer Match, офлайн-конверсии или данные о покупках в магазине, у вас в пайплайне почти наверняка стоит шаг «посчитать SHA-256 перед отправкой». С 16 ноября 2026 года этот шаг перестаёт быть обязательным: Google рассылает рекламодателям письмо о том, что Data Manager будет по умолчанию принимать зашифрованные, а не хешированные данные. Ниже — что на практике означает шифрование в Data Manager, чего в письме нет, и какие девять вещей стоит проверить в своих выгрузках до середины ноября, чтобы не проснуться с провалившимся матчингом и мёртвыми аудиториями.

Что именно меняется 16 ноября 2026 года

Первоисточник один — письмо Google с темой «Encryption in Google Ads Data Manager». Его опубликовал в LinkedIn Anthony Higman (ADSQUIRE) 18 октября 2026 года, и в тот же день текст разобрало издание PPC Land. Ключевая фраза из письма в их цитировании звучит так: начиная с 16 ноября 2026 года Google «больше не будет требовать хешированные данные клиентов (SHA-256) для Google Ads Data Manager и вместо этого будет поддерживать зашифрованные данные клиентов по умолчанию».

Дальше письмо описывает механику: Data Manager будет расшифровывать, нормализовать и сопоставлять данные внутри доверенной среды исполнения (trusted execution environment, TEE). То есть порядок операций переворачивается. Раньше рекламодатель сам приводил данные к нормальной форме и хешировал их, а Google работал уже с необратимыми отпечатками. Теперь нормализацию берёт на себя Google — внутри изолированной среды, куда данные приезжают зашифрованными.

Обоснование, которое Google даёт в том же письме: обновление сделано «чтобы предложить лучшую производительность и задействовать наши последние разработки в области privacy-enhancing technology», и оно «улучшает точность сопоставления… и снижает количество ошибок, вызванных расхождениями форматирования до хеширования».

Главное практическое следствие: источником ошибок матчинга перестаёт быть ваша нормализация. Но ровно поэтому меняется и то, что именно ваш пайплайн обязан отправлять — а значит, его надо пересобрать до даты, а не после.

Чего в письме нет — и почему это важнее самой новости

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

Останется ли хеширование рабочим вариантом. Формулировка «больше не требуем» и «поддерживаем шифрование по умолчанию» подразумевает альтернативу, но письмо её не описывает. Запрета на SHA-256 там тоже нет.
Что будет с уже настроенными регулярными выгрузками, которые продолжат слать хеши после 16 ноября: продолжат ли они работать, будут ли конвертироваться, упадут ли в ошибку — не сказано.
Кто держит ключи шифрования для не-API маршрутов (CRM-коннекторы, импорт из облачного хранилища, прямая загрузка файлов). Для Data Manager API схема с обёрнутыми ключами в KMS задокументирована ещё с декабря 2025 года, для остальных каналов — нет.
Затронуты ли продукты за пределами Google Ads. В письме названы Customer Match и расширенные конверсии; Display & Video 360 и Google Analytics, которые тоже принимают данные через Data Manager API, не упомянуты.

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

Как было устроено до этого: хеш, нормализация и confidential matching

Чтобы понять масштаб изменения, полезно вспомнить, из чего состоит текущая схема. Рекламодатель брал email, телефон или почтовый адрес, приводил их к каноническому виду и считал SHA-256 — на выходе строка из 64 шестнадцатеричных символов. Правила нормализации в документации Data Manager API жёсткие и именно они были главным источником потерь:

телефон — в формате E.164 (плюс, код страны, номер без пробелов и скобок);
адрес собирается из имени, фамилии, почтового индекса и двухбуквенного кода страны;
всё в нижнем регистре, без пунктуации, без ведущих и хвостовых пробелов;
у Gmail-адресов перед хешированием убираются точки и всё после плюса.

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

Второй слой — confidential matching в Google Ads: технология, запущенная ещё в сентябре 2024 года, при которой сопоставление идёт внутри доверенной среды, наружу выходят только совпавшие записи, а несовпавшие данные удаляются. Для Customer Match и Data Manager она применяется по умолчанию и без доплаты. Ноябрьское изменение не отменяет этот слой — оно меняет формат, в котором данные в него приезжают.

Шифрование в Data Manager: какие каналы загрузки затронуты

По письму, новый порядок распространяется на все четыре маршрута, через которые данные попадают в Data Manager:

Маршрут	Типично у кого	Что проверять
CRM-коннекторы	Салес-команды, лидген, B2B	Обновит ли вендор коннектор сам и к какой дате
Импорт из облачного хранилища	Ecommerce, крупные аккаунты	Кто формирует файл и где в нём шаг хеширования
Прямая загрузка файлов	Небольшие аккаунты, ручные выгрузки	Шаблон выгрузки и инструкция для того, кто её делает руками
Data Manager API	Инхаус-разработка, агентства	Версия клиента, схема шифрования и управление ключами

Продукты, которые на этих данных стоят, названы в письме прямо: Customer Match и расширенные конверсии. Сюда же по смыслу попадают офлайн-данные, которые заходят через Data Manager — например, Store Sales через Data Manager API. Если вы ещё только выстраиваете этот контур, начните с базовой картины в разборе Data Manager и данных первой стороны.

Девять пунктов, которые стоит закрыть до 16 ноября

Инвентаризация потоков. Выпишите все места, откуда данные уходят в Google: списки аудиторий, офлайн-конверсии, покупки в магазине, обогащение конверсий. У большинства команд их оказывается больше, чем помнят наизусть — особенно если часть настроена подрядчиком два года назад.
Найдите шаг хеширования. Для каждого потока ответьте, где физически считается SHA-256: в SQL-запросе витрины, в скрипте выгрузки, внутри CRM, в плагине CMS или в коннекторе вендора. Миграция касается именно этого шага.
Запросите план у вендоров. Если данные уходят через коннектор CRM или CDP, у вендора должен быть ответ на один вопрос: переключитесь вы сами и когда, или от клиента нужны действия. Письмо Google рассылается рекламодателям, а не обязательно интеграторам.
Снимите бейзлайн match rate. Зафиксируйте текущий процент совпадений по каждому списку и размеры аудиторий до 16 ноября. Без этой цифры вы не отличите «стало лучше» от «половина данных перестала доезжать».
Проверьте, не упираются ли аудитории в минимальные пороги. Если список балансирует на границе допустимого размера, любое изменение матчинга может выключить таргетинг — и вы увидите это как падение охвата, а не как ошибку загрузки.
Поставьте мониторинг на ошибки загрузки. Молчаливый сбой — худший сценарий: задание отработало, файл принят, записи не совпали. Алерт на падение числа принятых строк и на провал match rate нужнее, чем ещё один дашборд.
Разберитесь с ключами. Для API-маршрута решите, где лежит ключ и кто им управляет (KMS облака), и впишите это в регламент доступов. Для остальных маршрутов зафиксируйте, что Google этот вопрос публично не раскрыл, и не придумывайте за него ответ в документации для юристов.
Обновите приватную документацию. Политика конфиденциальности, DPIA и внутренние описания потоков часто написаны в формулировке «передаются только необратимые хеши». Если фактический формат меняется, формулировку нужно привести в соответствие — это работа юриста, а не маркетолога, и начать её лучше заранее.
Назначьте окно наблюдения. Неделя до и две недели после 16 ноября: не меняйте в этот период стратегии назначения ставок и состав аудиторий, иначе не разделите эффект изменения и эффект собственных правок. Как быстро находить причину просадки, разбирали в материале про историю изменений Google Ads.

Чего делать не нужно

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

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

Что это даёт тем, кто сделает всё правильно

Если убрать из уравнения ошибки нормализации, выигрывают все измерительные механики, которые кормятся с первичных данных: точность Customer Match, качество сигнала для Smart Bidding, достоверность расширенных конверсий. Эффект при этом не универсален — он тем заметнее, чем грязнее были ваши данные до сих пор. Аккаунт, где телефоны лежали в трёх форматах, а почты с плюсами резались неправильно, увидит разницу; аккаунт с аккуратной витриной — почти нет.

Полезно также помнить, что матчинг — лишь один из слоёв. Сигнал теряется и до него: на стороне сайта, на блокировках и в разрывах атрибуции. Если эта часть у вас ещё не закрыта, посмотрите на отдачу тегов со своего домена через Google tag gateway и на новые колонки загрузки Customer Match — вместе эти три вещи дают больше, чем любая из них по отдельности.

И последнее по порядку, но не по важности: пока вы наводите порядок в данных, проверьте, не сломается ли у вас что-то в другом месте календаря. У Google в 2026 году накопилось несколько дедлайнов, которые бьют по операционке без предупреждения — например, декларация о политической рекламе ЕС, из-за которой перестают проходить правки кампаний. А если хотите параллельно вычистить расходную часть, самый быстрый эффект обычно даёт n-gram анализ поисковых запросов.

Если инфраструктура — не ваша зона

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

Хронология: как Google шёл к этому изменению

Дата	Что произошло
Сентябрь 2024	Google запускает confidential matching: сопоставление первичных данных внутри доверенной среды, по умолчанию для Customer Match и Data Manager, без доплаты.
Апрель 2025	На Data Protection Forum Google описывает схему: данные шифруются до попадания в среду, матчинг идёт внутри, наружу выходят только совпадения, несовпавшие записи удаляются.
Декабрь 2025	Запуск Data Manager API с задокументированным шифрованием XChaCha20-Poly1305 и обёрнутыми ключами в KMS облака. На этом этапе шифрование — опция поверх хеширования.
Май 2026	В Data Manager API появляется поле для зашифрованных пользовательских идентификаторов — сигнал, что вектор не на хеши.
18 октября 2026	В публичном доступе оказывается письмо Google «Encryption in Google Ads Data Manager» с датой перехода.
16 ноября 2026	Шифрование в Data Manager становится форматом по умолчанию; требование хешировать SHA-256 снимается.

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

Как выглядит разбор одного потока на практике

Возьмём типовой случай: интернет-магазин, у которого раз в сутки уходит список покупателей за 540 дней для Customer Match и отдельно — офлайн-конверсии по звонкам из колл-центра. Разбор занимает один вечер и выглядит так.

Где начинается поток. Витрина в BigQuery, представление crm.customers_for_google. Внутри — TO_HEX(SHA256(LOWER(TRIM(email)))). Это и есть точка миграции: один слой представления, не весь пайплайн.
Что отправляет файл. Планировщик дёргает скрипт, скрипт кладёт CSV в бакет, Data Manager забирает его по расписанию. Значит, маршрут — «импорт из облачного хранилища», и переключение формата потребует правки ровно двух вещей: SQL и, возможно, схемы колонок.
Какой сейчас match rate. Открываем аудиторию, записываем: размер списка, процент совпадений, дату снимка. Отдельно — то же самое по офлайн-конверсиям: сколько строк отправлено и сколько принято за последние 14 дней.
Где сломается тихо. У звонков телефон хранится в трёх вариантах — с восьмёркой, с плюсом и без кода страны. Сейчас часть из них просто не матчится. После перехода нормализацию берёт на себя Google, и эта часть может «ожить» — то есть количество конверсий вырастет не потому, что выросли продажи. Этот эффект стоит заранее описать в комментарии к отчёту, иначе в декабре его спишут на удачную креативную гипотезу.
Кто отвечает. Аналитик — за SQL и формат, байер — за мониторинг объёмов и аудиторий, юрист — за описание потока в приватной документации. Если все три роли — один человек, тем важнее записать план на бумаге до даты.

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

FAQ

Что конкретно происходит 16 ноября 2026 года?

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

Хеширование запретят?

В опубликованной части письма запрета нет — сказано только, что Google «больше не требует» хеш. Будет ли старый формат приниматься после этой даты, в письме не описано, поэтому ориентируйтесь на собственные логи загрузок и на справку Google, когда она появится.

Это касается только Customer Match?

В письме названы Customer Match и расширенные конверсии, а также все четыре маршрута загрузки: CRM-коннекторы, импорт из облачного хранилища, прямая загрузка файлов и Data Manager API. Про DV360 и Google Analytics, которые тоже используют Data Manager API, в письме ничего не сказано.

Нужно ли что-то делать, если я граблю данные руками через интерфейс?

Да, но меньше. Главное — знать, в каком виде вы готовите файл, и после 16 ноября проверить процент совпадений по загруженному списку. Если он резко изменился в любую сторону, это повод пересобрать шаблон выгрузки.

Станет ли match rate выше?

Google обещает улучшение точности за счёт снятия ошибок форматирования, но не приводит ни процента, ни теста, ни базы сравнения. Реальную дельту увидит только тот, кто зафиксировал свой match rate до изменения.

Кто будет держать ключ шифрования?

Для Data Manager API схема с ключами, обёрнутыми в облачный KMS, задокументирована с декабря 2025 года. Для CRM-коннекторов, импорта из хранилища и прямой загрузки письмо этот вопрос не раскрывает.

Значит ли это, что Google теперь видит мои данные в открытом виде?

Корректная формулировка: данные расшифровываются и нормализуются внутри доверенной среды исполнения. Утверждения в духе «Google всё видит» и «Google не видит ничего» одинаково выходят за рамки того, что сказано в письме. Если вопрос для вас юридически значимый, его стоит задать представителю Google письменно и получить ответ в переписке.

Меняются ли из-за этого мои обязанности по GDPR?

Смена технического формата передачи сама по себе не переносит ответственность: контролёр данных — по-прежнему рекламодатель. Но описание потока данных в ваших внутренних документах может перестать соответствовать фактам, и это стоит проверить с юристом до даты, а не после жалобы.

Что делать, если мой CRM-вендор молчит?

Зафиксируйте запрос письменно, снимите бейзлайн match rate и поставьте алерт на объём принятых строк. Если после 16 ноября загрузки начнут падать, у вас будет и дата, и цифры для эскалации, а не ощущение «кажется, стало хуже».

Как это связано с confidential matching?

Confidential matching — это слой, где происходит само сопоставление внутри изолированной среды, и он работает с 2024 года. Ноябрьское изменение меняет формат, в котором данные в этот слой попадают: не необратимый хеш, а шифрование с расшифровкой уже внутри среды.

Может ли это сломать аудитории, которые уже работают?

Прямых указаний на это нет, но риск сосредоточен в регулярных автоматических выгрузках, за которыми никто не следит. Поэтому единственная по-настоящему обязательная подготовка — мониторинг загрузок и зафиксированный бейзлайн.

Где следить за официальной информацией?

За справкой Google Ads Data Manager и за release notes Google Ads API: именно там обычно появляются точные формулировки и имена полей. До этого момента любые детали, включая изложенные в этой статье, стоит считать описанием письма, а не документацией.

Шифрование в Data Manager вместо SHA-256: что проверить в выгрузках до 16 ноября 2026