Телефоны и почта в CRM: формат для Яндекс Метрики
Метрика ищет визит по совпадению строк. Телефон со скобками или почта с заглавной буквой пары не найдут — и ошибки не будет.
Метрика сравнивает строки, а не людей
Если сделки из CRM не привязываются к рекламе, хотя передача настроена и ошибок нет, — скорее всего, дело в формате контактов. Это механическая проблема, и она чинится правилами.
Нормализация контактов — приведение телефонов и почт в CRM к единому формату перед передачей в Метрику. Она нужна потому, что Метрика ищет визит для заказа по совпадению строк: телефон должен быть записан цифрами с кодом страны, почта — строчными буквами. Значение, записанное иначе, пары не находит, и никакой ошибки при этом не возникает. Проблема не в рекламе и не в интеграции — она на уровне данных, и именно там её нужно искать.
Коротко: пять фактов, которые объясняют всё
- 01
Метрика привязывает заказ из CRM к визиту по ClientID, телефону или почте. ClientID надёжнее всего, телефон и почта — запасной путь.
- 02
Телефон нужно передавать цифрами с кодом страны, без пробелов и символов: 79995551111, а не 7 (999) 555-11-11. Почту — без заглавных букв.
- 03
Один номер в семи написаниях даёт семь разных хешей, и совпадает только одно написание.
- 04
Если захешировать номер в неправильном формате самому, Метрика не сможет понять, к какому визиту относится заказ.
- 05
Чтобы телефону из CRM было с чем совпасть, Метрика должна получить его с сайта — для этого есть опция дополнительных настроек отслеживания.
Почему доля привязки падает без ошибок
Представьте типичную ситуацию: передача сделок из CRM настроена, загрузки проходят, в интерфейсе всё зелёное. Но в отчёте Метрики об источниках заказов их заметно меньше, чем в CRM, и со временем разрыв растёт. Первая мысль — что-то с рекламой. Вторая — что-то с интеграцией. Обе, как правило, ошибочные.
Главная причина чаще оказывается механической. Метрика не знает людей — она сравнивает строки. Если телефон в CRM записан со скобками, а на стороне сайта он пришёл цифрами, это две разные строки. Пары нет, заказ остаётся без визита, и сообщить об этом некому: ошибки ведь не было.
Доля привязки может падать и со временем — без каких-либо изменений в настройках. Подключили новую форму или телефонию, которая записывает номер по-своему. Менеджеры вводят часть контактов руками — со скобками, пробелами, восьмёркой. Один клиент попадает в две карточки с разными написаниями. Каждое такое изменение ничего не ломает: оно просто добавляет строки, которые не найдут пару. Важно понимать, что формат — не единственная причина непривязки: у заказов есть ещё сроки, в течение которых они могут прикрепиться к визиту, — это отдельная тема.
Две строки: что Метрика знает с сайта и что приходит из CRM
Привязка заказа к визиту — это встреча двух сторон. Чтобы она состоялась, обе стороны должны говорить об одном и том же контакте одинаковыми словами.
Сторона CRM. Вы передаёте телефон или почту клиента — открытым текстом или хешем. Справка задаёт формат жёстко: телефон — числовая строка с кодом страны, без пробелов и символов; почта — латиница с символом @ и доменом, без заглавных букв. Если хешируете сами, нормализуйте до хеширования: хеш от неправильно записанного номера Метрика сопоставить не сможет. Подробнее о путях доставки данных из CRM и о том, что одного параметра клиента достаточно для упрощённого формата, — в отдельной статье.
Сторона сайта. Чтобы телефону из CRM было с чем совпасть, Метрика должна связать этот телефон с посетителем. Для этого есть опция дополнительных настроек отслеживания: на сайтах с HTTPS она передаёт в Метрику в хешированном виде телефон и почту, которые человек ввёл в форму. Есть и ручная передача через JavaScript-метод — по оценке Яндекса, она собирает в два-три раза больше данных, чем автоматическая. Справка прямо рекомендует эту опцию, если ClientID записать не получается.
Самый надёжный способ по-прежнему ClientID — идентификатор посетителя, записанный в сделку при создании. Телефон и почта — запасной путь для тех сделок, где ClientID нет: звонки, офлайн-покупки, обращения, пришедшие мимо формы. О том, как передавать ClientID через скрытое поле, — в статье о настройке целей в Метрике под сквозную аналитику.
механика совпадения
Как заказ находит свой визит
Профиль справочника: как понять, что происходит у вас
Прежде чем что-то чинить, полезно понять масштаб. Выгрузите телефоны и почты из CRM и посмотрите, сколько записей приходится на каждый шаблон написания. Это и есть профиль справочника — он показывает, какая доля контактов вообще имеет шанс совпасть при нынешнем состоянии данных.
Один номер в семи написаниях: 79995551111, +79995551111, 89995551111, 9995551111, 7 (999) 555-11-11, +7 999 555-11-11, 8-999-555-11-11. Для человека это один телефон. Для алгоритма хеширования — семь разных строк. С эталонным совпадает только первый вариант. С почтой так же: одна заглавная буква, пробел в начале или в конце — и хеш другой.
| Как записано | Годится как есть | Чинится автоматически | Что делать |
|---|---|---|---|
| 79995551111 | да | — | ничего |
| +7 или 7 с пробелами, скобками, дефисами | нет | да | убрать всё, кроме цифр |
| 8 9XX… (11 цифр с восьмёркой) | нет | да | заменить первую восьмёрку на семёрку |
| 9XX… (10 цифр без кода страны) | нет | да | добавить семёрку в начало |
| С добавочным, два номера в поле, текст | нет | нет | разобрать вручную: один номер — одно поле |
| Городской номер | формат справки описывает мобильный | — | на привязку не рассчитывать, проверить на своих данных |
| Почта с заглавными или пробелами по краям | нет | да | привести к строчным, убрать пробелы |
| Почта с опечаткой в домене или без @ | нет | нет | исправить вручную или исключить |
Два места, которые нужно проверить у себя, а не принимать на веру: нормализует ли номера сам коннектор вашей CRM, если он передаёт данные напрямую, — это проверяется тестовой сделкой, а не документацией. И не превращает ли маска в форме номер в строку со скобками при сохранении в CRM — такое встречается, когда форма показывает номер красиво, а в базу пишет то, что видит пользователь.
модельный расчёт
Сколько контактов возвращают три правила нормализации
Профиль на 1000 контактов — модельный, не бенчмарк. У вас профиль свой.
до нормализации
после трёх правил
При таком профиле больше двух третей контактов не имели шанса совпасть ещё до всякой рекламы. И это никак не видно в интерфейсе: загрузки проходят, ошибок нет, просто заказы остаются без визита. Именно поэтому снятие профиля справочника — первый шаг, а не диагностика рекламных кампаний.
Как нормализовать и не испортить снова
Правила для выгрузки. Нормализуйте на выходе из CRM — в той копии данных, которая уходит в Метрику, а не переписывайте оригиналы в карточках вслепую. Так ничего не потеряется, если правило ошибётся. Для российских мобильных номеров работают три правила из расчёта: убрать всё, кроме цифр; заменить первую восьмёрку на семёрку; добавить семёрку к десяти цифрам. Почту привести к строчным и убрать пробелы по краям. Если хешируете сами — сначала нормализация, потом хеш, и проверьте алгоритм на контрольных значениях из справки: хеш от mail@yandex.ru должен быть 3c56ff8fef0f6c65b36b2d25720fe276, хеш от 79995551111 — f09f2c3d48f31e2a802944ade2e5aec5. Правовая сторона передачи контактов разобрана в отдельной статье о 152-ФЗ.
Чтобы профиль не испортился снова. Одно поле — один номер, добавочный — в отдельное поле. Проверьте, в каком виде номер сохраняется из каждого источника: формы, телефонии, мессенджеров, ручного ввода. Объединяйте дубли карточек — иначе заказ может оказаться у той копии, где контакт записан неправильно. Для B2B отдельный момент: если в карточке только офисный номер компании, а мобильного у контактного лица нет, привязать такую сделку по телефону не получится — это аргумент в пользу того, чтобы записывать мобильный контактного лица.
Если контакты в Метрику передаёт система сквозной аналитики — Roistat, Calltouch, CoMagic, K50 или другая — формат на выходе задаёт она, и его тоже стоит проверить.
Как проверить, что сработало: три шага
- 01
Снимите профиль справочника до и после нормализации. Доля записей в формате 79XXXXXXXXX должна вырасти. Это базовый замер, который показывает, что правила сработали на ваших данных.
- 02
Проведите тестовую сделку с номером в «грязном» формате — например, со скобками. Посмотрите, в каком виде он уходит в Метрику и прикрепляется ли заказ к визиту. Это заодно покажет, нормализует ли номера ваш коннектор самостоятельно.
- 03
Раз в месяц сверяйте число оплаченных сделок за период в CRM и число оплаченных заказов в отчёте Метрики об источниках заказов. Сравнивайте новые периоды со старыми: нормализация не прикрепит задним числом заказы, срок привязки которых уже прошёл.
чек-лист
Что проверить до следующей загрузки в Метрику
Типичные ошибки, которые не видно в интерфейсе
Как это выглядит на практике
- Телефон из формы с маской сохраняется в CRM как «7 (999) 555-11-11» — маска отображает красиво, но пишет в базу то, что видит пользователь.
- Коннектор CRM передаёт номер «как есть», без нормализации — и никто не проверял, так ли это.
- При ручном вводе менеджер пишет «89995551111» или «9995551111» — оба варианта не совпадут с эталоном.
- Один клиент в двух карточках: в одной номер правильный, в другой — со скобками. Заказ попадает к «неправильной» копии.
- Хеширование делается до нормализации — хеш правильный по алгоритму, но от неправильной строки.
Как это проверить
- 01
Тестовая сделка с номером в «грязном» формате: посмотрите, что уходит в Метрику на самом деле.
- 02
Профиль справочника: выгрузите телефоны и посчитайте шаблоны — это покажет масштаб проблемы.
- 03
Проверка контрольными значениями из справки, если хешируете сами.
- 04
Регулярная сверка: число оплаченных сделок в CRM vs. число оплаченных заказов в отчёте Метрики.
Хорошая новость в том, что всё это чинится не перенастройкой интеграции и не правками в рекламных кампаниях — а правилами обработки данных на выходе из CRM. Три автоматических правила для мобильных номеров и одно для почты закрывают большую часть проблем. Остальное — ручной разбор нестандартных случаев и регулярный мониторинг новых источников контактов.
Главное: проблема механическая, решение тоже
- 01
Снимите профиль справочника: выгрузите телефоны и посчитайте, сколько записей уже в формате 79XXXXXXXXX, а сколько — нет.
- 02
Примените три автоматических правила для мобильных номеров и одно для почты — это закрывает большинство случаев.
- 03
Нормализуйте на выходе из CRM, не трогая оригиналы в карточках: так ничего не потеряется.
- 04
Если хешируете сами — сначала нормализация, потом хеш, и проверьте на контрольных значениях из справки.
- 05
Проверьте каждый источник контактов отдельно: форму, телефонию, мессенджеры, ручной ввод.
- 06
Раз в месяц сверяйте число сделок в CRM с числом заказов в отчёте Метрики — это покажет, работает ли нормализация.
Формат контактов — не единственная причина, по которой заказы могут не привязываться к визитам. Есть ещё сроки привязки и другие факторы. Но формат — самая механическая из причин, и именно с него удобнее всего начинать: он виден в данных, чинится правилами и не требует изменений в рекламных кампаниях или настройках интеграции.
Часто задаваемые вопросы
Одна из самых незаметных причин — формат контактов. Если в сделке нет идентификатора посетителя, Метрика ищет визит по телефону или почте и сравнивает строки. Телефон со скобками, пробелами или восьмёркой вместо семёрки — другая строка, чем тот же номер цифрами с кодом страны. Почта с заглавной буквой — тоже. Пары нет, заказ остаётся без визита, а ошибки в интерфейсе не появляется: загрузка прошла успешно. Проверить это можно, сняв профиль справочника — сколько записей уже в нужном формате. Формат — не единственная причина: у привязки есть ещё сроки, но начинать разумно с него, он чинится правилами.
Телефон — числовой строкой с кодом страны, без пробелов, скобок, дефисов и плюса: например, 79995551111. Почту — латиницей, с символом @ и доменом, без заглавных букв: mail@yandex.ru, а не Mail@yandex.ru. Так формат описан в справке для данных о клиентах и заказах из CRM. Если хешируете значения сами, сначала приведите их к этому виду, а потом хешируйте каждую запись отдельно. Проверить алгоритм можно на контрольных значениях из справки: хеш от mail@yandex.ru и от 79995551111 должен совпасть с указанным там. Формат описывает мобильный номер; на привязку по городскому номеру рассчитывать не стоит.
Не обязательно. Можно передавать телефоны и почты открытым текстом: справка указывает, что в сыром виде они в Метрике не хранятся и хешируются на её стороне. Можно хешировать самостоятельно — тогда важно нормализовать данные до хеширования. Хеш от номера со скобками или от почты с заглавной буквой — это другой хеш, и Метрика не сможет определить, к какому визиту относится заказ. Выбор между открытым текстом и хешем — вопрос не только техники, но и обработки персональных данных, поэтому его стоит согласовать с тем, кто отвечает у вас за эту часть. Техническое требование в обоих случаях одно: правильный формат.
Скорее всего, менялось не в настройках, а в данных. Новая форма на сайте или подключённая телефония могут записывать номер в своём формате. Часть контактов менеджеры вводят вручную — со скобками, пробелами, восьмёркой. Один клиент оказывается в двух карточках, и заказ попадает к той, где телефон записан неправильно. Каждое такое изменение ничего не ломает, оно просто добавляет строки, которые не найдут пару. Поэтому профиль справочника полезно снимать не один раз, а регулярно, и отдельно проверять формат для каждого нового источника контактов, прежде чем он начнёт массово писать в CRM.
Спасибо за заявку!
Мы свяжемся с вами в ближайшее время.
