Офлайн-конверсии и CRM: как вернуть данные о продажах в рекламу

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

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

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

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

Зафиксируйте договор коммерческого события

Название цели само по себе ничего не гарантирует. «Квалифицирован», «в работе» и «успешно» звучат убедительно, но разные сотрудники могут вкладывать в них разный смысл. До настройки обмена каждое передаваемое событие нужно описать как небольшой договор между маркетингом, продажами и аналитикой.

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

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

Сохраните идентификаторы в момент первого обращения

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

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

Для Яндекса используются разные варианты связи. В справке Метрики об импорте офлайн-данных перечислены ClientId, UserId, yclid и PurchaseId; ClientId Яндекс называет рекомендуемым параметром для наиболее точной привязки к визитам. Для данных о клиентах и заказах из CRM также поддерживаются идентификаторы клиента и заказа, статус, время, доход и себестоимость.

Для Google Ads классическая связь строилась вокруг GCLID, а расширенное отслеживание конверсий лидов дополняет ее хешированными данными, предоставленными пользователем. В актуальной справке Google по расширенному отслеживанию лидов новым интеграциям рекомендуют использовать улучшенный вариант и Менеджер данных. Там же зафиксированы изменения 2026 года в способах загрузки, поэтому старую инструкцию по API нельзя считать вечным контрактом.

Минимальный набор, который я хотел бы видеть у обращения:

1. исходный URL и UTM-параметры без последующего переписывания;
2. доступные идентификаторы рекламного клика и веб-посетителя;
3. внутренний ID лида или обращения;
4. ID клиента и сделки, если они создаются отдельно;
5. время первого обращения;
6. источник, через который лид действительно поступил: форма, звонок, чат или импорт;
7. история смены коммерческих статусов, а не только текущее значение.

UTM-метки помогают прочитать источник, кампанию и объявление, но не заменяют идентификатор для платформенной привязки. Базовая связь источника, целей и CRM разобрана в материале о сквозной аналитике и UTM.

Соберите один маршрут данных

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

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

Не смешивайте четыре даты

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

• дата визита нужна для связи с рекламой;
• дата лида показывает скорость поступления обращения;
• дата квалификации или оплаты относится к реальному бизнес-этапу;
• дата выгрузки показывает задержку интеграции.

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

Для офлайн-данных Метрики текущий период дополнения визитов составляет 21 день. Для заказов из CRM Яндекс позволяет после первичной привязки обновлять сведения дольше: до 111 дней от визита. Практический вывод для длинной сделки такой: подходящий заказ нужно передать вовремя со стабильным ID, а его статус и доход обновлять по мере развития, а не создавать новую запись на каждом этапе.

В Центре конверсий Яндекс Директа также указано, что источник следует обновлять не реже одного раза в сутки, а для корректного изменения статусов использовать ID заказа из CRM. Эти сроки относятся к текущим правилам платформы и должны повторно проверяться при реализации.

Один коммерческий исход должен иметь один устойчивый ID

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

Правило дедупликации лучше строить не вокруг телефона, а вокруг бизнес-сущности:

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

Для Google Ads order_id используется как идентификатор транзакции и помогает предотвращать повторный учет; ошибки дублирования отдельно описаны в официальной диагностике загрузки конверсий. Конкретный механизм корректировки зависит от текущего способа импорта, поэтому бизнес-правило ID должно существовать независимо от выбранного коннектора.

Не превращайте каждый CRM-статус в цель

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

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

Отдельно исключаются:

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

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

Проверяйте не факт выгрузки, а полноту связи

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

Для контроля нужны три доли:

1. Доля отправки. переданные события / все события CRM, которые подходят под договор.
2. Доля привязки. связанные с рекламой события / переданные события.
3. Сквозное покрытие. связанные события / все подходящие события CRM.

Полезная приемка включает несколько конкретных записей каждого типа:

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

Запускайте оптимизацию после контрольного периода

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

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

Последовательность запуска:

1. выбрать одно глубокое событие и описать его договор;
2. сохранить идентификаторы у новых обращений;
3. передавать событие только в отчетном режиме;
4. сверить подходящие, отправленные, принятые и привязанные записи;
5. проверить зрелую когорту и причины непривязки;
6. решить, хватает ли событию регулярности и скорости для оптимизации;
7. сделать его управляющим сигналом для ограниченного контура;
8. только после стабильной приемки добавлять ценность или следующий этап.

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

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

Назначьте владельца каждому разрыву

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

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

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

Проверьте готовность контура

Перед использованием CRM-данных в рекламе я проверил бы девять условий:

1. Для каждого события есть однозначное условие достижения и список исключений.
2. Менеджеры одинаково применяют передаваемые статусы.
3. Рекламные и веб-идентификаторы сохраняются при первом обращении.
4. Лид, клиент, сделка и платеж имеют стабильные ID.
5. Даты визита, лида, результата и выгрузки не смешиваются.
6. Повторная отправка не создает новую конверсию.
7. CRM, выгрузка и рекламная система сверяются по конкретным записям и итоговым долям.
8. Отмены, возвраты и смена статуса проходят проверенный сценарий обновления.
9. Управляющая цель включается только после отчетной приемки на завершенной когорте.

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

Верните продажу в общую маркетинговую систему

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

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