Если сегмент в Яндекс Аудиториях не собирается или собирается крошечным, причина чаще всего не в Яндексе и не в том, что “аудитория узкая”. Обычно ломается файл: формат, кодировка, мусор в контактах, неверное хеширование, дубли, телефоны менеджеров вместо клиентов. В итоге вы делаете выгрузку клиентской базы телефонов в Яндекс Аудитории, загружаете, ждете, а на выходе получаете почти ноль.

Ниже практичная схема, как подготовить CSV так, чтобы загрузка данных пользователей (телефоны, email) для рекламы нормально отработала. И чтобы сегменты Аудитории Яндекса для ретаргетинга было не стыдно запускать в Директ.

Как подготовить файл телефонов и email для Яндекс Аудиторий, чтобы сегмент реально собрался

Если сегмент в Яндекс Аудиториях не собирается или собирается крошечным, причина чаще всего не в Яндексе и не в том, что “аудитория узкая”. Обычно ломается файл: формат, кодировка, мусор в контактах, неверное хеширование, дубли, телефоны менеджеров вместо клиентов. В итоге вы делаете выгрузку клиентской базы телефонов в Яндекс Аудитории, загружаете, ждете, а на выходе получаете почти ноль.

Ниже практичная схема, как подготовить CSV так, чтобы загрузка данных пользователей (телефоны, email) для рекламы нормально отработала. И чтобы сегменты Аудитории Яндекса для ретаргетинга было не стыдно запускать в Директ.

Что Яндекс Аудитории ждут от файла

Сегмент “из CRM” загружается файлом CSV. Условия на самом деле простые, но важно выполнить их буквально.

Файл должен быть именно CSV (не XLSX, переименованный руками). Кодировка - UTF-8 или Windows-1251. Первая строка - заголовки полей, дальше каждая строка - отдельная запись, а значения разделены запятыми. Отдельно подчеркну про разделитель: в русской локали Excel любит сохранять CSV с точкой с запятой. Яндекс ожидает запятую, поэтому лучше открыть CSV в блокноте и одним взглядом проверить, что там реально стоит.

В каждой записи достаточно одного поля: phone или email. Остальные поля необязательны. Телефон должен быть строкой цифр с кодом страны, без пробелов и любых дополнительных символов. Яндекс прямо приводит пример “79995551111” как корректный формат.

Есть два важных ограничения, про которые часто забывают, пока не упрутся лбом. Во-первых, минимальный объем базы: не менее 100 записей. Во-вторых, максимальный размер файла: до 1 ГБ.

Если вы загружаете хешированные данные, используйте SHA-256. С января 2025 новые MD5-хеши не поддерживаются. В интерфейсе при создании сегмента обязательно включается опция “Хешированные данные” и выбирается SHA-256, иначе вы формально загрузите файл, но совпадение будет не тем.

После загрузки сегмент уходит в обработку. Это не ошибка и не “сломалось”, просто процесс может занять до двух часов.

Два пути: грузить “как есть” или грузить хеши

По сути есть два рабочих варианта.

Первый - загрузка телефона и email в явном виде. Это проще, меньше шансов ошибиться, быстрее диагностировать проблему. Если внутри компании нет жесткой политики по персональным данным, это самый быстрый способ запустить ретаргетинг клиентской базы в Яндекс Директ.

Второй - загрузка хешированных значений (SHA-256). Это нормальная практика, но она требует дисциплины. Любая ошибка нормализации до хеширования превращает запись в “не матчится”, даже если данные правильные по смыслу.

Если вы не уверены, что в компании умеют правильно нормализовать и хешировать, проще стартовать с явных данных, а потом перейти на хеши. Если политика требует сразу хешировать, просто относитесь к нормализации как к отдельному обязательному этапу, а не как к “да там и так нормально”.

Как привести телефоны к рабочему виду

Цель здесь не “сделать красиво”, а получить единый формат и вычистить мусор, который ломает совпадения.

Типовые причины провала совпадения данных всегда одни и те же: пробелы, скобки, дефисы, “доб. 123”, разные варианты +7, 8, 7, текст внутри ячейки (“тел: …”, “whatsapp …”), копипаст служебных номеров, коллтрекинг, телефоны сотрудников, дубли.

