Офлайн-конверсии в Метрике: как подготовить передачу из CRM

Передачу офлайн-конверсий из CRM в Метрику начинают с определения бизнес-события и сохранения идентификаторов посетителя. Затем проверяют формат времени, допустимую задержку загрузки и фактическую привязку к визиту. Успешно принятый файл ещё не означает, что каждая продажа сопоставлена с рекламным переходом.

Выберите событие для передачи

Разделите квалификацию обращения, подтверждение заказа и оплату. Это разные результаты, которые полезно анализировать отдельно. Не называйте любую смену этапа продажей: менеджер может переместить карточку заранее, вернуть её назад или исправить ошибку.

Для оплаты определите источник подтверждения, идентификатор операции и правило частичных платежей. Если бизнес хочет передавать только полностью оплаченный заказ, событие создаётся после выполнения этого условия. Это методика проекта; её нельзя автоматически приписывать готовому коннектору без проверки.

Подготовьте данные сопоставления

В официальном формате загрузки предусмотрены идентификаторы ClientID, UserID, yclid или PurchaseId; требуется хотя бы один. Поле Target связывает событие с целью, а DateTime передаёт время конверсии в секундах Unix. Конкретную схему сверяют с документацией передачи данных.

Сохраняйте идентификатор вместе с обращением и историей его происхождения. Не заменяйте отсутствующее значение номером сделки: технически похожая строка не становится идентификатором посетителя. Отсутствие данных лучше показать отдельной категорией, чем создать видимость полной атрибуции.

Рассчитайте запас по времени

Официальный отчёт описывает период учёта в 21 день до момента загрузки и причины непривязанных событий. Для сопоставления нужны подходящие идентификаторы и визит в допустимом интервале; одной своевременной оплаты недостаточно. Проверяйте условия по справке офлайн-конверсий.

Практически это означает регулярную передачу и контроль стареющей очереди. При длинном цикле продажи часть оплат может не получить нужную связь с визитом. Такие продажи остаются фактом CRM, даже если возможности конкретного способа загрузки не позволяют отнести их к посещению сайта.

Условный пример с частичной оплатой

Предположим, клиент отправил заявку, затем внёс аванс и позднее оплатил остаток. Компания решила считать отдельными событиями подтверждённый заказ и полную оплату. В карточке сохраняются идентификатор посетителя, номер заказа и даты соответствующих операций.

Повторная выгрузка не должна создавать новые бизнес-события из прежнего аванса. Внутренний журнал отмечает, какие операции подготовлены, отправлены и проверены. Если окончательная оплата не привязалась, аналитик исследует временной интервал и идентификатор, а не меняет дату оплаты ради попадания в отчёт.

Проверяйте загрузку в двух местах

На момент проверки документации 20 октября 2026 года Яндекс предупреждает: статусы привязки в отчётах могут отображаться неверно, актуальную долю следует смотреть на странице «Загрузка данных». Поэтому при настройке учитывают действующее предупреждение и сверяют состояние загрузки с отчётом, а не полагаются на один индикатор.

Сохраните номер загрузки, количество переданных событий и суммы в собственном журнале. Причины непривязки группируйте: отсутствующая цель, неверный идентификатор, неподходящее время и другие фактические ответы сервиса. Общую природу расхождений раскрывает материал о данных Метрики и CRM.

Приёмка перед регулярной передачей

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

Запуск оправдан, когда известны доля подготовленных событий, доля принятых и доля сопоставленных, а причины потерь доступны для разбора. Эти показатели отвечают на разные вопросы; объединять их в единый процент «работы интеграции» не следует.