директор и машина · маркетинг · запись № 044 · 24 августа 2026 · Давид Герштейн

Куда пропадают заявки с сайта на пути к оплате

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

Утро понедельника, отдел маркетинга смотрит на дашборд с заявками с сайта: конверсия органики упала. В январе было 17%, в марте — почти 15%, в апреле — уже ниже 10%. Руководитель произносит вслух: «Тенденция по лидам идёт вниз. Если отдел продаж работает по плану, а маркетинг столько лидов не даст — мы снова там, где не хотим быть». Логичная реакция — резать бюджет на органику и переливать деньги в платный трафик.

Проблема в том, что цифра 10% — не про трафик. Она про то, как отчёт считает лидов. Одна точка входа на сайте генерит два-три дубликата в CRM. Каждый десятый-пятнадцатый лид вообще не атрибутируется — пользователь заблокировал куки или почистил историю, а в декабре доля таких «ничейных» заявок доходит до 30%. И конверсия в отчёте зависит от того, по какой дате её считать: по дате создания заявки или по дате оплаты. На одном и том же массиве данных эти два среза дают расхождение в разы. Отдел продаж здесь — 8 менеджеров с планом около 50 сделок в месяц при обороте ~9 млн ₽ и среднем чеке ~180 тыс. ₽; похожий разбор того, как искажённые цифры ломают план продаж, — в статье про ошибки согласования договоров. Если решение «резать органику» принято на кривых цифрах — это удар не по строчке в таблице, а по реальному потоку сделок.

Экран, который врал по-тихому

Вот как выглядел дашборд до пересборки. Одна вкладка, три колонки: дата, число заявок с сайта, конверсия в продажу. Автообновление раз в сутки. Красиво, но бесполезно для управленческого решения — потому что за каждой цифрой в колонке «заявки» стоят как минимум четыре разных явления, слитых в одну сумму.

Руководитель наткнулся на разрыв случайно, пока разбирался с падением конверсии: похожий кейс, где смена фильтра «дата оплаты / дата создания» меняла итоговую сумму отчёта в разы, я уже подробно разбирал в статье про то, во сколько на самом деле обходится реклама. В своей ситуации руководитель обнаружил то же самое: сумма по одному и тому же месяцу отличалась почти вдвое в зависимости от того, по какой дате её считать — по дате создания сделки или по дате поступления оплаты. Один и тот же массив данных, два разных вывода — смотря кто и как считает.

Ещё одна цитата с той же планёрки: «Отсутствие информации — это отсутствие рычагов давления. И это меня прям очень сильно бесит». Речь шла о невозможности разделить конверсию по Google и по Яндексу из-за ограничений интеграции — а без этого разреза непонятно, куда лить бюджет, а откуда его убирать.

Пять причин, почему заявки с сайта теряются в отчёте

После разбора набралось пять причин, по которым один и тот же экран показывал разные версии реальности.

1. Дубли на входе. Одна точка входа на сайте (форма, чат-бот, звонок с сайта) создаёт два-три лида в CRM — например, если форма отправляет данные и в CRM напрямую, и через рекламный пиксель отдельным вебхуком. Отчёт считает валовые заявки, не различая уникальные обращения.
2. Неатрибутируемый трафик. 10–15% лидов в обычный месяц и до 30% в декабре невозможно привязать к каналу — блокировщики рекламы, приватный режим, очистка cookies. Эти лиды либо выкидываются из отчёта по каналам (искажая конверсию платных источников вверх), либо приписываются случайному каналу (искажая её вниз).
3. Дата создания vs дата оплаты. Сделка может быть создана в одном месяце, а оплачена в другом. Если отчёт не разделяет эти два среза явно, любое сравнение план/факт по месяцам становится нечестным — это тот же механизм, что подробно разобран в статье про сдвиг дат в CRM врёт: как я поймал Битрикс24.
4. Валовый объём вместо качества. Из потока лидов только 120 из 300 (40%) проходили проверку качества, хотя план предполагал отвал не более 20%. Отчёт со строчкой «заявки с сайта: 300» без разбивки на качество выглядит отлично и полностью врёт про реальный поток годных обращений.
5. Смешение источников без разреза. Конверсия органики падала три месяца подряд (17% → 15% → менее 10%), но в общем отчёте это тонуло среди платного трафика — никто не видел тренд, пока кто-то не построил отдельный срез вручную.

Маркетолог Оля, разбирая похожий случай, формулирует это так: продажи кричат «лиды плохие», а на деле часть «плохих» лидов — просто дубли одного и того же человека, посчитанные трижды (подробнее — Лиды есть, а продаж нет).

Пересборка экрана: что делали по шагам

Дальше — не абстрактная «оптимизация воронки», а конкретная последовательность действий, которую можно повторить с любой CRM, где есть вебхуки.

