Личный планировщик
Для этого приложения полезное действие — выполнить намеченную задачу. Человек может открыть приложение, посмотреть на список и сразу закрыть его. Такой визит мы увидим, но по нему ещё нельзя сказать, что продукт помог человеку.
Представим приложение, в котором люди планируют дела и отмечают выполненные задачи. Новых пользователей становится больше, но доля тех, кто продолжает пользоваться приложением, снижается. Разберёмся, означает ли это проблему с продуктом — или изменилось что-то другое.
Вывод за минуту ↓Исследовать когорты ↗Раньше из рекламы приходили 31,06% новых пользователей, теперь — 72,76%. В нашем примере эти люди возвращаются реже, чем пользователи из органического канала — пришедшие без платной рекламы. Когда доля такой аудитории увеличивается, общий показатель может снизиться. При этом, если рассмотреть каждый канал отдельно, доля вернувшихся в обоих случаях немного выросла.
Изменение долей каналов даёт −9,13 процентного пункта. Улучшение показателя внутри каналов компенсирует часть этого снижения: +2,17 пункта. В сумме получается −6,96 пункта — разница между 39,11% и 32,15%. Так мы объясняем, как изменилось общее число. Но пока не доказываем, почему конкретные люди стали вести себя иначе.
Что делать команде: не отменять изменения в продукте только из-за общего показателя. Сначала разобраться, каких людей приводит реклама, сколько стоит их привлечение и что мешает им получить пользу от приложения. Затем проверить конкретные гипотезы.
Удержание, или retention, показывает, какая доля людей продолжает пользоваться продуктом спустя некоторое время. Но сначала нужно договориться, кого сравниваем, какое действие считаем полезным и сколько времени даём человеку на возвращение.
Для этого приложения полезное действие — выполнить намеченную задачу. Человек может открыть приложение, посмотреть на список и сразу закрыть его. Такой визит мы увидим, но по нему ещё нельзя сказать, что продукт помог человеку.
Объединяем людей, впервые зарегистрировавшихся в одну неделю: с понедельника по воскресенье. Такая группа называется когортой. За каждым человеком закрепляем один идентификатор и источник, из которого он пришёл. Все даты считаем в одном часовом поясе — UTC.
Засчитываем человека, если он отметил хотя бы одну выполненную задачу в выбранный период. В данных это действие называется task_completed. Если он выполнил несколько задач, всё равно считаем его один раз. Делим число таких людей на всех зарегистрированных в группе — в том числе на тех, кто так и не начал пользоваться приложением.
День регистрации обозначаем D0, следующий календарный день — D1, и так далее. Для основного показателя берём дни с D7 по D13 включительно: это вторая неделя жизни пользователя в приложении, которую в таблице обозначаем W1. Например, у человека, зарегистрировавшегося 3 августа, проверяем выполненные задачи с 10 по 16 августа. У зарегистрировавшегося 6 августа — с 13 по 19 августа.
Есть важная тонкость: человек может впервые выполнить задачу только на девятый день и тоже попасть в этот показатель. Поэтому наш расчёт говорит об использовании приложения после регистрации, но не обязательно о сформировавшейся привычке. Ниже отдельно посмотрим на тех, кто начал получать пользу с задержкой.
D7: есть действие именно в календарный день 7. Подходит для вопроса о конкретном дне, но чувствителен к ритму использования.
W1: есть действие в D7–D13. Более широкое окно; W1 не может быть ниже D7 на одной и той же зрелой аудитории.
R7–34: есть действие в D7–D34. Это ограниченный горизонт «на седьмой день или позже». Мы специально фиксируем конец на D34, чтобы у всех было одинаковое время для возврата. Это не бессрочный rolling retention.
Пользователь с действиями на D2, D9 и D31: D7 = нет, W1 = да, W4 = да, R7–34 = да. Частое открытие приложения без выполненных задач не засчитывается в основной метрике.
Выберите, какое действие считать возвращением и каких пользователей посмотреть. Затем включите режим с ошибкой. Вы увидите, что происходит, если оценивать недавних пользователей, хотя у них ещё не закончился весь срок для возвращения.
| Начало недели | Пользователи | D7 | W1 | W2 | W4 | R7–34 |
|---|
Серая клетка означает, что хотя бы у одного человека в группе ещё не закончился период наблюдения. Например, невозможно оценить возврат на четвёртой неделе, если после регистрации прошло лишь несколько дней. В этом кейсе такую группу целиком не включаем в итог выбранного показателя. Можно считать только тех, кто уже прожил нужный срок, но тогда важно явно показать, что состав группы изменился.
Для короткого периода уже достаточно данных о многих группах, а для длинного — только о самых ранних. Поэтому итог D7 и итог W4 могут описывать разных людей. Если хотите показать, как удержание одной аудитории меняется со временем, возьмите только те группы, за которыми успели наблюдать весь самый длинный период.
Сравним две группы периодов: зарегистрировавшихся 3–16 августа и зарегистрировавшихся 31 августа–13 сентября. У всех этих людей уже закончилась вторая неделя после регистрации, поэтому условия наблюдения сопоставимы. Две промежуточные недели остаются в общей таблице, но в это конкретное сравнение не входят.
| Канал | База: вернулись / вошли | Новые когорты | Изменение W1 |
|---|
Общий retention — сумма долей каналов × их retention. В первом шаге заменяем доли каналов на новые, сохраняя базовые удержания: получаем 29,98%. Разница с базовыми 39,11% — вклад состава −9,13 п. п.
Во втором шаге подставляем новые удержания при новых долях: 32,15% − 29,98% = +2,17 п. п. Сумма вкладов равна общему изменению. Порядок замены влияет на распределение вкладов.
Другой вопрос: каким был бы retention новых когорт при базовых долях каналов? Получаем 41,63%. Это стандартизованная описательная оценка, не прогноз и не результат эксперимента. Знаменатель здесь условный, а не новая наблюдаемая когорта.
В новых группах вернулись 1 178 человек, в базовых — 986. То есть людей, получивших пользу на второй неделе, стало больше, хотя их доля снизилась. Чтобы решить, стоит ли продолжать рекламу, нужны расходы на привлечение и доход от этих пользователей. Одного показателя удержания для этого недостаточно.
Более высокий retention внутри каналов — наблюдение в синтетической выборке. Причинность, значимость и устойчивость роста здесь не доказаны. Сегментация по двум каналам не контролирует все различия людей, кампаний и сезонов.
Возьмём одних и тех же 2 521 человека из базовых групп. Посмотрим, кто выполнял задачи на второй неделе (W1, дни 7–13), а кто — на третьей (W2, дни 14–20). Эти периоды уже полностью прошли. Разделим людей на пять групп без пересечений.
Вернувшимся после паузы здесь считаем того, кто выполнял задачи в первую неделю, не делал этого во вторую, а в третью снова начал. Обычно это называют реактивацией. Пропуск одной недели не означает, что человек ушёл навсегда. И наоборот: одно действие в каждой из двух недель ещё не доказывает ежедневную привычку.
Если растёт реактивация, исследуем повторный вход и коммуникации. Если много поздних первых действий — онбординг и время до ценности. Если падает переход из активных W1 в активных W2 — регулярный сценарий использования. Суммарный W2 не различает эти задачи.
Регистрация в 23:57 и действие в 00:11 следующего дня дадут календарный D1 через 14 минут. В окне 24–48 часов это ещё D0. Зафиксируйте часовой пояс и тип окон до сравнения инструментов. Для timestamp сначала выполните перевод в выбранную зону, затем выделяйте дату.
У недельной когорты разные даты регистрации. Чтобы целиком оценить W4, наблюдаем последнего зарегистрированного до конца его D34. Дата начала когорты + 34 дня не подходит. «Сегодня» не включаем как полный день.
Если незаметно убрать неактивированных, показатель вырастет. Retention от регистрации и retention от первой ценности отвечают на разные вопросы. В знаменателе метрики от первой ценности остаются только достигшие её; потеря на пути к ней требует отдельной метрики.
Объединённый retention = сумма вернувшихся / сумма участников зрелых когорт. Среднее строк отвечает другому вопросу — о средней когорте. Равные веса могут быть намеренным выбором, но его нельзя выдавать за долю всех пользователей.
Anonymous ID, вход с другого устройства, объединение аккаунтов и общий рабочий аккаунт меняют числитель и знаменатель. Нужны правила склейки, дедупликации и исключения тестовых пользователей. В модели ID уже чистые; реальная проверка не выполнена.
Фоновый запуск, автосохранение или открытый экран могут выглядеть как активность. Возврат должен соответствовать ценности продукта. После смены схемы событий проверяйте сопоставимость, версии клиентов и полноту доставки.
Если переназначать канал по последнему визиту, email-пользователи уже отобраны фактом возвращения. В кейсе канал фиксируется при регистрации. Для оценки влияния рассылки нужен эксперимент, а не сравнение получателей, которые открыли письмо, с остальными.
Мотивированные люди чаще и активируются, и возвращаются. Если искать активацию на всём будущем горизонте, появляется утечка будущего и смещение выживших. Зафиксируйте раннее окно, например D0–D2, затем исследуйте последующий исход; для причинного вывода рандомизируйте вмешательство.
Покупка кровли и ежедневный планировщик имеют разную частоту потребности. Выбирайте окно по сценарию использования. Даже анализ интервалов между действиями отбирает тех, кто уже вернулся хотя бы дважды, и не описывает всех новичков.
Пользователь мог выполнить задачу вчера, а информация об этом попала в отчёт сегодня — например, после восстановления интернета. Учитывайте дату самого действия и договоритесь, сколько ждёте запоздавшие данные перед финальным расчётом. Сохраняйте дату формирования отчёта. Если часть событий потерялась, это ещё не значит, что пользователи не возвращались. В учебном примере задержек и потерь нет.
Рядом с процентом показывайте, сколько людей вошло в расчёт и сколько вернулось. Чем меньше группа, тем сильнее случайные колебания. В реальном анализе оцените диапазон неопределённости показателя и разницы между группами. Если изучать десятки сегментов, некоторые «улучшения» найдутся случайно — это тоже нужно учитывать. В этом учебном кейсе мы объясняем состав показателя, но не утверждаем, что изменения статистически надёжны.
Сезон, страна, устройство, цена, кампания и естественная частота задач могут менять retention одновременно с релизом. Декомпозиция локализует изменение, но не заменяет эксперимент. Постоянно ищущий «лучший» сегмент анализ особенно легко превращает случайность в историю.
| Шаг | Что делаем | Какой результат нужен |
|---|---|---|
| Проверить измерение | Зафиксировать события, ID, UTC-окна, зрелость и доставку; пересчитать по журналу | Одинаковые правила в SQL и продуктовом отчёте |
| Разобрать привлечение | Детализировать платный канал по кампании и намерению, соединить с затратами | Стоимость пользователя, достигшего ценности; экономика зрелых когорт |
| Найти ранние барьеры | Время до первой задачи, трудности онбординга, качественные интервью | Проверяемая гипотеза, а не выбранный постфактум «магический» порог |
| Спроектировать эксперимент | Рандомизация при регистрации; основная W1 от всех назначенных; заранее заданные мощность и горизонт | Причинная оценка изменения онбординга после дозревания всех наблюдений |
| Проверить устойчивость | W4, качество выполненных задач, отписки и частота нежелательных уведомлений | Рост регулярной ценности без давления на пользователей |
Если проверяем изменение экспериментом, важно дать каждому участнику одинаковое время. Недостаточно закончить тест через 13 дней после прихода первого человека: нужно дождаться тринадцатого дня после регистрации последнего. Какие показатели считаем главными и по каким правилам принимаем решение, договариваемся до запуска.
13 317 пользователей, восемь недель регистрации с 3 августа по 27 сентября. 69 653 строки активности типа user × date × event_type. Это уникальные активные дни, а не полный поток событий. Количество выполненных задач из этой проекции восстановить нельзя.
Все данные сгенерированы, seed 739127. Внутри каналов намеренно задан рост W1 и рост доли платного привлечения — это демонстрация парадокса состава, не найденный факт о реальной компании. Для остальных окон активность синтезируется отдельно; модель не претендует на реалистичную зависимость поведения между неделями.
Срез после полного 29 сентября 2026, UTC; будущих событий в выгрузке нет. days и opens — смещения календарных дат от регистрации. Тестовые и удалённые аккаунты, поздние события и реальные дефекты трекинга не моделируются. Экономика, выручка и причинный эффект отсутствуют.
users.csv загружается в users, activity.csv — в activity. SQL использует даты UTC; для реальных timestamptz сначала нормализуйте зону. Возврат проверяется через EXISTS, поэтому несколько событий одного пользователя не раздувают числитель.
Зрелость проверяется по максимальной дате регистрации в полной когорте. Последний день окна включён. Итог — отношение сумм только зрелых когорт; пустые окна остаются NULL. Данные начинаются с полного доступного журнала регистраций: в реальной базе не ищите «первую регистрацию» после предварительного ограничения событий датой отчёта.
Для воспроизведения положите data.json, analysis.mjs и verify.mjs рядом; выполните node verify.mjs (Node.js 18+). Генератор восстанавливает JSON и оба CSV.
Определения и особенности инструментов: Amplitude: расчёт и неполные периоды · календарное время и 24-часовые окна. Правила этой страницы заданы явно и не обещают совпадения с настройками вашего инструмента.