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

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

Какое событие передавать и каким способом

Офлайн-конверсия — действие, которое произошло вне сайта, но может быть связано с онлайн-визитом: например, оплата после разговора с менеджером. Для начала выберите один понятный результат. «Квалифицированная заявка», «выставлен счёт» и «получена оплата» — разные события; их нельзя складывать в одну цель «Продажа».

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

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

Для выбранного события создайте в нужном счётчике цель типа «Целевое событие» (в документации API — «JavaScript-событие») с условием «совпадает» и уникальным идентификатором, например crm_paid. Этот идентификатор попадёт в поле Target. Он не равен названию цели на экране и не заменяется её числовым номером. Одно и то же событие не следует дополнительно отправлять как достижение другой одноимённой цели без понятного правила учёта.

Как сохранить ClientID, UserID или yclid

Метрика должна узнать, с каким онлайн-взаимодействием связано событие из CRM. Поэтому идентификатор нужно получить на сайте и сохранить вместе с обращением, а затем перенести в сделку. Название кампании, UTM-метка и телефон клиента сами по себе не заменяют поле сопоставления в этом CSV.

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

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

Пример: одна оплата от CRM до отчёта

Ниже полностью условный пример: выдуманные сделка и ClientId, никаких данных клиента. Все времена указаны в UTC. Допустим, человек посетил сайт 5 октября, оставил заявку и оплатил 18 000 ₽ 8 октября. Цель crm_paid уже создана в том же счётчике.

1. 5 октября, 09:00: визит и заявка. Сайт получил условный ClientId 1111111111222222222. Он записан в заявку и сохранён в сделке DEMO-104 без изменения цифр.
2. 8 октября, 10:00: подтверждена оплата. В CRM зафиксированы 18 000 ₽ и время платежа. В журнале интеграции появился внутренний ключ события DEMO-104:payment-1. Этот ключ нужен для контроля повторов; он не является дополнительным полем CSV.
3. 8 октября, 10:05: сформирован файл. В нём одна строка, Target равен crm_paid, DateTime соответствует времени оплаты. Дата формирования файла не подставляется вместо даты события.
4. После отправки: проверена обработка. Сохранены идентификатор загрузки и ответ сервиса. Условные значения source_quantity = 1 и line_quantity = 1 показывают одну исходную строку и одну строку, прошедшую валидацию. Число прошедших валидацию строк не равно числу привязанных конверсий. Для API статус PROCESSED означает, что загрузка обработана. Он ещё не доказывает, что строка привязалась к визиту.
5. После обработки: проверена привязка. В отчёте «Офлайн-конверсии» найдена строка с нужным идентификатором, временем и целью. Проверен её статус, а при ошибке — указанная причина.
6. В целевом отчёте: проверен результат. Выбраны тот же счётчик и цель, согласованный период, сегмент и модель атрибуции. Проверяются достижение цели и доход 18 000 ₽, а не только наличие файла в истории загрузок.

Учебная строка CSV для этого события:

ClientId,Target,DateTime,Price,Currency
1111111111222222222,crm_paid,1791453600,18000.00,RUB

DateTime — Unix-время в секундах: 1791453600 соответствует 8 октября 2026 года, 10:00 UTC. Price — сумма, Currency — код валюты. В этом формате используются CSV в UTF-8, запятая как разделитель столбцов и точка в дробной части. Число 18000.00 означает 18 000 рублей при валюте RUB, а не 18 000 копеек. Это пример структуры для чтения, его не нужно загружать в рабочий счётчик.

При работе через API отдельную загрузку проверяют запросом GET /management/v1/counter/{counterId}/offline_conversions/uploading/{id}: нужен ID именно этой отправки. В справке Метрики для появления загруженных данных в отчётах указано до трёх часов. Мгновенного результата ждать не следует.

В обычной статистике офлайн-конверсия дополняет подходящий визит. Поэтому дата оплаты и дата, на которой вы ищете результат в отчёте, могут различаться. В примере проверьте период, включающий и 5, и 8 октября; затем посмотрите, какой визит дополнен событием. Для диагностики используйте также отчёт «Офлайн-конверсии», где видны переданное событие и результат привязки.

Как учитывать окно 21 день

