Зафиксируйте событие и единицу подсчёта
Для расчёта активации команда должна договориться, какую завершённую работу она сможет подтвердить. В учебном сервисе согласования расходов сотрудник подаёт авансовый отчёт, а руководитель его утверждает. Первым результатом будем считать первый утверждённый отчёт в аккаунте компании. Оплата расхода происходит позже и в это определение не входит.
Единицей подсчёта здесь служит аккаунт. Несколько сотрудников могут подготовить отчёты, а руководитель может их утвердить; продуктовая команда изучает запуск общего процесса. Если считать этих людей как независимых новых пользователей, действия одной компании распадутся на разные пути и часть зависимостей между ролями исчезнет из анализа.
Событие утверждения должно содержать идентификатор аккаунта, время и статус успешного решения. Проверьте его по нескольким исходным записям: отчёт действительно утверждён, время соответствует этому действию, аккаунт определён верно. Открытие экрана подтверждения или запрос в очереди фиксируют более ранние этапы. Если включить их в конечное событие, процент активации будет отвечать на другой вопрос.
У активации и повтора разные окна
В учебном расчёте дадим новому аккаунту 14 дней с момента создания. Активация за этот срок равна числу аккаунтов с первым утверждённым отчётом, делённому на все новые аккаунты выбранной когорты. Каждый аккаунт должен получить полные 14 дней наблюдения. Сам срок служит условием примера; для своего сервиса его выбирают по циклу задачи клиента.
Для перехода к подаче отчёта знаменатель будет уже. Возьмите аккаунты той же когорты, которые пригласили сотрудника в свои первые 14 дней. В числитель попадут аккаунты из этой группы, где после приглашения сотрудник подал первый отчёт до конца того же окна. Отсчёт остаётся привязанным к созданию аккаунта: новое приглашение не добавляет ещё 14 дней. Укажите это в названии или описании показателя, чтобы его не приняли за долю подачи за 14 дней после приглашения.
Повтор начинается с другого события. Среди аккаунтов, у которых после первого утверждения прошло полных 30 дней, посчитайте долю со следующим утверждением в течение этих 30 дней. В числитель входит часть указанного знаменателя. Аккаунт, получивший первое утверждение вчера, ещё не подходит для сравнения за полный срок повтора, даже если успел сделать ещё одно.
Такую запись определений стоит хранить рядом с отчётом. Она объясняет, почему у активации, перехода к подаче и повтора разные знаменатели. Сравнивать проценты без этих условий будет трудно даже внутри одной команды.
Разберите когорту из 40 аккаунтов
Возьмём вымышленные числа: за одну неделю создали 40 аккаунтов, и к моменту расчёта у каждого закончились 14 дней наблюдения. В 12 аккаунтах за этот срок утвердили первый отчёт. Активация составит 12 / 40 = 30%. Это учебный расчёт, без отраслевого ориентира и результатов реального продукта.
Все 40 аккаунтов остаются в знаменателе. Остальные 28 не достигли выбранного результата за срок наблюдения; по этому расчёту нельзя утверждать, что они не достигнут его позже. Если добавить вчерашние регистрации, у части когорты окажется меньше времени на завершение и процент перестанет описывать прежние условия.
Для TTV возьмите время от создания аккаунта до первого утверждения у 12 завершивших путь. Медиана и p75 этой выборки относятся только к ним. У остальных 28 в рамках выбранного окна нет измеренного времени до результата, поэтому они не входят в этот расчёт. Рядом с показателем времени оставьте «12 из 40 за 14 дней»: так читатель отчёта увидит, какую часть запусков описывает скорость.
После общего расчёта можно разобрать переходы. Если аккаунт пригласил сотрудника, но тот не подал отчёт, проверьте этот участок. Если отчёт уже подан, изучите ожидание руководителя. Связывайте события сотрудников и руководителей по аккаунту; последовательность работы команды не совпадает с путём одного человека.
Отделите место задержки от её причины
Задержка между подачей и утверждением может возникнуть из-за отсутствующего руководителя, неполных документов или ошибки уведомления. Воронка выделит аккаунты, на которых стоит проверить эти предположения. Откройте несколько задержавшихся отчётов, посмотрите, кому направили запрос и что видел сотрудник. После этого можно выбирать между исправлением уведомления, пояснением требований к документам и изменением рабочего процесса.
Версию события тоже нужно учитывать. Если команда стала иначе определять «утверждено», пересчитайте прежние когорты по новому правилу, когда исходные данные позволяют это сделать, или начните отдельную серию. Прямая склейка процентов смешает изменение учёта с изменением поведения клиентов.
Наконец, более высокая активация среди увидевших подсказку ещё не показывает её эффект. Подсказку могли видеть сотрудники, которые уже начали подавать отчёт и потому имели больше шансов закончить. Для причинной оценки заранее задайте подходящие аккаунты, итоговое событие и срок, затем случайно распределите аккаунты между вариантами с подсказкой и без неё. Распределение по аккаунтам сохраняет совместную работу ролей в одном варианте.
При небольшой базе несколько завершений заметно меняют процент. Наблюдение за работой поможет разобраться в задержках, но не заменит оценку неопределённости эффекта. В выводе разделите то, что проверили по записям, и то, что ещё предстоит проверить экспериментом.
