RevOps-реальность: почему “MQL воронка” ломает дашборды в 2026

RevOps-реальность: почему “MQL воронка” ломает дашборды в 2026

В 2026 я снова и снова вижу одну и ту же проблему: дашборды строят так, будто у маркетинга и sales всё ещё разные судьбы. В итоге мы честно считаем MQL, SQL, конверсии в meeting и даже стоимость лида… но не можем ответить на главный вопрос RevOps — что именно маркетинг делает с **выручкой** и **долей выручки, которая доживает до повторных продаж**.

Моё наблюдение по внедрениям BI: если в BI-модели “лид” живёт своей жизнью (UTM/канал/оффер → MQL), а в другой витрине “выручка” живёт по сделкам (pipeline → won → revenue), то через 2–3 месяца вы гарантированно получаете разрыв: маркетинговые метрики перестают быть объясняющими. Не потому что они “неправильные”, а потому что бизнес перестаёт принимать решения по этой логике.

Где ломается чаще всего:

— Единый ключ. Лиды и сделки связаны не идеально: есть дубли, ручные переносы, смена ответственных, “вход” клиента может быть не там, где мы его впервые увидели.
— Неподходящий уровень агрегации. “MQL за месяц” не равен “выручке за месяц” — задержки в B2B огромные, а в 2026 на добавку накладывается privacy-first атрибуция: last-click всё хуже объясняет причинность.
— Опора на конверсии вместо инкрементальности. Много команд остаются в режиме “какая доля дошла”, но уходят от вопроса “что изменилось благодаря маркетингу”.

Как я предлагаю чинить модель (и какие метрики должны появиться раньше, чем очередная таблица по каналам):

1) Ввести единый “customer-lifecycle” уровень: не лид, а учётная запись (account) или контакт, который превращается в сделку.
2) Считать маркетинг как вклад в **создание возможностей** (opportunity creation), а не только в лидогенерацию. Для дашборда это выглядит как: маркетинг-активность → появление opportunity → won rate → выручка/маржа.
3) Добавить “cohort-lag” в отчёты: не просто конверсии по датам, а конверсию по группам поступлений с учётом времени до сделки. Это часто даёт единственное “железное” отличие между “канал лучше, потому что быстро” и “канал хуже, потому что жмёт воронку не в ту сторону”.

Цифра из практики: когда мы пересобрали модель с переходом от MQL к account-based когортам, разница по эффекту каналов стала внятной уже на 2-м месяце. Оказалось, что один из источников выглядел слабым по MQL→SQL, но стабильно давал более высокий won rate и меньшую долю “пустых” сделок на последующих стадиях. Старый дашборд это скрывал структурно, новый — показывает за счёт правильного уровня и задержек.

Если у вас сейчас дашборд “воронка MQL → SQL → revenue” живёт отдельной витриной, я бы начал не с новой визуализации, а с проверки связности данных: насколько хорошо маркетинговые сущности соответствуют сущностям продаж на уровне account и как ведут себя когортные метрики с учётом lag. Это тот случай, когда BI должен быть не витриной, а механизмом объяснения выручки.

— @MarketingAnalyticsRoomPro