В рекламном кабинете всё выглядит прилично: заявки идут, стоимость заявки держится в разумных пределах. В CRM картина другая: половина заявок остаётся без ответа, часть не доходит до счёта, оплатили единицы. Один экран показывает движение, другой — деньги. И если между ними нет связи, рекламная система продолжает учиться на том, что ей видно, а не на том, что важно бизнесу.
Что на самом деле видит рекламная система
Стратегия «Максимум конверсий» старается увеличить долю кликов по объявлениям и фразам, которые чаще приводят к выбранному целевому действию. Если единственная цель — отправка формы, алгоритм получает данные о формах. Он не знает, что часть заявок оказалась мусором, кому-то не дозвонились, а кто-то оплатил заказ через неделю. Это не поломка и не хитрость: система работает с тем сигналом, который ей дали.
Заявка, качественный лид и подтверждённая оплата — разные ступени воронки, и смешивать их нельзя. По-моему, главная ошибка начинается с привычки считать любую форму клиентом. Форма — это ещё не клиент и не гарантия, что человек готов разговаривать. Алгоритм в такой схеме оптимизируется по неполному или промежуточному сигналу, и удивляться результату потом странно.
Цена ошибки на условной воронке
Допустим, на рекламу ушло 100 000 рублей. Пришло 100 отправок формы, 30 заявок признали качественными, 10 клиентам выставили счёт, 6 заказов оплатили. Кабинет, который видит только формы, покажет стоимость заявки 1 000 рублей. А фактическая стоимость оплаченного заказа будет около 16 667 рублей. До оплаты дошло 6% заявок. Это иллюстративный расчёт, а не рыночная статистика, но логика в нём неприятно узнаваемая.
Низкая стоимость заявки сама по себе не доказывает, что реклама приводит покупателей. Она показывает цену промежуточного действия — и только. Можно сколько угодно радоваться дешёвому потоку форм, если не смотреть, что с этим потоком происходит дальше.
Есть и более наглядная схема. Источник А дал 60 заявок и 3 оплаты. Источник Б дал 40 заявок и 7 оплат. Если оптимизироваться только по формам, А выглядит заметно лучше. После возврата оплат ценнее оказывается Б. Это условный пример, но он хорошо объясняет, почему количество лидов и качество лидов — не один и тот же показатель.
Как выглядит нормальная обратная связь
Нормальная цепочка начинается не с кнопки «включить интеграцию», а с дисциплины в CRM. Выглядеть она может так:
- Человек приходит на лендинг и отправляет форму.
- В CRM создаётся лид.
- Контакт подтверждают — например, созвоном.
- Лид квалифицируют: подходит клиент или нет.
- Выставляют счёт или согласовывают заказ.
- Клиент оплачивает.
- В Метрику уходит обновлённый статус и идентификатор заказа.
Дальше важно, чтобы событие привязалось к исходному визиту. Яндекс Метрика поддерживает загрузку данных из CRM и стандартные статусы IN_PROGRESS, PAID, CANCELLED, SPAM, а также пользовательские статусы, связанные с JavaScript-целями. Для стандартных статусов могут появляться цели вроде «CRM: Заказ создан» и «CRM: Заказ оплачен». В документации есть и пример более дробной цепочки: «заказ создан → качественный лид → заказ оплачен». Качественный лид можно передавать отдельной целью, обновлять заказ по его CRM-идентификатору, а затем отправлять статус оплаты.
Чтобы событие вообще связалось с визитом, нужен устойчивый идентификатор. Для офлайн-данных Метрика может использовать ClientId, UserID, yclid или PurchaseId, а при загрузке CRM-данных — также телефон и email, связанные с клиентом. ClientId Яндекс называет рекомендуемым параметром для точной привязки. Если связи «визит — заказ» нет, событие может передаться, но остаться без привязки. Внешне интеграция вроде бы работает, а рекламная система полезного сигнала не получает.
Со сроками тоже лучше не тянуть. Общий период дополнения визитов офлайн-данными составляет 21 день: между последним визитом и обработкой переданных данных должно пройти не больше 21 дня. Для CRM-заказов предусмотрен расширенный период изменения уже добавленного заказа — до 111 дней с момента связанного визита. И ещё нюанс: заказ может быть оплачен онлайн, но событие всё равно передаётся из CRM как офлайн-данные. Это не обязательно покупка «в офлайне» в бытовом смысле.
Если оплат мало
Яндекс рекомендует выбирать цель, которая достигается не реже 10 раз в неделю. На обучение стратегии может уйти не менее 1–2 недель. Это ориентир, а не математическая гарантия эффективности. Если оплат слишком мало, ждать, пока наберётся красивая статистика, можно долго.
В такой ситуации разумно передавать более частый, но содержательный этап: подтверждённый или квалифицированный лид. Это практическая адаптация рекомендации, а не универсальное правило. Ранняя цель помогает рекламной системе получать сигнал, пока финальных покупок недостаточно. Но она не отменяет контроль оплат: иначе можно оптимизироваться на качественные заявки и снова не знать, доходят ли они до денег.
Разным этапам можно назначать разную ценность. В настройках кампании для целей задаётся оценка экономической выгоды, и чем выше ценность, тем более важную роль цель играет в работе кампании. Поэтому заявка, квалификация и оплата не должны механически считаться равноценными событиями. Это разные сигналы, и цена у них разная.
Как проверить, что цепочка работает
В отчёте «Офлайн-конверсии» видно, привязалось ли событие к визиту. Если нет, причина может быть конкретной: отсутствует идентификатор, указана неизвестная цель, визит оказался за пределами периода учёта, передано некорректное время. Смотреть стоит не только на общее число конверсий, но и на несколько реальных заказов по всей цепочке — разумеется, без лишних персональных данных в рабочих таблицах.
Проверку гипотезы лучше делать на одном сегменте или кампании. Сначала наладить передачу подтверждённых этапов, убедиться, что события привязываются, а потом сравнивать не только стоимость заявки, но и долю оплат, стоимость оплаченного заказа и качество лидов. Иначе легко получить красивый отчёт о формах и не заметить, что продажи остались на прежнем месте.
Типичные сбои выглядят скучно: статус в CRM не обновляется вовремя, событие уходит без идентификатора, цель указана неверно, событие приходит слишком поздно. Офлайн-конверсии не включаются одной кнопкой. Без регулярной проверки цепочка может выглядеть включённой, но не давать рекламной системе полезного сигнала.
Что меняется в управлении рекламой
Ориентироваться стоит не на самый дешёвый лид, а на результат, который подтверждает бизнес: квалификацию, счёт, оплату. Сравнивать источники нужно по качеству, а не только по количеству заявок. Дешёвый поток форм может скрывать дорогие и редкие продажи, и наоборот: источник с меньшим числом заявок иногда приносит больше денег.
Гигиена CRM здесь не бюрократия, а часть рекламной настройки. Статусы должны обновляться, идентификаторы — сохраняться. Если этого нет, даже хорошая схема передачи событий превращается в формальность. Алгоритм не обманывают — ему просто дают неполный или промежуточный сигнал. Формулировка скучнее, зато точнее.
Если собирать статусы, идентификаторы и передачу этапов вручную неудобно, есть смысл посмотреть, как эта задача решена в Market-GPT. Там, по данным проекта, реализована цепочка событий от создания лида до оплаты: заявка появляется в системе, проходит обработку, получает квалификацию, доходит до счёта и оплаты. Публично на сайте Market-GPT описаны лендинги, формы заявок, Инбокс и mini-CRM со статусами обработки лидов — то есть место, где эти статусы и появляются. Насколько полно цепочка передаётся в рекламный контур, лучше проверять в самом продукте и на своих данных, а не по обещаниям на лендинге.
Вернёмся к двум экранам из начала. Отчёт рекламного кабинета и CRM могут рассказывать разные истории об одном и том же бизнесе. Разрыв между ними — не техническая мелочь, а управленческая проблема: она влияет на то, куда пойдёт бюджет и каких клиентов реклама будет искать дальше. Рекламная система не обязана угадывать, что произошло после заявки. Ей нужно это сообщить — статусом, идентификатором и дисциплиной обновления данных. Дешёвая заявка — это не результат; результат — оплаченный заказ, о котором рекламная система знает.
