Фаннелы для RevOps: как доказать, что ваша воронка доводит до выручки

Фаннелы для RevOps: как доказать, что ваша воронка доводит до выручки

В 2026 лидогенерация “MQL → SQL → сделка” часто перестаёт быть единственной осью. Маркетинг вместе с продажами и customer success (удержание/ценность продукта) отвечает за выручку, поэтому в Mixpanel Funnels нужно связывать продуктовые шаги с бизнес-результатом — хотя бы через модель “сигнал раннего намерения → момент готовности → выручка”.

Как сделать это за неделю.

1) Подготовьте метрики и события в Mixpanel
— Определите один “бизнес-событие” (например, account_converted_to_paid, opportunity_won, invoice_paid) и одно или два “промежуточных” продуктовых события (например, invited_team, first_integration_connected, created_first_dashboard).
— Проверьте, что события приходят с одной и той же логикой идентификаторов: на уровне пользователя (user_id) и/или аккаунта (company_id, account_id). Для B2B почти всегда важнее аккаунт.
— Сведите названия событий к стабильным: без синонимов и дублей. Если в истории есть варианты (opportunity_won_v2), оставьте один главный и маппинг сделайте на уровне трекинга/ETL.

2) Постройте базовую воронку “намерение → готовность”
— Откройте Funnels.
— Выберите уровень анализа: Account (если события доступны по компании) или User (если модель сделки завязана на пользователя).
— Добавьте шаги в порядке, отражающем процесс в вашем продукте:
— Step 1: “первый полезный запуск” (например, first_value_achieved)
— Step 2: “расширение использования” (например, invited_team или connected_integration)
— Step 3: “готовность к покупке/продлению” (например, pricing_viewed + contacted_sales — или один событие типа requested_demo/started_trial_to_paid)
— Установите окно конверсии (time window) в разумных пределах вашей цепочки. Цель — не смешать несвязанные визиты/сессии.

3) Задайте разрезы, которые пригодятся RevOps
В Funnels обязательно включите сегменты, чтобы продажам и success было что обсуждать, а не “общая статистика”.
— Разрез по каналу привлечения (channel_source) — но только если он проходит server-side и не разваливается на privacy-first атрибуции.
— Разрез по размеру аккаунта (company_size_bucket).
— Разрез по типу использования (product_plan или feature_adoption_flag).
Если канал у вас нестабильный, начните с продуктовых признаков (feature_adoption_flag) — в 2026 это часто надёжнее.

4) Сделайте “фаннел диагностику” вместо одного отчёта
Вместо того чтобы смотреть одну воронку целиком, сделайте две-три:
— Funnel A: от “ценности” до “контакта/готовности” (value → requested_demo/started_security_review)
— Funnel B: от “готовности” до “оплаты” (requested_demo/approved → account_converted_to_paid)
— Funnel C: от “ценности” до “оплаты” (value → paid) — как контрольная сумма
Так вы отделите проблему продуктового момента (до готовности) от проблемы продаж/закрытия (после готовности).

5) Включите контроль качества данных (иначе выводы будут вредными)
— Проверьте, что доля пользователей/аккаунтов без Step 1 не “объясняет” всё. Если много пропусков — сначала фиксим трекинг.
— Сравните конверсии на тестовой выборке: 2–3 сегмента должны различаться логично (например, большие аккаунты имеют выше шанс пройти Step 2).
— Если у вас есть инкрементальность (incrementality) по маркетингу/кампаниям — добавьте сегмент “exposed vs not exposed” и посмотрите, меняется ли путь до payment, а не только верхняя часть.

6) Превратите результаты в действия на этой неделе
Завершите пост-обработку воронки одним конкретным решением:
— Если провал в Step 2: сформируйте список триггеров для onboarding (например, подсказки при connected_integration не выполняются — надо поправить сценарий).
— Если провал после Step 3: передайте продажам “аккаунты, дошедшие до готовности, но не оплатившие” с сегментацией по plan/company_size — это улучшает приоритизацию и снижает шум.
— Если провал распределён: пересмотрите критерии “готовности” — возможно, ваш Step 3 слишком общий и надо заменить на событие ближе к финальному согласованию.
…