ACTIVATION / КРИТИЧЕСКАЯ ЦЕПОЧКА / ЭКСПЕРИМЕНТЫ
Метрики есть. Модели нет: как понять, что на самом деле двигает деньги
Как связать события продукта с результатом клиента, найти объяснение потерь в воронке и выбрать изменение, которое имеет смысл проверить.
На еженедельной встрече всё выглядит профессионально: конверсия, retention, активные пользователи, средний чек. Графики обновляются без задержек. Но когда нужно решить, что команда делает на следующей неделе, разговор снова начинается с мнений.
Проблема часто в том, что отчёт отвечает на вопрос «что изменилось», а команда ждёт ответа «за что взяться». Между ними нужна проверяемая версия происходящего: какие действия пользователя создают результат, где он теряется и как это связано с деньгами.
Выберите результат, который можно увидеть
Представим сервис планирования смен для небольших сетей. Регистрация ещё ничего не говорит о пользе. Созданный черновик расписания тоже: возможно, руководитель просто открыл шаблон. Более содержательное событие — опубликованное расписание, в котором нужные смены закрыты и сотрудники получили назначения.
Даже такое событие сначала остаётся кандидатом на активацию. Проверьте по разговорам и наблюдениям: действительно ли руководитель получил результат? Затем посмотрите, связано ли событие с дальнейшей работой в продукте. Связь поможет выбрать метрику, но сама по себе ещё не докажет причинность.
В AJTBD используется понятие критической цепочки работ: необходимых задач, без выполнения которых не получится итоговый результат. Для диагностики полезно сопоставить эту цепочку с событиями продукта. Воронка кликов показывает лишь ту её часть, которую вы уже научились измерять.
Один провал воронки — несколько объяснений
Пусть в условной когорте 100 новых руководителей. За первые семь дней 72 начали составлять расписание, 49 опубликовали его, а 31 вернулся к следующему циклу планирования. Все числа относятся к одним и тем же людям; за возвращением наблюдали достаточно долго, чтобы у каждого наступил следующий цикл.
Между началом и публикацией потерялись 23 человека. Это 23 процентных пункта от исходной когорты и около 32% от начавших составление. Не смешивайте эти две величины в презентации: они отвечают на разные вопросы.
Из чисел пока неизвестно, почему люди остановились. Руководитель мог не понять интерфейс. Мог обнаружить, что сервис не учитывает ограничения сотрудников. Мог ждать списка доступности от коллеги. А мог уже решить задачу в таблице и открыть приложение из любопытства.
| Версия | Что проверить | Возможное действие |
|---|---|---|
| Неясно, как опубликовать | Наблюдение за первым использованием | Изменить переход к публикации |
| Не хватает исходных данных | Последний реальный цикл планирования | Упростить сбор доступности |
| Результат нельзя использовать | Разобрать полученное расписание | Исправить конкретное ограничение |
| Пришёл другой сегмент | Сопоставить задачу и источник привлечения | Скорректировать обещание и квалификацию |
Одинаковый график может привести к четырём разным решениям. Именно поэтому команда не должна назначать редизайн по одному проценту конверсии.
Свяжите изменение с экономикой
Допустим, продукт получает 400 подходящих регистраций в месяц. Команда предполагает, что улучшение первого сценария увеличит долю платящих на 5 процентных пунктов. Это 20 дополнительных плательщиков. Если каждый приносит 3 000 ₽ маржинального дохода за первый оплаченный месяц, модель обещает ещё 60 000 ₽ за этот месяц.
Это сценарий, а не найденный эффект. Из него нужно вычесть дополнительные расходы, проверить удержание и понять, сколько стоит само изменение. Главное здесь — прозрачная связь допущений: если ожидаемый рост оплаты не случится, финансовый результат тоже не появится.
Такая модель позволяет сравнить улучшение активации с другими ходами: изменением пакета, канала привлечения или стоимости обслуживания. Решение перестаёт зависеть от того, у какого графика самое тревожное падение.
Договоритесь, что будет считаться доказательством
Перед выпуском запишите основную метрику, период наблюдения и ограничения: например, публикаций должно стать больше, а количество ошибочных назначений и нагрузка на поддержку не должны ухудшиться. Если изменение затрагивает командную работу, эксперимент обычно разумнее распределять по организациям, чтобы участники одного рабочего пространства не получали конфликтующие варианты.
Размер выборки зависит от исходной метрики, ожидаемого эффекта и допустимой ошибки. Неделя наблюдения не становится достаточной только потому, что закончился спринт. При малом потоке пользователей используйте наблюдения и ограниченный пилот для уточнения гипотезы, прямо обозначая, что точного количественного эффекта пока нет.
После проверки возможны три нормальных решения: расширить изменение, переработать его или остановить. Полезный отчёт заканчивается одним из них — с объяснением, какие данные позволяют сделать именно этот шаг.
