Чистая воронка против красивой: что выбирают зрелые команды

Откуда берутся красивые воронки

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

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

Три признака чистой воронки

Каждый этап – это событие

Не состояние сознания клиента, а факт, который зафиксирован в системе: открыл страницу, оставил телефон, взял трубку, подписал. Если факта нет – этапа нет.

• У этапа есть источник данных и человек, который за него отвечает
• Переход между этапами считается по одному правилу весь год
• Этап нельзя «примерно оценить» – либо событие есть, либо нет

Между этапами нет дыр

Сумма переходов сходится с общим числом. Если из 100 заявок 40 стали сделками, а 30 отвалились, вы обязаны знать, где остальные тридцать, а не списывать их на «долгий цикл».

1. Выгрузите сырые данные за квартал, а не сводку из дашборда
2. Сверьте количество на каждом этапе с CRM и с отделом продаж
3. Найдите расхождение больше 5% и разберитесь до причины
4. Зафиксируйте правило подсчёта в документе, а не в голове аналитика

Воронка помещается на один экран

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

Как выглядит разница на цифрах

Ниже – один и тот же проект до и после пересборки. Число этапов уменьшилось, но каждый стал измеримым, и стало видно, где именно теряются деньги.

Главное изменение – строка «квалифицированные». До пересборки 44% заявок были нецелевыми, но это не было видно: в отчётах отдел маркетинга показывал 620 лидов, а отдел продаж считал, что получил 344.

Как это фиксируют технически

Правило подсчёта должно жить в коде или в конфиге, а не в договорённостях. Минимальный вариант – один SQL-запрос, который считает воронку и лежит в репозитории.

select
  stage,
  count(distinct lead_id) as leads,
  round(100.0 * count(distinct lead_id)
    / max(count(distinct lead_id)) over (), 1) as pct
from funnel_events
where event_date >= date_trunc('quarter', current_date)
  and is_test = false
group by stage
order by min(stage_order);

Такой запрос – это и есть документация воронки. Он не может «примерно посчитать», не зависит от настроения аналитика и переживает смену подрядчика.

С чего начать на своём проекте

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

• Выпишите этапы, для которых есть событие в системе
• Всё остальное вычеркните – это не воронка, а гипотезы
• Для каждого оставшегося этапа назначьте ответственного
• Опишите правило подсчёта одним предложением и запросом