КОРОТКИЙ ОТВЕТ
Зачем передавать офлайн-конверсии из CRM
Интеграция CRM с Яндекс Метрикой передаёт реальные статусы и выручку из сделок как офлайн-конверсии, связывает их с рекламными визитами и помогает Директу оптимизироваться не по заявкам, а по продажам.
Офлайн-конверсии из CRM закрывают разрыв между рекламой и фактическим результатом. Сайт фиксирует отправку формы или звонок, но не знает, прошёл ли лид квалификацию, состоялась ли встреча, оплачен ли счёт и какую маржу принесла сделка. Эти данные появляются в CRM и должны вернуться в аналитический контур.
Цель проекта — не просто загрузить таблицу со сделками. Нужно устойчиво связать клиента с рекламным визитом, согласовать бизнес-статусы, исключить дубли, передавать ценность события и контролировать, почему часть конверсий не атрибутировалась.
Архитектура интеграции CRM, Метрики и Директа
На сайте Метрика создаёт идентификатор посетителя. При отправке формы сайт сохраняет этот идентификатор вместе с UTM-метками и другими данными в CRM. Когда сделка достигает согласованного статуса, интеграция передаёт в Метрику идентификатор, цель, время события и при необходимости выручку. Метрика ищет подходящий визит, добавляет конверсию в отчёты, а Директ может использовать её для анализа и оптимизации.
Не следует отправлять конверсию прямо из браузера после смены этапа менеджером. Источником истины должна быть серверная CRM или интеграционный слой: так событие не зависит от открытой вкладки и оставляет проверяемый журнал.
Какие идентификаторы сохранять в CRM
| Идентификатор | Откуда берётся | Роль |
|---|---|---|
| ClientID | Счётчик Яндекс Метрики на сайте | Основной способ связать CRM-событие с визитом пользователя. |
| yclid | Переход из Яндекс Директа | Связь с рекламным кликом, если параметр сохранён при обращении. |
| UserID | Внутренняя авторизация сайта | Объединение визитов известного пользователя в бизнес-системе. |
| Телефон и email | Форма, звонок или менеджер | Дополнительное сопоставление и данные о клиентах и заказах. |
| ID лида и сделки | CRM | Идемпотентность, аудит и защита от повторной отправки. |
Идентификаторы нужно записывать в отдельные технические поля без ручного редактирования. Если заявка проходит через webhook, коллтрекинг или промежуточную форму, эти поля должны сохраняться по всей цепочке. Потерянный ClientID нельзя достоверно восстановить задним числом из UTM-меток.
Официальная документация Яндекс Метрики рекомендует сохранять ClientID для онлайн-обращений и допускает передачу офлайн-событий по ClientID, UserID, yclid или PurchaseID. Чем больше корректных идентификаторов передано, тем выше вероятность атрибуции. Возможности и форматы сверены с разделом об офлайн-конверсиях Яндекс Метрики 10 августа 2026 года.
Какие статусы CRM превращать в цели
Нельзя отправлять каждый этап воронки как главную цель рекламной стратегии. События делят по бизнес-ценности и стабильности. Для обучения рекламы подходят только те статусы, которые команда заполняет одинаково и которые возникают достаточно часто.
| Событие | Когда отправлять | Ценность |
|---|---|---|
| Квалифицированный лид | Проверены потребность, контакт и соответствие целевому сегменту. | Ранняя цель для длинного цикла продаж. |
| Назначена встреча | Есть подтверждённые дата и участники. | Показывает переход к активной продаже. |
| Договор или счёт | Документ действительно отправлен клиенту. | Промежуточная цель с высокой ценностью. |
| Оплата | Платёж подтверждён учётной системой. | Основная цель с фактической выручкой. |
| Отмена или спам | Причина отказа утверждена и заполнена. | Нужна для анализа качества, но не как положительная цель. |
Для каждого события фиксируют правило перехода, владельца поля и источник суммы. Если менеджер может случайно перемещать сделку туда и обратно, интеграция должна решить, отправлять ли событие один раз, обновлять его или компенсировать отменой в другом аналитическом контуре.
Три способа передачи данных
Ручная загрузка CSV подходит для первой проверки структуры и разового восстановления данных. Она плохо подходит для регулярной оптимизации: задержки, человеческие ошибки и отсутствие автоматического журнала быстро снижают качество.
Готовый коннектор ускоряет запуск, если поддерживает нужную CRM, идентификаторы и статусы. До покупки нужно проверить, где хранится токен, как обрабатываются повторные события, передаётся ли выручка и можно ли увидеть необработанные записи.
API-интеграция оправдана для нескольких воронок, нестандартных статусов и строгого контроля. Она позволяет создать очередь, журнал, повторную обработку и собственные правила, но требует мониторинга и ответственного после запуска.
Этапы внедрения
- Аудит пути лидаПроверяем формы, звонки, UTM, ClientID, yclid, создание контакта и сделки.
- Словарь конверсийОпределяем события, цели, владельцев статусов, сумму и правила повторной отправки.
- Тестовый контурСоздаём контрольные обращения по разным каналам и проводим их до оплаты или отказа.
- ПередачаНастраиваем файл, коннектор или API, очередь ошибок и технический журнал.
- СверкаСравниваем число событий CRM, отправленных записей и привязанных конверсий.
- Запуск оптимизацииТолько после стабилизации выбираем цели для стратегии Директа.
Первые недели полезно параллельно смотреть старую и новую модель оценки рекламы. Резкий перенос бюджета на редкую цель может сделать обучение нестабильным. Для длинных продаж используют несколько уровней: раннюю качественную цель и более редкую оплату с ценностью.
Как контролировать качество атрибуции
Типовые причины потерь — форма не передала ClientID, значение затёрлось при объединении дублей, событие отправили слишком поздно, время указано неверно или цель не существует. Отчёт должен показывать конкретные записи с причиной, а не только общий процент успешности.
Персональные данные и безопасность обмена
Передача аналитических идентификаторов и данных CRM должна входить в утверждённую схему обработки персональных данных. Не отправляйте в журналы и технические уведомления открытые телефоны, email, комментарии менеджеров и содержимое сделок, если для диагностики достаточно внутренних ID и кода ошибки.
Токены Метрики хранят на сервере или в защищённом хранилище секретов, ограничивают нужным счётчиком и регулярно обновляют. Доступ к настройкам получают только ответственные сотрудники, а каждая ручная повторная отправка фиксируется. Если используется подрядчик или облачный коннектор, до запуска проверяют договор, место обработки, срок хранения и процедуру удаления данных.
Аналитика должна получать минимально необходимый набор: идентификаторы для сопоставления, бизнес-событие, время и ценность. Текст переписки, паспортные данные и документы клиента не улучшают атрибуцию и создают лишний риск.
Чек-лист перед запуском
- ClientID и yclid сохраняются во всех формах и каналах, где это возможно.
- Технические поля защищены от ручного изменения.
- Для каждой цели описаны статус, сумма, время и владелец.
- Повторная обработка не создаёт дубли конверсий.
- Есть журнал отправок и уведомление о накоплении ошибок.
- Тесты включают оплату, отказ, дубль и объединение контактов.
- CRM, Метрика и финансовый отчёт проходят регулярную сверку.
Часто задаваемые вопросы
Что лучше передавать: заявку или оплату?
Заявка уже фиксируется сайтом, а из CRM полезнее передавать квалификацию, встречу и оплату. Для оптимизации выбирают достаточно частое, стабильное и связанное с выручкой событие.
Можно ли настроить офлайн-конверсии без API?
Да. Для проверки можно использовать файл или доступный коннектор. API нужен, когда важны автоматическая отправка, несколько воронок, собственные правила, мониторинг и повторная обработка ошибок.
Почему продажа не привязалась к рекламному визиту?
Чаще всего отсутствует или неверен идентификатор, событие передано за пределами допустимого периода, время указано некорректно либо Метрика не нашла соответствующий визит. Причину нужно проверять по конкретной записи.
Продолжить по теме «CRM и управление»
Материал входит в тематический маршрут Sabitov Systems: от базовых решений к внедрению и практическим сценариям.