Кейс: 17 смет загрузили как продажи — Директ учился на 14 заказах без оплаты

Смета ушла — продажа появилась

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

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

Технически обмен работал без ошибок: ID заказа был, сумма стояла, событие принималось. Именно поэтому поломка выглядела убедительно.

Отчёт сошёлся, бизнес — нет

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

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

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

Сумма не превращает расчёт в оплату

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

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

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

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

Полчаса на проверку вместо месяца обучения

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

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

Проверьте правило интеграции на одной тестовой карточке. Перевод в «Смета отправлена» не должен создавать оплату. Перевод в «Успешно реализовано» должен отправлять устойчивый ID и фактическую сумму один раз.

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

Сигнал должен пережить три вопроса

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

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

Чек-лист: не обучается ли Директ на сметах

• Какой точный статус CRM создаёт событие продажи?
• Есть ли у этого статуса дата и сумма фактической оплаты?
• Сколько «продаж» из отчёта всё ещё находятся на согласовании?
• Что происходит с отменённой или пересчитанной сделкой?
• Передаётся ли один устойчивый ID заказа при обновлениях?
• Совпадает ли число оплат в аналитике с подтверждёнными оплатами CRM?

Если отчёт показывает больше продаж, чем банк и CRM, не ждите, что алгоритм сам разберётся. Он честно усиливает тот сигнал, который ему дали, — даже когда «продажей» назвали отправленный PDF.