Представим рекламный отчёт: сто заявок, приемлемая цена обращения, график идёт вверх. В CRM тем временем часть заявок не подходит, несколько ещё обсуждаются, а две уже закончились оплатой. Рекламный кабинет видит красивую форму, отдел продаж — совсем другую историю. Спор о качестве рекламы начинается не обязательно из-за плохой работы сторон. Иногда они просто смотрят на разные этапы одной воронки.
Офлайн-конверсии в Яндекс Метрике позволяют передавать подтверждённые действия вне сайта и связывать их с онлайн-историей при выполнении условий сопоставления. Для этого нужны согласованные статусы CRM, сохранённые идентификаторы, время события и проверка результата загрузки. Успешно переданный файл ещё не доказывает привязку к визиту или улучшение рекламы. Разберём всю цепочку от определения продажи до сверки отчёта.
Заявка, квалификация и оплата — разные события
Сначала решите, какое действие действительно важно. Отправка формы показывает обращение, квалификация — соответствие согласованным критериям, оплата — определённый финансовый факт. Не называйте все три «конверсией» без уточнения. Если отчёт смешивает этапы, рост числа событий можно принять за рост продаж, хотя один клиент просто последовательно прошёл несколько состояний.
Для каждого события запишите определение, источник и момент возникновения. «Качественный лид» требует критериев, которые менеджеры понимают одинаково. «Оплачено» требует выбранного факта: полной оплаты, первого платежа или другого согласованного основания. Статья не назначает бухгалтерский смысл вашим статусам. Она показывает, что техническая передача начинается после предметного определения, а не вместо него.
Метрика описывает офлайн-конверсии как способ учитывать действия, происходящие вне сайта, с использованием целей. Не нужно передавать всю историю карточки как одинаково ценные достижения. Выберите ограниченный набор событий, которые можно достоверно подтвердить и полезно анализировать отдельно.
Проверьте дисциплину CRM. Если сотрудник ставит «успешно» при отправке предложения, а другой — после получения денег, интеграция точно передаст неоднозначность. Автоматический импорт не делает исходный статус объективным. Начните с выборки карточек и сравнения с доступным основанием. Исправление смысла этапа важнее скорости передачи неправильно названного результата.
Таблица соответствий: что именно уходит из CRM
Создайте таблицу: внутреннее условие, событие Метрики, время, сумма и правило повторов. Не используйте отображаемое название статуса как единственный технический ключ: его могут переименовать. Сохраняйте устойчивые идентификаторы там, где система их предоставляет. При этом человек в протоколе должен видеть понятное название и смысл, а не разбираться только в числах из API.
| Условный этап | Основание | Время события | Что не считать тем же самым |
|---|---|---|---|
| Квалифицировано | Выполнены согласованные критерии | Момент подтверждения | Простое создание карточки |
| Договор подписан | Подтверждённое состояние документа | Выбранный момент подписания | Отправка черновика |
| Получена оплата | Согласованный финансовый факт | Момент этого факта | Выставление счёта |
| Повторная покупка | Новая самостоятельная операция | Время новой покупки | Повторная доставка прежнего события |
Пример не является готовой настройкой для любой CRM. Ваша воронка может иметь другие этапы и основания. Важно, чтобы рекламный специалист и продажи одинаково понимали каждую строку. Если событие используется для управленческого сравнения или оптимизации, изменение определения должно быть зафиксировано: новая семантика не должна незаметно продолжать старый график.
Для отмен и исправлений заранее изучите возможности выбранного механизма импорта. Не предполагайте, что повторный файл автоматически отредактирует любую ранее переданную запись. Логика загрузки офлайн-конверсий и другие способы передачи CRM-данных могут различаться. Зафиксируйте, какой именно путь используете, и проверьте его поведение на контролируемом наборе до массовой передачи.
Без связующего идентификатора два отчёта не узнают друг друга
Нужно сохранить поддерживаемый идентификатор в момент, когда он доступен, и довести его до нужного объекта CRM. Потеря часто происходит между сайтом, формой, серверным обработчиком и карточкой. Поле может существовать в интерфейсе, но не заполняться. Или заполняться, а затем перезаписываться пустым значением при обновлении. Проверяйте фактический путь, а не только наличие названия поля.
В текущем описании CSV для офлайн-конверсий указаны поддерживаемые идентификаторы, Target и DateTime; требуется хотя бы один из предусмотренных идентификаторов. Выбор ClientID, UserID, yclid или PurchaseId зависит от доступного сценария и правил Метрики. Нельзя произвольно подставить внутренний номер сделки и ожидать, что система сама поймёт его связь с визитом.
Если используете UserID, должна существовать корректная связь с онлайн-историей в соответствии с документацией. Если используете рекламный идентификатор, убедитесь, что он действительно получен и сохранён, а не восстановлен по догадке из источника обращения. Название кампании и идентификатор конкретного перехода решают разные задачи. Одного текста «Яндекс» в CRM недостаточно для точного сопоставления.
Проверьте несколько способов обращения: обычная форма, повторное посещение, звонок, заявка из другого устройства, ручное создание карточки. Возможности связки будут различаться. Не обещайте полное покрытие всех продаж одним механизмом. Для каждого пути полезно знать долю технически доступных идентификаторов и причины отсутствия, не подменяя их случайным значением ради заполненного столбца.
Время события и срок передачи нельзя менять ради отчёта
Передавайте время реального согласованного события, а не время формирования файла. Иначе недельная выгрузка перенесёт продажи разных дней на один момент и исказит анализ. В описании формата Метрики DateTime задаётся в Unix-времени в секундах; при подготовке нужно учитывать указанный в документации часовой пояс счётчика. Ошибка единиц или преобразования времени может сдвинуть событие далеко от его фактического дня.
У импорта есть ограничение по периоду дополнения визитов. На дату проверки, 17 октября 2026 года, документация Метрики описывает соответствующие условия; в разборе ошибок передачи указано превышение 21 дня от последнего визита посетителя до начала обработки файла. Это не универсальные «21 день после продажи». Перед настройкой сверяйте актуальное правило выбранного способа передачи.
Для длинного B2B-цикла это существенная граница. Не меняйте дату продажи на более раннюю, чтобы она поместилась в окно. Лучше оценить подходящий механизм, доступные промежуточные события и ограничение покрытия. Квалификация или подписанный этап могут быть самостоятельным сигналом, если определены честно. Они не становятся оплатой только потому, что доступны раньше.
Настройте регулярность выгрузки с учётом рабочих задержек, а не только технического расписания. Если менеджеры закрывают неделю в пятницу, ежедневный скрипт не сделает статусы свежими автоматически. Нужен владелец качества исходных событий и видимость задержки. Отдельно наблюдайте время от бизнес-факта до записи в CRM и от записи до успешной обработки в Метрике.
Сумма: что именно вы называете доходом
Согласуйте, передаётся ли сумма заказа, поступивший платёж или другая величина. Не смешивайте их под одним полем. Частичная оплата и полная стоимость могут быть полезны в разных анализах, но при одинаковом названии создают неверные сравнения. Указывайте валюту и правило для возвратов или корректировок в пределах поддерживаемого механизма и вашего учёта.
Не отправляйте потенциальный бюджет клиента как подтверждённую выручку. Это может сделать ранние этапы воронки очень привлекательными на панели, но не поможет оценить реальные продажи. Если оценочная ценность нужна для отдельной задачи, обозначьте её именно как оценку и не смешивайте с фактическими денежными событиями. Смысл поля важнее того, насколько удобно по нему построить график.
Сверяйте несколько контрольных сумм с CRM по одной и той же выборке. Условные десять событий по тысяче дают десять тысяч только если это действительно десять самостоятельных фактов без дублей и разных валют. Совпадение общей суммы не исключает взаимно компенсирующихся ошибок. Проверяйте строки и идентификаторы на небольшой выборке, затем переходите к агрегатам.
Загрузка файла и привязка конверсии — разные результаты
После передачи проверьте обработку, а затем сопоставление. Файл может иметь правильную структуру, но часть записей не свяжется с визитами. Причины нужно разбирать отдельно: идентификатор, цель, время, отсутствие нужной истории. Не объявляйте интеграцию готовой только по ответу API о принятой загрузке. Он подтверждает этап обмена, а не весь аналитический результат.
Отчёт Метрики «Офлайн-конверсии» показывает загруженные события и состояние привязки. Используйте его для проверки конкретных строк и причин. Даже привязанное событие ещё нужно правильно интерпретировать в выбранном отчёте и модели атрибуции. Не сравнивайте разные представления, не согласовав период и смысл метрики.
Разделяйте четыре числа: событий в CRM, подготовленных к передаче, обработанных и привязанных. Между ними могут быть нормальные и проблемные различия. Например, не у каждой продажи есть поддерживаемый онлайн-идентификатор. Это ограничение покрытия, которое нужно показать. А исчезновение записей между подготовкой и загрузкой уже указывает на технический сбой или правило отбора, которое следует объяснить.
Не придумывайте универсальный норматив процента привязки. Он зависит от каналов, устройств, цикла сделки и реализации сбора. Сначала установите собственную проверенную базу и причины неполного покрытия. Затем наблюдайте резкие изменения при сопоставимых условиях. Падение после релиза формы требует расследования, даже если абсолютный процент выглядит кому-то привычным.
Учебная сверка: почему два процента могут быть правильными
Возьмём условную выборку из двадцати подтверждённых событий CRM. У шестнадцати есть подходящий идентификатор, у четырёх его нет. Все шестнадцать записей обработаны, двенадцать привязаны к визитам. Тогда доля привязки среди переданных — 12 из 16, то есть 75%. Покрытие всех двадцати событий CRM — 12 из 20, то есть 60%. Это учебные числа, не результат кампании или интеграции 404ai.
Оба процента полезны, если названы знаменатели. Первый помогает оценивать переданную часть, второй показывает охват исходного бизнес-набора. Если написать просто «привязка 75%», руководитель может принять его за долю всех продаж. А четыре события без идентификатора вообще исчезнут из разговора, хотя именно они могут указывать на проблему формы, звонков или ручного ввода.
Теперь разберите четыре переданные, но непривязанные записи. У них могут быть разные причины, и исправление одной не поможет остальным. Не складывайте отсутствие цели, пропущенное окно и неизвестный идентификатор в общий статус «Метрика не работает». Сопоставьте конкретное сообщение отчёта с исходной карточкой и этапом передачи. Так задача получает владельца и проверяемый результат исправления.
После изменения повторите сверку на сопоставимой выборке и сохраните определение показателей. Рост с 60% до 70% общего покрытия нельзя честно сравнивать с прежними 75% среди переданных. Это та же ловушка знаменателя, только в рекламном отчёте. Понятные названия и явные количества часто предотвращают спор лучше, чем дополнительный график с процентами.
Повторы и возврат статуса в CRM
Одна карточка может несколько раз проходить этап, а интеграция — повторять выгрузку после таймаута. Заранее определите, какое событие должно передаваться один раз, а что является новым бизнес-фактом. Идентификатор сделки не всегда достаточен: у неё может быть несколько оплат или повторная покупка. Но каждая попытка доставки не должна превращаться в новую продажу.
Храните журнал подготовленных событий с устойчивым ключом, временем, состоянием передачи и основанием. При неопределённом исходе используйте документированное поведение импорта и сверку, а не слепую массовую переотправку. Подробнее транспортные повторы разобраны в материале о защите от повторных вебхуков CRM. Здесь добавляется аналитический смысл: дубль искажает не только работу менеджера, но и оценку канала.
Изменение стадии назад не всегда отменяет прошлый факт. Клиент мог оплатить, затем запросить возврат; договор мог быть подписан и позже расторгнут. Нужна модель событий, соответствующая реальному процессу и выбранному механизму передачи. Не стирайте историю только ради красивой текущей воронки. Правила корректировок согласуйте и проверьте отдельно, прежде чем использовать данные для решений.
Когда подключать сигнал к оценке рекламы
Сначала подтвердите определения, сбор и сопоставление на ограниченном наборе. Затем наблюдайте стабильность и только после этого принимайте решения о применении сигнала в рекламной стратегии. Документация Метрики описывает возможность использования офлайн-действий для продвижения, но конкретная настройка зависит от кампании и доступных данных. Наличие новой цели само по себе не обещает роста продаж или снижения стоимости привлечения.
Редкий поздний результат и частый ранний сигнал имеют разную ценность и ограничения. Оплата ближе к экономике бизнеса, квалификация может быть доступна раньше. Выбор нельзя свести к лозунгу «оптимизируемся только на деньги». Нужно учитывать качество определения, объём и задержку, а также действующие возможности платформы. Не меняйте одновременно множество факторов, если затем хотите понять причину результата.
Сохраняйте отдельные отчёты по ранним и поздним этапам. Условная кампания А дала больше заявок, кампания Б — меньше обращений, но больше подтверждённых продаж. Это повод разбирать качество и экономику, а не автоматически объявлять победителя по одной доле без затрат и достаточного наблюдения. Неполное покрытие идентификаторов тоже может различаться между каналами.
Для ведения рекламы полезно принести карту статусов, доступные идентификаторы и примеры расхождений. Конкретный способ интеграции и использования данных проверяется под проект. Эта статья не утверждает, что любая CRM уже подключена к рекламному кабинету. Рабочий результат подтверждается на реальном пути от карточки до нужного отчёта.
Приёмочный набор для передачи офлайн-конверсий
| Проверка | Что фиксируем | Что нельзя подменять |
|---|---|---|
| Значение статуса | Подтверждённое определение события | Любой этап словом «продажа» |
| Идентификатор | Его происхождение и путь до CRM | Номер карточки случайным онлайн-ID |
| Время | Реальный момент и корректное преобразование | Дату события датой выгрузки |
| Повтор | Стабильный ключ и проверенный исход | Попытку доставки новой конверсией |
| Обработка | Принято, обработано, привязано | Успех загрузки успехом всей цепочки |
| Сверка | Одинаковый период и состав выборки | Неполный отчёт итогом всей CRM |
Проведите тесты на контролируемых объектах и доступных идентификаторах, не создавая вымышленные рабочие продажи ради проверки. Убедитесь, что тестовые события не искажают используемые бизнес-цели. Для изоляции полезен тестовый стенд интеграции, но финальная проверка соответствующего рабочего контура всё равно должна быть ограниченной и осмысленной.
После запуска назначьте владельцев источника и передачи, наблюдайте задержки и причины непривязанных строк. Отчёт должен объяснять, какая часть продаж действительно связана с онлайн-историей, а какая остаётся вне этого механизма. Тогда разговор рекламы и продаж становится предметнее: стороны обсуждают одни и те же подтверждённые события и видимые ограничения, а не защищают разные версии красивого графика.