Офлайн-конверсии в Яндекс.Метрике: как связать заявки с оплатами из CRM

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

Разберём основной маршрут: CRM формирует события подтверждённой оплаты, а команда загружает их как офлайн-цели через CSV. Отдельно обозначим интеграцию клиентов и заказов CRM: у неё другая модель данных, статусы и возможности обновления. Эти два механизма нельзя объединять в один произвольный файл.

Какой способ передачи подходит вашей задаче

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

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

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

Сначала согласуйте, что считается оплатой

Название этапа воронки не всегда подтверждает поступление денег. Менеджер может перевести сделку в «Успешно» после обещания клиента, а бухгалтерия увидит платёж позже. Для аналитики нужен воспроизводимый критерий: какое поле или подтверждение делает событие допустимым и какую дату следует передать.

Ниже — условная карта для компании, которая считает оплатой полное закрытие суммы заказа. Это политика примера, а не обязательная схема Яндекса.

Состояние в CRM	Действие экспортера	Что проверяется
Новая заявка	Не создавать событие оплаты	Обращение зарегистрировано, денег ещё нет
Получен аванс	Ожидать полной оплаты	Остаток задолженности больше нуля
Полностью оплачено	Создать одно событие crm_paid_confirmed	Сумма и время подтверждены учётной системой
Отмена или возврат	Передать в отдельную процедуру сверки	Определить влияние на управленческий отчёт

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

Как сохранить ClientID вместе с заявкой

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

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

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

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

Когда применимы UserID, yclid и PurchaseId

ClientID — не единственный вариант, но идентификаторы нельзя заменять друг другом по сходству названий. Собственный номер клиента становится UserID для Метрики только после согласованной передачи. В документации setUserID прямо указано: связь с ClientID возникает для посетителей, во время посещений которых вызван этот метод. Само наличие номера клиента в CRM такую связь не создаёт.

В формате офлайн-целей также предусмотрены Yclid — идентификатор рекламного клика Директа, и PurchaseId — идентификатор покупки электронной коммерции. Последний подходит, когда соответствующая покупка уже зарегистрирована: произвольный номер нового заказа из CRM не превращается автоматически в PurchaseId известной Метрике покупки.

Выберите основной идентификатор и проверьте его на нескольких сквозных примерах. Если используете дополнительные, убедитесь, что они относятся к одному реальному событию. Больше заполненных колонок не означает более правильную атрибуцию. Телефон и email не являются заменой ClientId в выбранном CSV офлайн-целей: работа с такими идентификаторами относится к отдельному формату клиентов и заказов.

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

Подготовьте цель и единый идентификатор события

В выбранном счётчике создайте цель типа «Целевое событие» с понятным названием, например «CRM: подтверждённая полная оплата», и идентификатором crm_paid_confirmed. В инструкции по передаче офлайн-конверсий описаны создание такой цели и загрузка файла через раздел настроек «Загрузка данных». Текстовое название для сотрудников и идентификатор события выполняют разные задачи.

Экспортер должен использовать согласованное значение Target без случайных пробелов и переименований. В документации API этот тип также назван JavaScript-событием; условие идентификатора требуется настроить на точное совпадение. Проверяйте именно нужный счётчик: одинаковое имя цели на другом проекте не подтверждает корректность настройки.

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

Как выглядит файл офлайн-конверсий

Спецификация API офлайн-конверсий требует Target, DateTime и хотя бы один поддерживаемый идентификатор. В примере выбран ClientId. Price и Currency необязательны; сумма записывается с десятичной точкой, валюта — трёхбуквенным кодом ISO 4217. DateTime передаётся в Unix-секундах, а не миллисекундах; время события не должно находиться в будущем.

ClientId,Target,DateTime,Price,Currency
1700000000123456789,crm_paid_confirmed,1793437200,12500.50,RUB

Это учебная строка с вымышленным ClientId. Значение 1793437200 соответствует 31 октября 2026 года, 09:00 UTC. Для примера часовой пояс счётчика также принят UTC; стоимость события составляет 12 500 рублей 50 копеек. Номер заказа ведётся в отдельном реестре экспортера и не добавляется самовольно в CSV под неописанным заголовком.