Для обычных офлайн-конверсий Метрика указывает окно дополнения визитов: между последним визитом пользователя на сайт и обработкой файла должно пройти не более 21 дня. Одной недавней оплаты недостаточно: если последний визит был 1 сентября, оплата 8 октября не делает такой визит доступным для дополнения.

Метрика проверяет и время самого события: DateTime должен попадать в 21 день до момента загрузки и не быть в будущем. Подходящий визит должен находиться в этом периоде и быть не позже конверсии. Поэтому новый визит не поможет привязать старую оплату, уже вышедшую за период учёта. В условном примере визит 5 октября, оплата и обработка 8 октября удовлетворяют обоим условиям.

Передавайте события регулярно и учитывайте задержку обработки. Выгрузка в последний момент оставляет меньше времени на исправление ошибки. Не меняйте время реального события на текущее, чтобы обойти ограничение: это исказит данные и не восстановит отсутствующую связь.

Для уже привязанных заказов, переданных механизмом CRM-заказов, отдельно предусмотрен период редактирования 111 дней от визита, который дополнен заказом. Это правило обновления существующего заказа, а не универсальное окно первичной привязки CSV. При длинном цикле продажи заранее проверьте подходящий механизм и долю сделок, для которых связь с визитом действительно сохраняется.

Почему конверсия не появилась

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

События нет в выгрузке

Сверьте правило отбора со сделкой: оплата подтверждена, время попадает в интервал выгрузки, сумма заполнена. Проверьте, не потерялся ли идентификатор после преобразования лида или объединения записей.

Файл отклонён или содержит ошибки

Проверьте счётчик и доступ к нему, имена столбцов, кодировку, разделители, Target, числовую сумму и DateTime в секундах. Сравните фактическую строку с подготовленным образцом. Поле времени в миллисекундах — другое число.

Файл обработан, строка не привязана

Откройте «Отчёты → Сквозная аналитика → Офлайн-конверсии», статус и причину ошибки. Проверьте, известен ли идентификатор именно этому счётчику, есть ли подходящий визит, не превышено ли окно и не датировано ли событие раньше визита.

Привязка есть, результата в выбранном отчёте нет

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

Количество или доход оказались больше ожидаемого

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

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

Как сверить количество и доход

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

Например, в условной сверке за день есть 100 оплат. У 12 нет идентификатора, ещё у 8 подходящий визит находится вне окна. Остальные 80 событий отправлены; после обработки 76 привязались, 4 попали в разбор. Полезно видеть два показателя:

• Привязка среди отправленных: 76 / 80 = 95%. Помогает оценить результат выбранной выгрузки.
• Покрытие всей выборки оплат: 76 / 100 = 76%. Показывает, какая часть оплаченных событий вообще представлена в этой аналитике.

Это разные знаменатели. Высокая доля привязки среди отправленных не означает, что в отчёте учтены все продажи бизнеса. Аналогично сверяйте суммы: по тем же событиям, с одинаковой валютой и смыслом дохода. Оплата, выручка заказа, выплата после удержаний и прибыль не взаимозаменяемы.

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

Чек-лист приёмки интеграции

• Однозначно определены событие, источник времени, сумма, валюта, частичные оплаты и возвраты.
• Зафиксирован механизм: обычный CSV офлайн-конверсий или CRM-заказы. Цель и счётчик выбраны верно.
• Идентификатор проходит путь от сайта до выгрузки без потери и изменения. Для UserID проверена предварительная передача в Метрику.
• На согласованной выборке подтверждены отдельно обработка, привязка и результат в нужном отчёте. Тестовые события не смешаны с рабочими продажами.
• Отсутствующий идентификатор, просроченный визит, ошибочная строка и неопределённый результат отправки имеют понятный маршрут разбора.
• Назначены ответственный за исключения и проверка задержки передачи. Сохраняется журнал, позволяющий найти исходное событие.
• Сверка показывает и долю привязки отправленных событий, и покрытие всех оплат. Ограничения выборки учтены при оценке рекламы.

Начните с одной цели и нескольких уже существующих событий, доступных для проверки. Когда цепочка подтверждена, расширяйте автоматическую передачу. Хороший результат внедрения — возможность объяснить судьбу каждой выбранной записи, а не только сообщение «Файл загружен».

Автор: Милюков Михаил Андреевич.