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

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

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

Что такое офлайн-конверсии и зачем передавать продажи из CRM

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

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

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

После настройки в отчётах можно анализировать несколько уровней результата:

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

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

Какие данные нужны для связи заявки с рекламой

Главная задача интеграции, сохранить идентификатор посетителя в момент обращения и не потерять его по дороге до CRM. В зависимости от сценария используются идентификаторы Яндекс Метрики, параметры визита и данные самой заявки.

Идентификатор визита

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

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

Параметры рекламного визита

UTM-метки помогают анализировать источник, кампанию, группу и объявление. Они не заменяют ClientID, но дают дополнительный уровень контроля. Для Директа обычно сохраняют источник, кампанию, ключевую фразу или идентификатор объявления, если эти данные доступны в конкретной схеме разметки.

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

Данные о сделке

В CRM должны быть понятные поля, по которым можно определить результат:

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

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

Какие офлайн-события передавать в Директ

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

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

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

Как работает передача офлайн-конверсий из CRM

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

1. Пользователь кликает по объявлению и открывает сайт.
2. Метрика фиксирует визит и присваивает ему идентификатор.
3. Форма, звонок или виджет передаёт идентификатор в CRM.
4. Менеджер обрабатывает обращение и меняет статус сделки.
5. Интеграция забирает нужное событие из CRM.
6. Событие отправляется в Метрику или напрямую в рекламную систему по поддерживаемому сценарию.
7. После обработки данные появляются в отчётах, а при достаточном объёме могут использоваться для автоматической оптимизации.

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

Три распространённых способа интеграции

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

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

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

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

Пошаговая настройка офлайн-конверсий

Шаг 1. Описать воронку продаж

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

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

Шаг 2. Проверить Метрику и цели

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

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

Шаг 3. Передать идентификатор в CRM

Создайте в CRM отдельное техническое поле для ClientID. Не смешивайте его с телефоном, UTM-меткой или комментарием менеджера. Если лид превращается в сделку, значение должно переноситься в новую карточку автоматически.

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

Шаг 4. Настроить отправку статусов и дохода

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

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

Шаг 5. Протестировать цепочку

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

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

Как оценивать рекламу после подключения CRM

После передачи продаж привычный отчёт по цене заявки становится только одним из уровней анализа. Основные показатели нужно считать по единой формуле и за одинаковый период.

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

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

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

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

Как использовать офлайн-данные для оптимизации кампаний

После накопления статистики можно сравнивать кампании, группы и объявления не по кликам, а по качественным этапам. Например, одна кампания даёт лиды по 500 рублей, но почти не приводит к встречам. Другая приносит обращения по 900 рублей, зато чаще заканчивается договором. По цене заявки первая выглядит лучше, по бизнес-результату может проигрывать.

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

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

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

Типичные ошибки при передаче продаж из CRM

В CRM не сохраняется ClientID

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

За конверсию принимают любой статус

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

Сделки передаются повторно

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

Передаётся договор, но не факт оплаты

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

Не учитываются звонки и обращения из внешних сервисов

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

Решения принимаются по слишком короткому периоду

Продажа может появиться через 14 или 30 дней после клика. Если отключить кампанию через два дня из-за отсутствия оплат, вы оцените только верхнюю часть воронки. Анализируйте когорты, то есть группы обращений по дате привлечения, и дайте им время пройти цикл сделки.

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

Контроль качества и регулярная сверка данных

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

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

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

Частые вопросы

Можно ли передавать в Директ только оплаченные заказы?

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

Что делать, если CRM не поддерживает прямую интеграцию?

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

Нужен ли ClientID, если у нас есть UTM-метки?

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

Как передавать доход по сделке с частичной оплатой?

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

Через сколько будут видны офлайн-конверсии?

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

Можно ли настроить всё без доработки сайта?

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

Что делать: короткий план

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

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