1. Дедупликация на входе. Что: каждая новая заявка. Чем: скрипт-обработчик вебхука сравнивает телефон и email с последними 30 днями лидов. Куда: если совпадение найдено — заявка помечается флагом «дубль» и не увеличивает счётчик валовых лидов в отчёте, а лишь дописывается как повторное касание к существующей карточке.
2. Маркировка неатрибутируемых. Что: заявки без utm-меток и с пустым referrer. Чем: правило в CRM плюс серверная (не только клиентская) фиксация источника через IP и таймстемп сессии. Куда: отдельная категория в отчёте «источник не определён», не смешанная ни с одним платным каналом.
3. Две даты вместо одной. Что: момент создания сделки и момент поступления оплаты. Чем: два отдельных поля в CRM, оба выводятся в отчёт как независимые срезы. Куда: план/факт по месяцам считается по дате оплаты, скорость цикла — по разнице между датами.
4. Скоринг качества на входе, а не через две недели. Что: поведенческие данные с сайта (время на странице, посещённые разделы) плюс данные из внешних источников (сегмент, тип услуги). Чем: модель присваивает предварительную вероятность сделки сразу при создании лида. Куда: приоритет менеджеру — кому звонить в первую очередь, а не общий список без сортировки.
5. Разрез по каналу без смешения. Что: конверсия по каждому источнику отдельно (органика, Google, Яндекс, соцсети). Чем: отдельная вкладка отчёта с недельной динамикой, а не общий агрегат. Куда: еженедельная сверка на планёрке, где смотрят не общее число лидов, а тренд по каждому каналу отдельно.
6. Контрольная точка по дням. Что: план 220 лидов в мае, 332 в июне при плановых 15 качественных лидов в день. Чем: детализация по неделям и дням — например, за прошлую неделю (без выходных) факт был 16–17 качественных лидов в день, за месяц накопилось больше 200, и при оставшихся 5–6 рабочих днях видно уже к вечеру среды, догоняет компания план или нет. Куда: короткий чат-алерт, если факт дня ниже 70% от плана два дня подряд.

ИИ-связка: конвейер разметки и скоринга

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

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

Роль: ты — классификатор входящих заявок с сайта для B2B-услуг.
На вход подаётся JSON с одной заявкой и списком похожих заявок за 30 дней.

Формат входа:
{
  "lead_id": "84213",
  "phone": "+7900...",
  "email": "client@mail.ru",
  "utm_source": "yandex_direct",
  "utm_medium": null,
  "time_on_site_sec": 340,
  "pages_visited": ["/tarify", "/kejsy", "/kontakty"],
  "segment": "malyi_biznes",
  "similar_leads_30d": [
    {"lead_id": "84190", "phone": "+7900...", "created_at": "2026-08-20"}
  ]
}

Задача:
1. Определи, является ли заявка дублем одной из similar_leads_30d
   (совпадение телефона ИЛИ email — это дубль).
2. Если utm_source отсутствует и referrer пустой — отметь как
   "no_attribution" с причиной.
3. Оцени вероятность сделки от 0 до 100 на основе времени на сайте,
   посещённых разделов и сегмента (посещение /tarify и /kejsy —
   сильный сигнал; только /kontakty без остального — слабый).
4. Не придумывай данные, которых нет во входе.

Формат ответа — строго JSON, без пояснений вне JSON.

Пример ответа модели:

{
  "lead_id": "84213",
  "is_duplicate": false,
  "duplicate_of": null,
  "attribution_status": "attributed",
  "no_attribution_reason": null,
  "deal_probability": 62,
  "priority": "high"
}

Инженерная обвязка. Вебхук Bitrix24 (или amoCRM API) ловит событие создания лида и кладёт JSON во временную очередь — таблицу Google Sheets или отдельный лист. Скрипт-обработчик раз в минуту забирает необработанные строки, вызывает модель, пишет результат обратно в карточку лида двумя полями: «дубль/не дубль» и «скоринг». Если API не ответил за 15 секунд — три повторные попытки с задержкой, при финальном отказе строка помечается «требует ручной проверки» и уходит алертом в Telegram-канал маркетинга. Логика перезапуска простая: скрипт идемпотентен, повторный вызов на уже обработанном лиде просто перезаписывает те же поля, ничего не задваивая.

Экран после пересборки

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

На диаграмме ниже — доля дублей, неатрибуции и брака по качеству на одном и том же потоке лидов.

На диаграмме — как менялась конверсия органики: с 17% в январе до уровня ниже 10% в апреле, три месяца подряд вниз.

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

