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

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

Начните с цели пользователя

В работе Родден, Хатчинсона и Фу о системе HEART предлагается связывать цели пользовательского опыта с наблюдаемыми сигналами и метриками. Работа описывает подход к измерению, но не назначает универсальное событие активации для всех продуктов. Протокол ниже — практическое применение CRM Lab.

Сформулируйте завершённую задачу: «команда согласовала первый документ», «магазин получил пригодный для решения отчёт», «пользователь обработал свой файл». Затем найдите события, которые подтверждают результат. Нажатие кнопки «Создать отчёт» слабее, чем успешное построение отчёта на рабочих данных; даже второй вариант стоит проверить через наблюдение и разговоры с клиентами.

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

Разведите ранний сигнал и будущий результат

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

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

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

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

Сравнивайте кандидаты и простую базовую модель

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

Условный пример. Из 1 000 новых аккаунтов 300 выполнили кандидатное действие в первую неделю. Из них 180 сохранили регулярное использование, а среди остальных 700 — 140. Получается 60% против 20%. Связь сильная в этой выборке, но событие охватывает лишь 180 из 320 будущих устойчивых пользователей. Значит, оно не описывает единственный путь к успеху.

Проверьте второй кандидат и сравните, какую новую информацию он добавляет. Не перебирайте десятки событий до красивого результата на одной и той же истории. Выбор сделайте на ранних когортах, затем без подстройки оцените на последующих. При изменении продукта проверку повторите.

Не превращайте прогноз в обещание эффекта

Люди с сильной потребностью могут и быстрее активироваться, и дольше пользоваться продуктом. Поэтому принуждение остальных к тому же действию не обязательно улучшит удержание. Здесь полезно различать прогноз ухода и эффект воздействия: модель поведения отвечает на вопрос «что вероятно произойдёт», а эксперимент — «что изменит наша помощь».

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

Сохраните версию определения

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

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

Источники

Rodden K., Hutchinson H., Fu X. Measuring the User Experience on a Large Scale: User-Centered Metrics for Web Applications. Proceedings of CHI 2010. ACM Press, 2010.