CRM-база для Яндекс Аудиторий: проверка перед загрузкой

Перед загрузкой базы в Яндекс Аудитории полезно разделить три вещи: техническую пригодность файла, объём сопоставленных пользователей и законность использования данных. Подготовка файла CRM-сегмента для Яндекс Аудиторий заканчивается проверенным CSV; сегмент, по которому можно запускать рекламу, появляется позже — после порога записей, сопоставления и подтверждённого разрешения. Шесть учебных строк показывают, где срабатывает нормализация, где появляется дубль и почему часть строк остаётся в статусе ожидания.

Учебный пример

Реальные контакты нормализуются и хешируются в вашей инфраструктуре, публичному чату показываются только обезличенные строки.

Выбрать CRM или универсальный формат

У Аудиторий два разных маршрута загрузки, и поля у них не совпадают. Универсальный сегмент принимает колонки под каждый тип данных: phone, email, idfa_gaid, mac, client_id, а также произвольные колонки, которые сохраняются, но не участвуют в матчинге. CRM-маршрут строится вокруг полей клиента: external_id, phone, email и дополнительных сведений вроде пола или даты рождения. В записи CRM должно быть хотя бы одно из полей phone или email, остальные необязательные.

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

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

Подготовить локальную таблицу

Вход — вымышленный CSV из шести строк, собранный специально для проверки правил. Колонки: id, phone, email, allowed (разрешение на использование контакта). Реальные контакты, даже в таком виде, в публичный чат передавать не нужно: нормализация телефона, приведение email к нижнему регистру и вычисление SHA-256 выполняются на вашей стороне, а модель может видеть только строки-примеры.

id	phone	email	allowed
R1	7 (999) 555-11-11	Test@Example.test	true
R2	79995551111	test@example.test	true
R3	—	—	true
R4	9995551111	—	true
R5	—	ok@example.test	null
R6	—	ready@example.test	true

R4 содержит только цифры, но без кода страны, и угадывать его нельзя. У R3 нет ни телефона, ни email. У R5 неизвестно разрешение. Эти три состояния дают разные решения.

Сформировать CSV-проект по эталону

Ожидаемые действия по строкам — ручной редакционный эталон; модель их не составляла:

• R1 — нормализовать: телефон привести к виду без пробелов и лишних символов (79995551111), email — к нижнему регистру без прописных букв. Получается test@example.test.
• R2 — после нормализации телефон и email совпадают с R1. Это дубль: связать запись с R1 и сохранить в протоколе оба исходных идентификатора.
• R3 — отклонить: нет ни phone, ни email, а хотя бы одно поле обязательно.
• R4 — удержать как hold_unknown: телефон без кода страны — гипотеза, а не факт. Угаданный код может соответствовать чужому человеку.
• R5 — удержать как hold_unknown по разрешению: технически валидный email не равен согласию на загрузку.
• R6 — оставить кандидатом: email нормализован, разрешение подтверждено.

Итог учебной проверки — две кандидатные строки, R1 и R6. В протоколе сохраняются исходные ID всех шести строк и причины решения по каждой: так дубль остаётся связанным с первоисточником, а статус ожидания не теряется.

CSV-проект для CRM-маршрута после нормализации. Формат учебный: две строки, файл меньше 100 записей.

external_id,phone,email
R1,79995551111,test@example.test
R6,,ready@example.test

Протокол нормализации на все шесть исходных ID:

id	решение	причина	связь
R1	candidate	нормализован, разрешение подтверждено	—
R2	duplicate	совпал с R1 после нормализации	R2 → R1
R3	reject	нет ни phone, ни email	—
R4	hold_unknown	нет кода страны, не угадываем	—
R5	hold_unknown	разрешение не подтверждено	—
R6	candidate	нормализован, разрешение подтверждено	—

Если планируете просить ИИ помочь с этим разбором, отдавайте ему правила и разметку строк, а не выгрузку. Промпт можно собрать так:

Правила:
- телефон: цифры с кодом страны, без пробелов и символов;
- email: латиница в нижнем регистре;
- в записи должен быть phone или email;
- код страны не угадывать, без него — hold_unknown;
- пустое разрешение (unknown) — hold_unknown;
- если после нормализации phone или email совпал с более ранней строкой — duplicate со ссылкой на исходную строку.

Строки (csv):
id,phone,email,allowed
R1,7 (999) 555-11-11,Test@Example.test,true
R2,79995551111,test@example.test,true
R3,,,true
R4,9995551111,,true
R5,,ok@example.test,
R6,,ready@example.test,true

Формат ответа: таблица id | решение | причина | связь.

Ответ модели — проект: сверьте его построчно с ручным эталоном выше. Если модель угадала код страны у R4 или пропустила R5 в кандидаты при неизвестном разрешении, ответ не принимается.

Отделить корректный файл от готового сегмента

Две кандидатные строки на выходе не приближают к загрузке. В CRM-файле минимальное количество записей — 100. Универсальный сегмент держит тот же порог. Учебный пример из шести строк проходит локальную проверку логики и остаётся учебным: он меньше десятой части минимального порога, и даже если добить его фиктивными контактами, файл не станет рабочим сегментом.

Сборка исходной базы — отдельная задача: разбор пересборки пользователей в ретаргетинг из CRM и общие приёмы локальной дедупликации в снижении дублей CRM.

Последовательность проверок перед загрузкой выглядит так:

1. Формат — колонки совпадают с выбранным маршрутом (CRM или универсальный сегмент), хеш помечен тем способом, который требует выбранная форма.
2. Нормализация — phone без пробелов и символов, email в нижнем регистре, SHA-256 считается после нормализации.
3. Дедупликация — совпавшие нормализованные идентификаторы связаны, исходные ID сохранены.
4. Обязательное поле — в каждой записи есть phone или email.
5. Разрешение — у контакта подтверждено основание для рекламного использования; технически валидный адрес его не заменяет.
6. Порог — файл достигает минимум 100 записей.
7. Матчинг — сколько пользователей Аудитории сопоставят с записями, файл не сообщает: по чистоте CSV эту долю не предсказать.

MD5 не новый формат загрузки: с января 2025 года загрузка новых хешей MD5 не поддерживается, используется SHA-256. Финальный файл не гарантирует охват — порог, сопоставление пользователей и разрешённость использования это разные проверки.

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