SEO-специалист, который взялся за пересборку, обещал уложиться в два дня — сделал за выходные, добавив реал-тайм отслеживание лидов и конверсий по страницам. Дальше команда параллельно тестирует две ключевые позиции в топ-3 Яндекса до 15 июня, чтобы проверить, коррелирует ли рост трафика с ростом продаж, или проблема остаётся не в трафике, а в обработке. Отдельно ввели коэффициент сезонности 0,8 для декабря — чтобы не сравнивать провальный по объективным причинам месяц с остальными наравне.

Где цепочка рвётся ещё раз — на стыке с оплатой

Даже с идеально размеченным дашбордом цепочка «клик → лид → сделка» может рваться не в аналитике, а в операционке рядом с ней. В том же отделе всплыла отдельная проблема: чтобы лиды пришли в начале месяца, счёт за них нужно оплатить заранее — например, 28-го числа предыдущего месяца, чтобы получить поток 3-го числа следующего. При этом, по признанию менеджера, около половины счетов оплачивается не вовремя. Результат предсказуем: даже безупречный отчёт о заявках не спасает, если сам поток лидов физически не запущен из-за просроченного счёта — тогда «дно» на графике конверсии на самом деле «дно» на графике оплат, а не на графике трафика. Это тот же тип ошибки, что и путаница дат создания/оплаты сделки, только на шаг раньше в цепочке — перед тем, как лид вообще появится.

Что это стоит и что даёт

Разработчик потратил на пересборку дашборда и вебхука дедупликации примерно 16 часов (оценка, по факту «выходные»). При ставке около 1000 ₽/час это разово 16 000 ₽ (оценка). Скоринг лидов дешёвой моделью при потоке 1500 заявок в месяц — расходы на API около 3–5 тысяч рублей в месяц; точный разбор счетов за токены — тема отдельной статьи Сколько на самом деле стоит ИИ в месяц.

Эффект считаю отдельно от прочих маркетинговых мер — только то, что даёт именно очистка отчёта и скоринг на входе, без учёта параллельных изменений в SEO, рекламе или SMM. Формула для своего случая словами: (фактическая доля отвала минус плановая доля) × поток лидов в месяц = число лишних лидов, которые кто-то должен вручную посмотреть и закрыть; дальше это число × время на один лид в часах × ставка часа сотрудника = потери в месяц на обработку мусора.

Подставляю числа этого случая: поток 1500 лидов в месяц, факт отвала 60% вместо плановых 20% — это (60% − 20%) × 1500 = 600 лишних лидов, которые кто-то формально обрабатывает (смотрит, звонит, закрывает карточку). Время на такую обработку — около 10 минут на лид (оценка, консервативно, без учёта времени на повторные касания). Это 600 × 10 мин = 6000 минут = 100 часов в месяц — больше половины ставки одного менеджера. При ставке около 1000 ₽/час (оценка) это 100 × 1000 = 100 000 ₽/мес чистых потерь на обработку мусора, который скоринг на входе мог бы отсеять сразу.

Разово потраченные на пересборку ~16 000 ₽ плюс 3–5 тыс. ₽/мес на скоринг при экономии порядка 100 000 ₽/мес на разгрузке менеджеров от мусорных лидов окупаются меньше чем за неделю (оценка, консервативно — если хотя бы половина из этих 100 часов реально высвобождается, а не уходит на другие задачи). Это только вклад дедупликации и скоринга на входе — эффект от исправления путаницы дат и разреза по каналам в этой сумме не учтён, потому что он управленческий, а не почасовой.

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

Чек-лист на понедельник

• Сравнить число заявок на форме сайта, число событий в вебхуке CRM и число карточек лидов за одну неделю — посчитать расхождение в процентах.
• Проверить, есть ли в CRM явный флаг «дубль» и отдельная категория «источник не определён» — если нет, завести их до пересборки отчёта.
• Развести в отчёте две даты: создания сделки и оплаты — и пересчитать план/факт по каждой отдельно.
• Проверить синхронизацию оплаты счетов за лидогенерацию с датой их фактического поступления — просроченный счёт выглядит на графике как провал трафика, хотя это провал платежей.
• Выгрузить за месяц долю лидов, прошедших контроль качества, и сравнить с плановым отвалом — если факт выше плана вдвое-втрое, разбираться до пересборки скоринга.
• Назначить человека, который раз в неделю сверяет автоматический отчёт с CRM вручную — без этого шага любая автоматика через месяц начнёт врать незаметно.
• Запустить скоринг на тестовой выборке 100–200 лидов и сравнить приоритет модели с тем, что менеджеры делают интуитивно — расхождение покажет, где модель ошибается.

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

Почему заявки с сайта не работают, хотя реклама крутится и лиды идут?

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

Что делать, если конверсия сайта упала, а причина непонятна?

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

Как проверить, что заявки с сайта теряются именно на этапе передачи в CRM?

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

#аналитика и отчётность #ошибки и провалы #контроль и надёжность