Офлайн-конверсии Яндекс Директа нужны, когда результат рекламы появляется после действия на сайте. Человек оставил заявку, менеджер подтвердил задачу, затем клиент оплатил услугу. Если аналитика видит только форму, она ещё не знает, какое обращение закончилось полезным результатом.
Передачу продаж из CRM в Метрику стоит принимать как последовательность проверяемых этапов. Сначала определяют событие, затем сохраняют связь с посещением, отправляют данные и проверяют их обработку. Сообщение подрядчика «интеграция включена» не заменяет эту проверку. Ниже порядок для владельца бизнеса, который помогает поставить предметную задачу специалисту.
Определите событие и правила его учёта
Выберите результат, который действительно подтверждается в CRM. Это может быть подходящее обращение, подписанный договор или полученная оплата. У этапа должны быть понятное определение, источник подтверждения и время наступления. Статус «успешно», который сотрудники используют по-разному, не даёт устойчивого основания для передачи.
Условный пример: клиент заполнил форму, менеджер подтвердил нужную услугу, позже поступила оплата. Здесь три этапа одного обращения, а не три новых покупателя. Событие формы не следует переименовывать в продажу. Отличия показателей и полезного результата разобраны в статье об эффективности Яндекс Директа.
Согласуйте поведение при повторном обращении и изменении статуса. Кто подтверждает квалификацию, что происходит после возврата, какие изменения требуют новой записи? Это правила вашего учёта. Их нужно описать до автоматизации, а не выбирать удобное толкование после появления расхождений.
Отдельно выберите формат передачи. Справка Метрики (откроется в новой вкладке) различает офлайн-конверсии и данные о клиентах и заказах из CRM. У форматов отличаются поля и возможности. Ниже рассматривается приёмка офлайн-события; не переносите на него произвольно схему полноценного импорта заказов.
Сохраните подходящий идентификатор вместе с обращением
Проверьте, может ли CRM связать подтверждённое событие с посещением сайта. Для этого в момент обращения сохраняют подходящий идентификатор. Номер сделки удобен внутри компании, но сам по себе не объясняет Метрике, какой визит найти. UTM-метки тоже не являются заменой такого идентификатора.
Для офлайн-конверсий используются, в частности, ClientID и yclid. Первый относится к посетителю в Метрике, второй к рекламному клику Директа. UserID требует заранее настроенной связи с ClientID; нельзя просто назначить незнакомому посетителю номер из CRM и считать сопоставление готовым. Выбор зависит от действующего формата и вашей схемы измерения.
Попросите специалиста показать обезличенный маршрут: обращение на сайте, сохранённое поле в CRM, событие после работы менеджера и запись для передачи. Наличие столбца с правильным названием ещё не подтверждает, что он заполняется реальными значениями и сохраняется после объединения дублей.
Если идентификатора нет, запишите ограничение. Не подставляйте значение другого посетителя ради привязки и не угадывайте источник по похожему времени. Данные без подтверждённой связи могут оставаться полезными для внутренней CRM-аналитики, но не должны превращаться в доказанную продажу конкретной кампании.
Проверьте данные и собственный журнал отправок
В описании передачи (откроется в новой вкладке) указаны идентификатор, Target и DateTime. Для этого формата нужна цель типа «Целевое событие». Target должен соответствовать её идентификатору, а DateTime отражает момент события в Unix-времени, в секундах. При подготовке даты учитывают часовой пояс счётчика. Время отправки файла и время фактической оплаты не следует смешивать.
Передача возможна через CSV или API. При ручной загрузке выбранный тип привязки должен соответствовать идентификатору в файле: yclid нельзя выдавать за ClientID. Для ручного разбора достаточно понять структуру и ответственность; постоянный поток требует контроля ошибок и задержек. Если готовая интеграция скрывает детали, попросите объяснить, где смотреть результат и кто получает сообщение о неудачной отправке.
| Этап | Какое доказательство нужно |
|---|---|
| Событие подтверждено | Понятный статус и время в CRM |
| Связь сохранена | Нужный идентификатор в записи обращения |
| Данные подготовлены | Корректные цель, время и выбранный формат |
| Передача выполнена | Ответ сервиса и собственная запись попытки |
| Привязка проверена | Доступные сведения об обработке и сверка состава |
В собственном журнале полезно различать подготовку, попытку, подтверждённый приём и последующую проверку. Для повторов нужен заранее определённый порядок: что можно отправить снова, как найти ту же запись и как исключить повторное действие вашей интеграции. Не обещайте автоматическую защиту от любых дублей без проверки конкретного механизма.
Учтите окна и текущие ограничения сервисов
Срок хранения сделки в CRM не равен доступному сроку дополнения визита. Общая документация Метрики описывает 21 день, но на дату проверки, 3 ноября 2026 года, действует специальный режим (откроется в новой вкладке). Период временно сокращён до 10 дней для визитов из Директа и до 3 дней для остальных источников.
Директ отдельно сообщает об окне не более 10 дней после клика (откроется в новой вкладке) для загружаемых офлайн-конверсий. Это другая формулировка ограничения. Не объединяйте окно после клика и период дополнения визита в одно произвольное правило. Сверьте маршрут данных и обе актуальные справки перед настройкой.
По тому же уведомлению Директа внешние конверсии, связанные с кликами до 11 октября и загруженные после этой даты, могут не учитываться. Поэтому поздняя загрузка старого архива не является способом гарантированно восстановить всю рекламную историю. Сохранённые в CRM продажи при этом не нужно удалять или менять ради совпадения отчётов.
Если цикл сделки длиннее доступного окна, обозначьте, какие события удаётся передать вовремя, а какие останутся только во внутреннем учёте. Выбирать более ранний этап можно лишь с честным названием и понятным смыслом. Нельзя называть предварительное согласование оплатой ради количества конверсий.
Разделите приём, привязку и рекламный отчёт
Успешная передача ещё не доказывает связь каждой записи с визитом. Возможны неверный идентификатор цели, отсутствие нужного посетителя или нарушение доступного периода. Сначала проверьте причину на стороне обработки, затем сопоставьте запись с исходным событием. Массовая повторная отправка без диагноза затрудняет разбор.
Важное ограничение: Яндекс предупреждает, что статусы привязки в отчётах офлайн-конверсий могут отображаться неверно. Актуальную долю привязанных рекомендуется смотреть в настройках счётчика, в разделе загрузки данных. Не объявляйте каждую строку отчёта окончательной истиной, когда сам сервис предупреждает об ограничении.
Сверяйте количества по одинаковому событию, периоду и правилам отбора. Отдельно покажите подготовленные, отправленные и доступные для сопоставления записи. Недоступные сведения отмечайте как неизвестные. Равенство двух итогов без проверки состава может скрывать одновременно пропуски и повторы.
Модель атрибуции и ограничения статистики могут влиять на рекламный срез. Разберите их отдельно от доставки данных. Как различать несопоставимые показатели, поясняет материал о кликах Директа и визитах Метрики. Совпадение числа событий также не доказывает причинный прирост продаж от рекламы.
Примите работу по доказательствам и определите следующий шаг
После настройки у владельца должны остаться описание события, схема идентификаторов, правила повторов, журнал отправок и способ разбирать ошибки. Укажите ответственного за сбой и условия повторной проверки. Это позволит обнаружить остановившуюся передачу после изменения сайта или CRM, а не ждать первого неудачного рекламного решения.
Не выбирайте новую цель оптимизации только потому, что она появилась в списке. Сначала подтвердите смысл события, стабильность передачи и доступность данных. Исправление счётчика и событий сайта можно разобрать по чек-листу аудита Метрики. Рабочая интеграция помогает измерению, но не гарантирует продажи или снижение стоимости обращения.
На платной часовой консультации можно разобрать эту цепочку, рекламу, сайт или маркетинговую задачу. Подготовьте схему и обезличенные примеры с описанием ограничений; ключи и клиентские данные в открытый чат не нужны. Внедрение интеграции и регулярное ведение Директа согласуются отдельно.