В Яндекс Директе довольно легко попасть в ловушку красивой статистики. Кампания даёт заявки по приемлемой цене, стратегия формально выполняет цель, графики выглядят бодро — а в CRM при этом продажи не радуют.
Обычно в такой ситуации начинают менять объявления, ставки, аудитории, посадочные страницы. Иногда это действительно нужно. Но есть более фундаментальная проблема: алгоритм может оптимизироваться не под тот бизнес-результат, который вам на самом деле нужен.
Если стратегия обучается на событии «форма отправлена», она будет искать людей, склонных отправлять формы. Это не обязательно те же люди, которые потом отвечают на звонок, проходят квалификацию, получают счёт и оплачивают заказ.
Директ не знает, какая заявка хорошая
Для рекламной системы конверсия — это сигнал. Она не понимает бизнес так, как понимает его собственник или менеджер по продажам. Если на сайте настроена цель «Спасибо за заявку», то именно это событие становится для алгоритма ориентиром.
В простых нишах этого может быть достаточно. Например, когда пользователь оставляет заказ и почти сразу оплачивает. Но чем длиннее путь от первого обращения до денег, тем выше риск разрыва между рекламной конверсией и реальным результатом бизнеса.
Типичная цепочка выглядит так: пользователь оставил заявку → менеджер связался → выяснилось, что запрос нецелевой → либо клиент исчез → либо заказ оказался слишком маленьким → либо сделка закрылась через неделю. Для Метрики все эти случаи изначально могут выглядеть одинаково: цель выполнена.
Поэтому цена заявки сама по себе — слабый ориентир, если качество лидов сильно различается.
Что дают офлайн-конверсии
Яндекс позволяет передавать обратно данные о событиях, которые произошли уже после визита на сайт: оплату, квалифицированный лид, покупку по телефону, продажу в офлайн-точке и другие статусы из CRM.
В документации Яндекса такие события называются офлайн-конверсиями. Смысл простой: дополнить картину тем, что не было видно на сайте, но известно бизнесу.
Это важно сразу по двум причинам. Во-первых, аналитика становится честнее: можно смотреть не только на количество обращений, но и на то, какие кампании реально приводят к продажам. Во-вторых, эти данные можно использовать для оптимизации стратегий.
И вот второй пункт обычно намного важнее первого.
Почему стратегия может ухудшать качество лидов
Представим две группы пользователей. Первая часто заполняет формы, но редко покупает. Вторая заполняет формы реже, зато заметно чаще доходит до оплаты.
Если стратегия получает только цель «заявка», первая группа для неё может выглядеть выгоднее. Конверсий больше, стоимость ниже, формально всё отлично.
Если же в систему возвращается статус «оплачен», картина меняется. Теперь алгоритм получает сигнал не только о факте обращения, но и о ценности этого обращения для бизнеса.
Отсюда простой вывод: когда рекламная кампания обучается только на верхнем этапе воронки, нельзя удивляться, что она оптимизирует именно верхний этап.
Какие данные можно передавать
В Центр конверсий и Метрику можно передавать события из CRM разными способами. Яндекс поддерживает загрузку через файл, источники по HTTP/HTTPS, FTP/SFTP, Google Sheets, готовые коннекторы и API.
Для малого проекта вполне может хватить регулярной выгрузки. Для более сложной системы логичнее автоматическая интеграция.
Важно другое: у конверсии должен быть идентификатор, по которому Яндекс сможет связать её с предыдущим визитом пользователя.
- ClientID Метрики;
- телефон;
- email;
- в некоторых сценариях другие идентификаторы, которые предусмотрены интеграцией.
Яндекс отдельно указывает, что качество сопоставления зависит от состава данных. Максимальное качество атрибуции получается, когда вместе передаются ClientID и контактные данные. Только ClientID — тоже хороший вариант. Если есть только телефон или email, качество ниже.
Практический смысл очень простой: если можно сохранять ClientID в CRM вместе с заявкой — лучше это делать.
Не все CRM-статусы одинаково полезны
Ещё одна частая ошибка — передавать в рекламу вообще все статусы подряд и считать, что чем больше данных, тем лучше.
Это не всегда так. У каждого статуса должна быть понятная бизнес-логика.
Например, можно разделить:
- заявка создана;
- лид квалифицирован;
- сделка подтверждена;
- заказ оплачен.
Для аналитики полезно видеть всю воронку. Для оптимизации стратегия должна получать сигнал, который достаточно близок к деньгам и при этом возникает достаточно часто.
Если оплаченных заказов единицы, а квалифицированных лидов десятки, иногда разумнее обучаться на квалифицированном лиде. Если оплат достаточно много — можно двигаться ближе к конечной продаже.
То есть универсальной цели «всегда оптимизируйся по оплате» нет. Нужен баланс между качеством сигнала и его объёмом.
Почему нельзя забывать про окно атрибуции
У офлайн-конверсий есть ограничение по времени. В текущей документации Яндекса окно, в течение которого офлайн-конверсию можно связать с визитом, составляет 21 день.
Это критично для бизнесов с длинным циклом сделки.
Если пользователь пришёл из рекламы, а договор подписал через месяц, такая продажа уже может не связаться с исходным визитом стандартным способом. Поэтому до настройки интеграции стоит посмотреть реальный цикл сделки, а не только техническую инструкцию.
После атрибуции данные о конверсии можно корректировать — например, обновлять доход или статус. Это полезно, когда заказ сначала создаётся, а потом становится оплаченным.
Доход важнее количества конверсий
Если у заказов сильно отличается ценность, просто считать количество продаж тоже бывает недостаточно.
Два объявления могут дать по десять оплаченных заказов, но в одном случае средний чек будет в несколько раз выше. Если передавать доход, рекламная система получает более содержательный сигнал.
Особенно это важно для интернет-магазинов и услуг с большим разбросом стоимости заказа. В таких проектах логика «одна конверсия = одна конверсия» слишком грубая.
Это напрямую связано с тем, куда сейчас развивается Директ: стратегии всё чаще работают не только с количеством действий, но и с их ценностью для бизнеса.
Что проверить, если заявок много, а продаж мало
Я бы не начинал с радикальной перестройки кампании. Сначала стоит пройтись по цепочке данных.
- Какая цель сейчас используется в стратегии?
- Что именно считается конверсией?
- Есть ли в CRM информация о качестве лида и оплате?
- Сохраняется ли ClientID вместе с заявкой?
- Можно ли вернуть в Метрику статусы из CRM?
- Какой процент заявок доходит до квалификации и оплаты?
- Укладывается ли цикл сделки в окно атрибуции?
Уже после этого становится понятно, проблема в рекламе или в том, что реклама обучается на слишком раннем событии.
Ещё одна неприятная ситуация: мусорные цели
На практике встречается и более простой сценарий: в стратегию добавлены все цели подряд. Просмотр страницы, клик по кнопке, открытие мессенджера, отправка формы, звонок — и всё это имеет одинаковый вес.
Тогда стратегия получает несколько разных сигналов и может выбрать самый простой для достижения. Формально конверсий становится больше, но бизнесу от этого не легче.
Поэтому набор целей для оптимизации стоит периодически пересматривать. Особенно после изменений на сайте, в CRM или в аналитике.
Когда офлайн-конверсии особенно нужны
В первую очередь — там, где заявка и продажа разделены во времени.
- услуги с обработкой лида менеджером;
- B2B;
- мебель, ремонт, строительство;
- медицина и другие направления с записью и последующей оплатой;
- товары, которые часто заказывают по телефону;
- проекты с офлайн-точками продаж;
- любые ниши, где большая часть заявок отсеивается.
Чем больше разница между «оставил контакты» и «принёс деньги», тем выше ценность обратной передачи данных.
Что в итоге
Автоматические стратегии в Директе не могут оптимизироваться по данным, которых у них нет. Если бизнес передаёт только факт заявки, стратегия и будет искать заявки.
Когда качество лидов различается, этого сигнала часто недостаточно. Тогда имеет смысл возвращать из CRM более глубокие события: квалификацию, оплату, доход.
И если в отчёте всё выглядит красиво, а отдел продаж недоволен качеством лидов, не спешите обвинять алгоритм. Иногда он просто очень хорошо выполняет неверно поставленную задачу.