Рабочее правило простое: в итоговой колонке телефона должны остаться только цифры, с кодом страны, без лишних символов. Если это Россия, часто приводят к виду 7XXXXXXXXXX (11 цифр, начиная с 7). Важно не выдумывать “как правильно”, а выбрать один формат и привести к нему всю колонку одинаково.

Если в вашей базе часть клиентов записана через “8…”, часть через “+7…”, а часть вообще “(999) …”, не пытайтесь загрузить “как есть”. Вы загрузите, но потом будете гадать, почему сегмент маленький.

Как привести email к рабочему виду

С email проблема обычно не в домене, а в мусоре. Пробелы в начале или конце, случайные символы после копипаста, значения типа “нет”, “-”, “не указан”, несколько email в одной ячейке.

Минимальный стандарт: один email на одну строку и без пробелов по краям. Если дальше будете хешировать, лучше привести почты к одному виду заранее (часто делают нижний регистр) и закрепить это правило в чеклисте. Это не “требование Яндекса”, это способ не получить разные хеши из одного и того же адреса из-за мелочей.

Структура CSV: как должно выглядеть

На практике хватает двух колонок: phone и email. Можно оставить только одну, если у вас реально есть только телефоны или только email. По требованиям Яндекса достаточно одного поля phone или email в записи.

Минимальный пример:

phone,email
79995551111,client1@example.com
79261234567,
,client2@example.com

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

Хеширование SHA-256: где чаще всего ошибаются

Если вы делаете загрузку email-базы в Яндекс Аудитории или выгрузку клиентской базы телефонов в Яндекс Аудитории в хешах, критичен порядок действий.

Сначала нормализуете. Приводите телефон к цифрам с кодом страны. Чистите email, приводите к выбранному единому виду. Только после этого хешируете SHA-256. На этапе создания сегмента включаете “Хешированные данные” и указываете SHA-256.

Почему это важно: SHA-256 от +7 (999) 555-11-11 и от 79995551111 будет разный. Для вас это один клиент, для системы это два разных значения, и контакты хуже распознаются системой. А рассчитывать на “ладно, попробую MD5” больше нельзя, новые MD5-хеши не принимаются.

Перед загрузкой: короткая проверка, которая экономит час

Здесь не нужен длинный регламент. Достаточно трезвой проверки перед кликом “Создать сегмент”.

Проверьте, что у вас реально CSV, а не Excel. Откройте файл в простом редакторе и убедитесь, что разделитель запятая, а не точка с запятой. Убедитесь, что кодировка UTF-8 или Windows-1251. Проверьте пару строк глазами: телефон без пробелов и символов, email без мусора. Убедитесь, что в большинстве строк заполнено хотя бы одно поле phone или email. И проверьте объем: минимум 100 записей, иначе сегмент просто не имеет смысла создавать.

Если вы грузите хеши, дополнительно убедитесь, что это SHA-256, и что в интерфейсе включена опция хешированных данных.

Что делать после загрузки и как понять, что все ок

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

Если сегмент получился слишком маленьким, обычно причина одна из трех: база реально маленькая, сломана нормализация, либо в файле много не клиентских контактов (служебные, менеджерские, коллтрекинг). Самый быстрый способ диагностики: взять 50-100 строк из файла, проверить формат руками, и только потом повторять загрузку целиком.

Как это связано с Директом, ретаргетингом и look-alike

Сегмент из CRM - база для сценариев “использование сегментов аудиторий в Яндекс Директ”, “таргетинг на собственную базу e-mail в Директ”, “ретаргетинг клиентской базы в Яндекс Директ”. Дальше на нем строятся корректировки ставок, исключения, разделение на группы, а потом уже look-alike аудитория Яндекс Аудитории.

Но вся эта рекламная стратегия: собственная база + look-alike + соцсети начинается не с “гениального таргетинга”, а с того, что файл чистый.

Где здесь k-client и почему это уместно

k-client не про “магически собрать сегмент в Яндексе”. Он полезен на другом этапе: помогает быстрее собрать и расширить исходные списки контактов под вашу нишу, чтобы дальше вы уже делали сегментацию пользователей по базе данных для рекламы и загружали данные в Яндекс Аудитории. То есть сервис закрывает этап “где взять список и как его расширять”, а эта статья закрывает этап “как подготовить файл так, чтобы сегмент реально собрался”.