При другой временной зоне сначала установите настоящий момент события по данным CRM, затем переводите его в Unix-секунды. Например, 12:00 при смещении +03:00 и 09:00 UTC обозначают один момент. Нельзя сначала прибавить смещение вручную, а затем повторно применить его библиотекой.

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

Почему важны время визита и срок обработки

По правилам импорта офлайн-данных базовый период дополнения визитов составляет 21 день. Для ClientID и UserID конверсия относится к предшествовавшему ей визиту; Yclid и PurchaseId используют соответствующие рекламный клик и покупку. Проверяйте подходящий визит, время конверсии и момент обработки, а не только возраст оплаты в CRM.

Условный клиент посетил сайт 20 октября в 09:00 UTC и оплатил 31 октября в 09:00 UTC. Других визитов не было. Если файл обработан 1 ноября в 09:00 UTC, от визита прошло 12 дней: временная последовательность укладывается в окно. Это ещё не гарантирует привязку — идентификатор и цель тоже должны быть корректными.

При обработке 12 ноября в 09:00 UTC визиту уже 23 дня. Оплате только 12 дней, но подходящий визит оказался за пределами периода. Перенос даты оплаты на сегодняшний день проблему не исправляет и искажает данные.

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

Разделите подготовку, приём файла и обработку

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

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

При тайм-ауте сначала выясните, приняла ли система загрузку. Не создавайте новый факт оплаты с другой датой только ради повторной отправки. Собственный реестр защищает от повторного выбора одного события; поведение повторной загрузки проверяйте по действующему контракту и на контрольном наборе.

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

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

Как разбирать привязанные и непривязанные записи

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

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

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

Учебная сверка с отделом продаж

Предположим, CRM содержит 100 подтверждённых оплаченных заказов по 10 000 рублей каждый. Для простоты примера у каждого заказа одна оплата, одна валюта, возвратов нет. Всего это 1 000 000 рублей. После проверки получился следующий реестр:

Группа заказов	Количество	Сумма
Нет подходящего идентификатора	10	100 000 рублей
Известный визит вне периода	5	50 000 рублей
Выгружены и успешно привязаны	80	800 000 рублей
Выгружены, привязка не подтверждена	5	50 000 рублей

Выгружено 85 событий, подтверждённая доля привязки среди них равна 80 / 85, приблизительно 94,1%. Покрытие всех оплаченных заказов составляет 80 / 100, то есть 80%. Это разные показатели. Высокая доля успешной обработки файла не означает полного охвата продаж.

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

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

Когда переходить к отдельному импорту заказов CRM

При длинном цикле сделки полезна модель «заказ появился — состояние изменилось». В специальной CRM-интеграции первоначальная привязка также ограничена 21 днём. Уже привязанный заказ допускает обновления в пределах 111 дней от начала визита, к которому его добавили. Это не дополнительные 111 дней после загрузки и не разрешение впервые привязать любой старый заказ.

Здесь передают клиентов и заказы по собственному формату, включая статусы; стандартный PAID соответствует оплаченному заказу. Механизм может использовать ClientId, email и телефон. Эти поля и правила не следует переносить в обычный CSV офлайн-целей.

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

Что проверить перед регулярной передачей

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

1. Выберите контрольные случаи: полная оплата, аванс, повторное сохранение карточки, отсутствие идентификатора и слишком старый визит.
2. Сравните исходные поля CRM с выгрузкой: событие, время, сумма, валюта, цель и идентификатор.
3. Проверьте обработку партии, доступные сведения о привязке и объяснение исключённых записей.
4. Убедитесь, что повторный запуск экспортера не создаёт новое событие для уже выбранной оплаты.
5. Назначьте ответственных за бизнес-статусы, техническую доставку и регулярную сверку итогов.

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

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

Для внешнего контроля HTTP-доступности сайта подключите SiteGuard, а передачу оплат и сверку с CRM включите в отдельный регламент аналитики.