Пользователь зарегистрировался.
А пользу получил?

1. Отделите подготовку от первого результата

Представим приложение для личного планирования. Человек хочет организовать свои дела. Создание аккаунта и просмотр подсказок помогают начать, но сами по себе ещё не показывают, что приложение пригодилось.

Кандидат на признак активации: пользователь создал собственную задачу и затем отметил её выполненной. Это ближе к использованию продукта по назначению, чем открытие главного экрана.

Однако галочку можно поставить случайно или ради прохождения обучения. Поэтому мы рассматриваем это действие как гипотезу о пользе. Стоит проверить реальные сценарии и поговорить с пользователями: что они пытались сделать и помог ли продукт.

Для сервиса записи таким признаком может быть состоявшаяся консультация, а для командного инструмента — совместное действие нескольких участников. Не переносите чужое определение без проверки смысла.

2. Зафиксируйте правило до расчёта

Для примера выберем первые семь суток после регистрации. Срок условный: он должен соответствовать тому, как часто людям нужен продукт. Для ежедневного планировщика и сервиса ежегодной отчётности периоды будут разными.

Событие ровно через 168 часов уже не входит в окно. Это не семь календарных дат: используйте временные отметки в единой шкале времени. Создание и выполнение связывайте по ID задачи, а не только по ID пользователя.

В знаменателе должны остаться и те, кто не открыл приложение после регистрации. Если исключить их, показатель будет отвечать на другой вопрос — об активации среди начавших пользоваться.

3. Посчитайте пользователей, а не события

Ниже условная группа, для которой полностью завершён период наблюдения. Все строки относятся к одним и тем же пользователям.

Активация = 863 ÷ 2 137 × 100% = 40,38%.

Переход от создания задачи к выполнению составляет 57,96%. Это полезный дополнительный показатель, но у него другой знаменатель. Нельзя подменять им активацию от регистрации.

Остальные 1 274 пользователя не выполнили правило в выбранный срок. Это не означает, что они никогда не получат пользу: часть может активироваться позднее. Покажите отдельно более поздние результаты, сохранив исходное определение основной метрики.

Время до активации тоже важно

Его можно считать от регистрации до первого подходящего выполнения. Но медиана только среди активировавшихся не рассказывает об остальных. Она может уменьшиться, если медленные пользователи перестали доходить до результата. Поэтому смотрите время вместе с долей активации и распределением сроков.

4. Проверьте связь с дальнейшим использованием

Разделим ту же группу на активировавшихся за первые 168 часов и остальных. Для обеих групп измерим дальнейший результат в одинаковом, более позднем окне: от 168 до 336 часов после регистрации. Возвратом здесь назовём выполнение собственной задачи, созданной уже в этом втором окне. Каждый пользователь учитывается один раз.

Так мы отделяем ранний признак от последующего поведения. Для этой проверки у всех участников должно пройти уже 14 суток, а не только семь.

Различие заметно, но это связь, а не доказательство причинности. Более мотивированные люди могли и раньше выполнить первую задачу, и чаще продолжать пользоваться приложением.

Сравните результат по источникам привлечения, устройствам и пользовательским сценариям. Проверьте определение на следующей группе регистраций. Если перебирали много действий и сроков, не оценивайте выбранный вариант только на тех данных, по которым его нашли.

Особенно опасно определять активацию по действиям за целый месяц и теми же действиями объяснять удержание внутри этого месяца. Тогда информация о будущем уже участвует в разделении пользователей.

5. Улучшайте путь к пользе, а не только показатель

Если люди создают задачу, но не завершают её, сначала выясните почему. Возможно, задача крупная и требует времени. Возможно, непонятно, как отметить результат. А возможно, человек уже выполнил дело и не видит причины возвращаться ради галочки.

Автоматическое выполнение демонстрационной задачи повысит число событий, но не решит эти проблемы. Изменение должно помогать реальному сценарию.

Для проверки нового знакомства с продуктом можно провести эксперимент с распределением новых пользователей до показа изменений. Сравнивайте все назначенные группы, а не только активировавшихся после изменения. Иначе результат эксперимента будет зависеть от отбора, на который само изменение уже повлияло.

Следите за ранней активацией, последующим использованием и признаками вреда: ошибками, навязчивыми подсказками, обращениями в поддержку. Критерии и длительность проверки согласуйте заранее.

6. Что проверить перед выводом

• Все участники получили одинаковое полное время наблюдения.
• Учебные задачи не смешались с самостоятельными действиями.
• Создание и выполнение связаны по одной задаче и происходят в правильном порядке.
• Повторные события не увеличивают число активированных людей.
• Смена устройства не создаёт нового пользователя в расчёте.
• Определение одинаково для сравниваемых периодов и вариантов продукта.
• Изменение доли не объясняется только новым источником трафика или ошибкой сбора.

В командном продукте дополнительно выберите единицу анализа. Регистрация сотрудника и первая успешно работающая команда — разные результаты. Не смешивайте пользователей и организации в одной дроби.

Следующая статья

Посмотрим, как пользователи проходят путь до результата.