Customer Match IP-адреса и таймстемпы в 2026: восемь колонок загрузки и где это не работает

В конце сентября 2026 года Google тихо переписал справку по загрузке списков Customer Match: в файле теперь может быть восемь колонок, и две из них новые — IP-адрес пользователя и таймстемп взаимодействия. Так в Customer Match IP-адреса впервые становятся полноценным идентификатором — и первым, который нельзя хешировать: он загружается в открытом виде. Разбираем, что именно изменилось в формате файла, какие комбинации полей допустимы, где новая механика не работает вообще, и стоит ли вам вообще отдавать IP-адреса ради прироста match rate.

Customer Match IP-адреса: что изменилось в формате загрузки

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

Восемь заголовков, которые принимает загрузчик:

Колонка	Хеширование	Комментарий
Email	SHA256 после нормализации	можно отдать в открытом виде — Google захеширует на стороне интерфейса
Phone	SHA256, формат E.164	номер без пробелов, с кодом страны
First Name	SHA256	работает только в паре с остальными полями адреса
Last Name	SHA256	то же
Country	без хеширования	двухбуквенный код
Zip	без хеширования	почтовый индекс
User IP address	без хеширования	IPv4 или IPv6 строкой, пробелы по краям обрезать
User interaction timestamp	без хеширования	время взаимодействия с этого адреса

Отдельное правило для мобильных идентификаторов: Mobile Device ID в этот набор не входит — файл с device ID должен содержать только эту колонку и ничего больше.

Требования к самому файлу не изменились: CSV в кодировке ASCII или UTF-8. UTF-16 не поддерживается — это частая причина, по которой выгрузка из старых CRM отваливается с невнятной ошибкой.

IP без хеширования: почему это важно

До сих пор логика Customer Match строилась на простом объяснении: вы хешируете контактные данные, Google не видит исходных значений, совпадение ищется по хешам. С IP-адресом так не получается. В документации формулировка прямая — передавать «обычной строкой, не хешировать».

Причина техническая и известная давно: пространство IPv4 — примерно 4,3 млрд значений, то есть хеш такого адреса перебирается за разумное время. Хеширование здесь не даёт защиты, а создаёт её иллюзию, поэтому Google и не требует его. Для рекламодателя это значит одну вещь: IP-адрес попадает в Google как есть, и решение о его передаче — это решение про приватность, а не про формат файла.

Email и телефон в Customer Match всегда подавались как «данные, которые Google не видит в открытом виде». Для IP-адреса это утверждение не действует. Если у вас есть внутренняя политика по передаче персональных данных подрядчикам, новая колонка должна пройти через неё, а не через настройки кабинета.

Таймстемп: что он значит и чем опасен его пропуск

Поле описано как «время зафиксированных взаимодействий с соответствующего IP-адреса». Концептуально Google оперирует двумя величинами — самым ранним и самым поздним взаимодействием, — но в CSV предусмотрен только один заголовок, что документация никак не разъясняет.

Форматы принимаются разные. Однозначны только два:

• 2026-08-15T00:01:54Z — UTC;
• 2026-08-14T17:01:54-07:00 — со смещением.

Более свободные варианты вроде Aug 14, 2026 17:01:54 формально проходят, но не несут часового пояса, и документация не говорит, какой пояс подставляется. Вывод практический: всегда отдавайте время в UTC с суффиксом Z — это единственный вариант, который читается одинаково при любой настройке аккаунта.

Теперь главное. Если IP загружен без таймстемпа, система берёт «последнего известного» пользователя этого адреса. Звучит безобидно, пока не вспомнишь, как устроена адресация у провайдеров: динамические адреса переназначаются, один публичный IP может закрывать целую квартиру, офис или точку общественного Wi-Fi. Выгрузка полугодовой давности без временных меток — это не «сегмент ваших клиентов», а сегмент тех, кто сегодня сидит за теми же адресами.

Какие комбинации полей допустимы

• IP с контактными данными — основной сценарий, усиливает сопоставление.
• Контактные данные без IP — классический Customer Match, ничего не изменилось.
• Только IP и таймстемп, без email и телефона — допускается.
• Только таймстемп, без IP и без контактных данных — ошибка загрузки.

Третий вариант выглядит привлекательно для тех, у кого нет контактной базы, но именно он самый рискованный по качеству: о точности сопоставления по IP ниже.

Где это не работает: ЕЭЗ, Великобритания и Швейцария

Ограничение сформулировано в справке однозначно: сопоставление по IP не поддерживается для конечных пользователей, находящихся в ЕЭЗ, Великобритании и Швейцарии. Поскольку таймстемп не может быть передан без IP, вся новая механика для этих рынков закрыта — это 30 стран ЕЭЗ плюс две.

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

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

API-линия: Data Manager, а не Google Ads API

