Офлайн-конверсии позволяют учитывать события, которые происходят после посещения сайта: квалификацию обращения, встречу или оплату. Для бизнеса важна не сама загрузка файла, а достоверная связь между рекламой и результатом работы с клиентом. Если CRM заполнена непоследовательно, интеграция перенесёт ошибки в отчёт. Поэтому сначала договоритесь о событиях и правилах их учёта, затем подключайте передачу. Ниже — рабочая последовательность для маркетолога, CRM-специалиста и руководителя продаж.
Выберите событие с однозначным смыслом
«Хорошая заявка» — слишком расплывчатое название. Лучше определить событие через проверяемое действие: подтверждена потребность, согласован просмотр или получена оплата. Для каждого события опишите, кто и на основании чего меняет статус.
Не объединяйте отправку формы и состоявшуюся продажу в одну цель. Эти события отвечают на разные вопросы. Если менеджер переносит сделку назад по воронке, нужно заранее решить, что происходит с ранее переданным событием и как отражать исправления.
Проверьте, как сохраняются идентификаторы
Яндекс описывает связь событий с посещениями в справке об офлайн-конверсиях. Поддерживаемые поля и формат передачи сверяйте с актуальной документацией загрузки: не стоит воспроизводить интеграцию по старому скриншоту интерфейса.
На своей стороне проверьте путь данных: форма → обработчик → CRM → выгрузка. Звонки и обращения из мессенджеров могут требовать отдельной схемы. Наличие меток в адресе сайта не означает, что нужные идентификаторы дошли до карточки клиента.
Составьте таблицу соответствий
| Поле | Что определить до запуска |
|---|---|
| Событие | Название и условие фиксации |
| Время | Момент действия, а не время выгрузки |
| Идентификатор | Источник и правило сохранения |
| Сумма | Оплата, выручка или другая согласованная величина |
| Повторная отправка | Как предотвращаются дубли |
| Ошибка | Кто получает уведомление и исправляет запись |
Условный пример: сделка на 200 000 ₽ оплачена двумя частями. Если передавать и полную стоимость сделки, и оба платежа как одну и ту же выручку, отчёт завысит результат. Выберите модель учёта и используйте её последовательно во всех выгрузках.
Проверьте небольшую выборку вручную
- Создайте контролируемые тестовые обращения.
- Проверьте сохранение полей в CRM.
- Переведите тестовые записи в нужный статус.
- Проверьте загрузку и привязку события в отчёте.
- Повторите отправку и убедитесь, что результат не задвоился.
- Исключите тестовые события из рабочих выводов.
Отдельно проверяйте два числа: сколько событий отправлено и сколько удалось связать с визитами. Это разные показатели. Причины непривязанных событий разбирайте в отчёте, а не списывайте все расхождения на «погрешность аналитики».
Когда использовать данные в управлении рекламой
Сначала убедитесь, что события поступают регулярно и означают одинаковое действие. Редкая продажа с большой задержкой может быть неудобна для оперативного контроля; промежуточное событие полезно, если оно действительно связано с результатом и стабильно фиксируется.
Не передавайте в рекламную аналитику диагнозы, содержание медицинских обращений и другие чувствительные сведения. Состав и основания обработки данных согласуйте с ответственным за персональные данные. Маркетинговая задача не требует выгрузки всей карточки клиента.
После запуска сверяйте итоги с CRM и храните журнал ошибок. Для длинных сделок используйте когортный подход в продажах компаниям-аналитике, а для оценки стоимости результата — разделение CPL, qCPL и CAC.
Протокол приёмки передачи офлайн-конверсий
До запуска зафиксируйте способ передачи, счётчик, цель, поддерживаемый идентификатор и правила времени события. Не смешивайте схему CSV для офлайн-конверсий с форматом отдельной Интеграции с системой учёта клиентов. Актуальные поля и ограничения проверяйте в инструкции Метрики по передаче данных.
| Проверка | Что сохранить в протоколе | Условие приёмки |
|---|---|---|
| Смысл события | Этап CRM и момент его наступления | Менеджер и аналитик одинаково понимают событие |
| Идентификатор | Тип и наличие значения; в отчёте — маска | Значение сохраняется от визита до нужной записи CRM |
| Цель | Счётчик и идентификатор цели | Они соответствуют выбранному способу передачи |
| Время | Время события, пояс, время отправки | Передаётся время бизнес-события, не дата запуска выгрузки |
| Передача | Обезличенный ID теста, статус обработки, ошибка | Система не считает HTTP-ответ доказательством появления конверсии в отчёте |
| Повтор | Поведение при повторной отправке | Проверено правило дедупликации выбранного метода; дублей не возникает |
| Ошибка | Отсутствующий идентификатор или обязательное поле | Некорректная запись видна в журнале, не теряется молча |
| Сверка | Счётчик событий CRM, принятых записей и отчёта | Расхождения объяснены после срока обработки сервиса |
Начните с разрешённого тестового сценария. Не отправляйте вымышленные продажи в рабочую цель, которая используется для обучения рекламы. Тестовую запись нужно отличать от реального результата и обрабатывать по правилам вашей интеграции.
Для каждого теста запишите ожидаемый и фактический результат, дату проверки и ответственного. До приёмки не масштабируйте выгрузку. В журнале не храните телефоны, email и другие персональные данные, если достаточно внутреннего обезличенного ID.