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

Выберите результат, которого не видно на сайте

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

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

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

Согласуйте определение конверсии с продажами

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

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

Небольшой словарь событий полезно утвердить вместе с руководителем продаж. Название цели должно быть узнаваемым в отчёте. «Оплаченный заказ» понятнее технического имени интеграции; при этом технический идентификатор цели отдельно фиксируется для разработчика.

Сохраните связь визита с обращением в момент его создания

Для сопоставления нужны идентификаторы, а не только текст рекламного источника в карточке. ClientID обозначает посетителя в контексте Метрики; UserID задаётся владельцем сайта и требует предусмотренной связи с ClientID. yclid относится к клику из Директа. PurchaseId — заданный владельцем сайта идентификатор покупки электронной коммерции; по нему результат связывается с визитом, в котором была передана эта покупка. Поддерживаемые назначения перечислены в справке по импорту офлайн-данных.

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

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

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

Выберите формат передачи под задачу учёта

В Метрике есть несколько способов импорта внешних данных. Офлайн-конверсии, данные о клиентах и заказах из CRM, а также звонки имеют разные форматы и возможности. Не смешивайте их в одно обещание «всё передадим в Метрику». Выбранный путь нужно назвать в задании вместе с ожидаемыми отчётами.

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

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

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

Учитывайте период привязки до начала пилота

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

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

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

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

Защитите учёт от дублей и неоднозначных сумм

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

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

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

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

Проведите сверку от CRM до привязанной конверсии

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

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

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

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

Сравнивайте отчёты по одинаковому смыслу и периоду

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

Условный учебный пример: из 20 подтверждённых оплат четыре относятся к обращениям без нужных идентификаторов. Это ещё не объясняет остальные расхождения, но уже показывает, что ожидать 20 привязок безусловно нельзя. Дальше каждую запись сравнивают с периодом и результатом обработки. Числа условны и не являются ориентиром нормальной доли сопоставления.

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

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

Подключайте рекламные решения после проверки качества сигнала

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

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

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

Первое задание аналитикам и разработчикам должно содержать событие, источник подтверждения, идентификаторы, период и контрольные примеры. С этим набором можно обсудить передачу результатов продаж с ШТАБ ИТ. Принимать настройку стоит по прослеживаемой цепочке и объяснённым ограничениям, а не по обещанию, что реклама сразу станет выгоднее.