Загрузка файлом — это только витрина. Технически возможность появилась раньше: в мае 2026 года в Data Manager API версии 1.7 добавили приём IP-адресов для Customer Match через составную структуру, где к обычным хешированным контактным данным прикладывается объект с адресом. Поле с адресом обязательное, два поля времени — начала и конца наблюдения — опциональные, но рекомендованные. На старте поддержку получил только Google Ads; Display & Video 360 в список не попал.

Это укладывается в общее направление: с весны 2026 года Data Manager стал обязательным маршрутом для новых интеграций Customer Match, а приём новых реализаций с IP-адресами и атрибутами сессии в импорте конверсий через Google Ads API закрыли ещё раньше. Если вы только строите пайплайн первичных данных, стройте его сразу на Data Manager — как он устроен и зачем нужен, мы разбирали в материале про передачу офлайн-покупок через Data Manager API.

Отдельный слой — шифрование. Для контактных данных существует механика, при которой сопоставление идёт в доверенной среде исполнения; как она устроена, описано в статье про confidential matching в Google Ads. Распространяется ли она на строки с IP-адресами, документация не уточняет — и это ещё один аргумент в пользу осторожности.

Match rate: чего ждать и чего не ждать

Обещание, с которым выкатывали функциональность в API, звучало так: IP-адреса вместе с временными метками помогут повысить match rate начиная с третьего квартала 2026 года. Квартал закончился, публичных цифр, подтверждающих эффект, в документации нет.

Важная оговорка из той же справки: match rate не является показателем качества списка. Высокая доля сопоставленных строк говорит лишь о том, что Google нашёл профили, а не о том, что это нужные вам люди. Разница принципиальная, когда речь идёт о сопоставлении по IP.

Независимые исследования точности связки «IP — человек» дают скромные цифры. Их стоит воспринимать как ориентир, а не как измерение работы Google (свою точность Google не публикует):

• связка IP с почтовым адресом оказывалась верной примерно в 13% случаев, IP с email — около 16%;
• шесть провайдеров данных сходились в одной и той же привязке к домохозяйству лишь в 6,4% случаев;
• по другому исследованию, около 23% резидентных IP попадали в заявленный географический таргет.

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

Порог в 100 и срок жизни списка

• Минимальный размер аудитории для показа во всех сетях — 100 пользователей.
• Match rate отображается только для загрузок через актуальный API и при наличии не менее 100 строк, сопоставленных с уникальными пользователями.
• Срок участия в списке ограничен 540 днями. Стоит знать, что в соседних разделах справки до сих пор встречается старая формулировка про «неограниченный срок по умолчанию» — ориентируйтесь на 540.
• Enhanced Matching, появившийся в августе 2026 года, работает с согласованными пользователями и ограничивает срок участия 60 днями против 540 у обычных списков.

Почему список «тает» и как это связано с порогом в 100 пользователей — подробно в материале про Customer Match и данные первой стороны.

Что делать: практическая последовательность

1. Решите вопрос с согласием до технической части

Google требует от рекламодателя исключить пользователей из ограниченных регионов и обеспечить корректные раскрытия и согласия в своих практиках сбора данных. Чекбокс в интерфейсе загрузки по-прежнему формулирует это как «данные собраны и передаются Google». Если ваша политика конфиденциальности не описывает передачу технических идентификаторов рекламным платформам — сначала правится политика, потом собирается файл. Как устроен сигнал согласия в связке с рекламой, разобрано в статье про Consent Mode v2.

2. Соберите выгрузку правильно

• Одна строка — одно взаимодействие с конкретного адреса, а не «последний известный IP клиента».
• Время — только в UTC с суффиксом Z.
• Фильтруйте строки с европейской геопривязкой на своей стороне.
• Не отдавайте адреса старше нескольких недель: чем старше строка, тем выше шанс, что адрес переназначен.
• Проверьте кодировку: ASCII или UTF-8, не UTF-16.

3. Тестируйте на сегменте, а не на всей базе

Соберите два списка: контрольный — только контактные данные, тестовый — те же пользователи плюс IP и таймстемп. Сравнивайте не match rate, а поведение аудитории: стоимость конверсии и объём. Если разница в метрике сопоставления есть, а в деньгах нет — вы добавили шум, а не охват.

4. Смотрите на уплотнение данных целиком

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

Как собрать выгрузку: логика запроса

Задача выглядит простой, пока не сядешь за SQL. Ошибка большинства первых выгрузок — взять из базы «последний IP клиента» и приложить к контактной строке. Это ровно тот сценарий, который документация описывает как рискованный.

Правильная логика ближе к журналу событий, а не к карточке клиента:

1. Берём таблицу взаимодействий — визиты, авторизации, оформления заказа — с полями: идентификатор пользователя, IP, время события.
2. Фильтруем по свежести. Разумное окно — последние 2–4 недели. Всё, что старше, выкидываем: адрес почти наверняка переназначен.
3. Отсекаем мусорные адреса. Внутренние диапазоны, адреса офиса, адреса мониторинга и ботов не имеют отношения к клиентам. Строка с офисным IP приведёт в аудиторию ваших же сотрудников и всех соседей по зданию.
4. Отбрасываем адреса с аномальной плотностью. Если за одним адресом числятся десятки разных пользователей, это почти наверняка корпоративный NAT, публичный Wi-Fi или мобильный оператор — такая строка не идентифицирует никого.
5. Фильтруем геопривязку. Строки, относящиеся к ЕЭЗ, Великобритании и Швейцарии, не отправляем.
6. Присоединяем контактные данные того же пользователя — email и телефон, нормализованные.
7. Форматируем время в UTC с суффиксом Z и проверяем кодировку файла.

