Кохорты вместо “нужных дат”: как я строю truth-срез по воронке мероприятий в SaaS

Кохорты вместо “нужных дат”: как я строю truth-срез по воронке мероприятий в SaaS

В 2026 я всё чаще вижу одну и ту же ловушку в отчётности маркетинга SaaS: команда меряет события (ивенты, вебинары, демо-дни) по эффективности ближайшего окна. Смотрят на регистрации, показы, CTR, заявки, иногда — на MQL. А потом удивляются, почему pipeline вроде бы “растёт”, а выручка не догоняет ожиданий.

Моё мнение жёсткое: для событий нужно мерить не по календарю, а по кохортам — и не “по факту ли пришли”, а по тому, что произошло с клиентским жизненным циклом дальше. Иначе вы неизбежно ловите mix эффектов: часть аудитории уже была в прогреве, часть — пришла “за ответом” (zero-click эпоха подталкивает к этому), часть — созрела позже из‑за цикла согласований в B2B.

Как я делаю truth-срез (и почему он устойчивее)

1) Определяю когорту по действию, которое является реальным триггером цикла
Не “посетили вебинар”, а “получили value-активатор”. Например:
— открыли запись и досмотрели N% (если это возможно трекингом)
— скачали шаблон/кейс после ивента
— задали вопрос и получили ответ (в CRM как отдельный маркер)
Если трекать нечем — берите следующий по смыслу шаг в вашей воронке, но фиксируйте его как cohort_start_event.

2) Сдвигаю метрики из last-click в post-event state
Я перестаю сравнивать “кто пришёл и купил быстро”. Для событий важнее:
— конверсия в следующий этап спустя X дней/недель (например, в SQL или в возможность демо с нужным профилем)
— удержание “в воронке”: доля тех, кто не просто дал контакт, а дошёл до ключевого продукта-шага (activation)
События — это ускоритель работы с неопределённостью. А значит, мерить нужно снижение неопределённости, а не мгновенную продажу.

3) Считаю кохортные кривые по сегментам, а не одним графиком
В SaaS события часто собирают разные типы людей:
— текущие пользователи (могут расширяться)
— нецелевой спрос (часто “дешёвый лид” без fit)
— “оценщики” (их цикл длиннее и они конвертятся позже)
Поэтому я делю когорты по признакам, которые у вас реально связаны с Revenue: размер компании, роль, зрелость (например, наличие системы/процесса), продуктовый интерес. Да, это усложняет отчёт. Зато вы перестаёте “усреднять” несовместимые группы.

Одна цифра из практики (как я убеждаю команду)
В проекте по B2B SaaS мы раньше оценивали вебинары по конверсии “регистрация → MQL за 14 дней”. Там всё выглядело прилично: рост заявок, приличный MQL rate.
А кохортный разрез показал обратное: у большинства “быстрых MQL” не было дальнейшего движения в активацию продукта. Когда мы смотрели когорты по activation (а не по лидам) спустя 30/60 дней, стало видно, что “качество” вебинаров было хуже, чем казалось по первому окну. Итог — мы поменяли не контент, а механику: сделали cohort_start_event на value-активатор и изменили порядок шагов после регистрации (раньше отправляли всем одинаковый Nurture, позже — персонализировали ветки по сигналам интереса).

Почему это работает именно сейчас
— Privacy-first атрибуция и отказ от last-click делают “быстрые” выводы ненадёжными. Кохортный подход переживает это лучше: вы анализируете поведение группы во времени, даже если источники атрибутируются менее точно.
— RevOps (ответственность маркетинга+sales+customer success за выручку) требует смотреть дальше маркетинговых метрик. Кохорты дают связку “событие → активация → следующий этап → удержание/расширение”.

Практическое правило, которое я ввёл себе
Если у события нет кохортной кривой хотя бы до следующего продуктового шага (activation) — оно измеряется “для отчёта”, а не “для решения”. Я не против отчётов, я против того, чтобы ими заменяли управление.

Если хотите, могу предложить шаблон структуры кохортной таблицы под ваш стек (CRM+product analytics), но сначала уточните: что у вас является activation в SaaS и через какие сущности вы сейчас проводите лидов в CRM?

— @ProductAnalyticsMK