Активация растёт, удержание нет: как проверить выбранное событие

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

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

Заморозьте раннее определение

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

Статус фиксируется по окончании седьмых суток. Если отчёт появился на двенадцатые, это полезное позднее действие, но оно не меняет раннюю группу задним числом. Иначе пользователи получают разные сроки на попадание в категорию, которую вы называете ранней.

Отдельно задайте возврат: например, успешная работа с собственным отчётом на восьмой–четырнадцатый день от старта. Логин и просмотр экрана ошибки не заменяют этот исход. День и часовой пояс должны быть одинаковыми для обеих групп. В этом примере считаем полные сутки от времени старта: раннее окно — от старта включительно до +7 суток исключительно, возврат — от +7 включительно до +14 суток исключительно. Событие точно на границе +7 относится уже к окну возврата.

Матрица двух зрелых групп

Условный пример: 200 пространств одной недели старта; каждое наблюдалось четырнадцать полных суток. Критерии и продукт в примере не менялись. Результат считается один раз на пространство.

48 / 80 = 60%, 36 / 120 = 30%, общий возврат — 84 / 200 = 42%. Разница равна 30 процентным пунктам. Это связь внутри условной когорты. Более мотивированные или лучше подготовленные команды могли и раньше активироваться, и чаще возвращаться.

Amplitude позволяет сравнивать поведенческие когорты. При этом настройки инструмента нужно сопоставить с собственным протоколом. В описании времени retention различаются скользящие 24-часовые окна и календарные дни: выбор влияет на расчёт. Не называйте их взаимозаменяемыми.

Где будущее попадает в прошлое

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

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

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

Почему агрегат может обмануть

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

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

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

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