Отдельный вопрос — что считать одним взаимодействием. Если пользователь заходил десять раз за неделю, десять строк не дадут десятикратного эффекта, но раздуют файл и упрутся в лимиты. Разумный компромисс: одна строка на пару «пользователь + адрес» с временем последнего взаимодействия.

Customer Match IP-адреса: риски, которые стоит проговорить с командой

• Правовой. IP уходит в открытом виде. Если политика конфиденциальности, договор с клиентами или внутренний регламент не предусматривают передачу технических идентификаторов, это нарушение процесса, а не настройка кампании.
• Качественный. Аудитория, собранная по адресам, может включать людей, которые никогда не были вашими клиентами, — соседей по NAT, следующего абонента динамического адреса, посетителей той же кофейни.
• Измерительный. Прирост match rate легко принять за прирост результата. Эти величины не связаны напрямую: сопоставление говорит о том, что профиль найден, а не о том, что он релевантен.
• Операционный. Новая колонка означает новый пайплайн и новое место для ошибки. Если выгрузка собирается руками раз в месяц, свежесть данных гарантированно будет хуже требуемой.

Стоит ли это делать вообще

Короткий ответ: да, если у вас уже выстроен контактный слой, и нет — если IP рассматривается как способ обойти нехватку данных.

Ситуация	Решение
Есть база email и телефонов, нужен прирост охвата	добавить IP и таймстемп как дополнительные колонки, сравнить на сегменте
Основной рынок — ЕС, UK или Швейцария	не использовать: механика не поддерживается
Контактной базы нет, есть логи сервера	не строить аудиторию на одних IP — точность связки низкая
Политика конфиденциальности не упоминает передачу идентификаторов	сначала правовая часть, потом загрузка
Данные старше месяца	не отдавать: адреса переназначены, «последний известный» пользователь будет чужим

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

Что делать с уже загруженными списками

Новые колонки не требуют пересобирать то, что уже работает. Существующие списки продолжают жить по старым правилам, и добавление IP — это отдельная ветка, а не миграция. Разумный порядок действий для аккаунта, где Customer Match уже используется:

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

Если по итогам теста разницы в деньгах нет, самый честный вывод — отказаться от передачи IP. Дополнительный идентификатор, который не приносит измеримого эффекта, — это лишний правовой и операционный риск без компенсации.

Где здесь PPC Rebels

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

FAQ

Какие новые колонки появились в Customer Match?

Две: «User IP address» и «User interaction timestamp». Вместе с email, телефоном, именем, фамилией, страной и индексом файл теперь может содержать восемь колонок.

Нужно ли хешировать IP-адрес?

Нет. IP передаётся обычной строкой без хеширования — как и таймстемп, страна и индекс. Хешируются только email, телефон, имя и фамилия.

Какой формат времени использовать?

Лучше всего ISO 8601 в UTC — например, 2026-08-15T00:01:54Z. Форматы без часового пояса принимаются, но документация не уточняет, какой пояс подставляется.

Что будет, если загрузить IP без таймстемпа?

Система возьмёт «последнего известного» пользователя этого адреса. Для старых выгрузок это означает сопоставление с посторонними людьми, потому что провайдеры переназначают адреса.

Можно ли загрузить список из одних IP-адресов?

Технически да — IP можно отдавать без контактных данных. Практически это рискованно: независимые исследования показывают низкую точность связки IP с конкретным человеком или домохозяйством.

Работает ли сопоставление по IP в Европе?

Нет. Для конечных пользователей в ЕЭЗ, Великобритании и Швейцарии механика не поддерживается, а таймстемп не передаётся отдельно от IP.

Поддерживает ли это Display & Video 360?

На момент запуска в API — нет, возможность получил только Google Ads.

Какой минимальный размер списка?

100 пользователей для показа во всех сетях. Match rate отображается при наличии не менее 100 строк, сопоставленных с уникальными пользователями, и для загрузок через актуальный API.

Сколько живёт список Customer Match?

Максимальный срок участия — 540 дней. Для Enhanced Matching ограничение жёстче: 60 дней.

Повысит ли это match rate?

Обещание прироста было дано при запуске в API, но публичных цифр, подтверждающих его, в документации нет. И сам Google отмечает, что match rate не показывает качество списка.

Какой формат файла принимается?

CSV в кодировке ASCII или UTF-8. UTF-16 не поддерживается.

Можно ли смешивать Mobile Device ID с остальными колонками?

Нет. Файл с мобильными идентификаторами должен содержать только эту колонку.