НВ / analytics
CASE 04 / RETENTION И ПОВЕДЕНИЕ ПОЛЬЗОВАТЕЛЕЙУчебный кейс

Пользователей больше.
Удержание ниже.
Продукт стал хуже?

Почему люди возвращаются —
и почему иногда кажется,
что они перестали.

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

Вывод за минуту ↓Исследовать когорты ↗
01 / ЧТО НА САМОМ ДЕЛЕ ПРОИЗОШЛО

Люди возвращаются реже.
Но причина может быть
не в самом продукте.

39,11% → 32,15%Возврат на второй неделе · сравниваем группы с полным периодом наблюдения

Стало больше людей, пришедших из рекламы

Раньше из рекламы приходили 31,06% новых пользователей, теперь — 72,76%. В нашем примере эти люди возвращаются реже, чем пользователи из органического канала — пришедшие без платной рекламы. Когда доля такой аудитории увеличивается, общий показатель может снизиться. При этом, если рассмотреть каждый канал отдельно, доля вернувшихся в обоих случаях немного выросла.

Проверяем, из чего сложилось снижение

Изменение долей каналов даёт −9,13 процентного пункта. Улучшение показателя внутри каналов компенсирует часть этого снижения: +2,17 пункта. В сумме получается −6,96 пункта — разница между 39,11% и 32,15%. Так мы объясняем, как изменилось общее число. Но пока не доказываем, почему конкретные люди стали вести себя иначе.

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

02 / ДОГОВАРИВАЕМСЯ О МЕТРИКЕ

Что мы считаем
возвращением пользователя?

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

ПРОДУКТ

Личный планировщик

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

ВХОД В КОГОРТУ

Первая регистрация

Объединяем людей, впервые зарегистрировавшихся в одну неделю: с понедельника по воскресенье. Такая группа называется когортой. За каждым человеком закрепляем один идентификатор и источник, из которого он пришёл. Все даты считаем в одном часовом поясе — UTC.

ВОЗВРАТ

Хотя бы одна выполненная задача

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

Главный показатель: вернулся ли человек на второй неделе

День регистрации обозначаем D0, следующий календарный день — D1, и так далее. Для основного показателя берём дни с D7 по D13 включительно: это вторая неделя жизни пользователя в приложении, которую в таблице обозначаем W1. Например, у человека, зарегистрировавшегося 3 августа, проверяем выполненные задачи с 10 по 16 августа. У зарегистрировавшегося 6 августа — с 13 по 19 августа.

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

Почему точный D7, недельный W1 и «вернулся позже» дают разные числа

D7: есть действие именно в календарный день 7. Подходит для вопроса о конкретном дне, но чувствителен к ритму использования.

W1: есть действие в D7–D13. Более широкое окно; W1 не может быть ниже D7 на одной и той же зрелой аудитории.

R7–34: есть действие в D7–D34. Это ограниченный горизонт «на седьмой день или позже». Мы специально фиксируем конец на D34, чтобы у всех было одинаковое время для возврата. Это не бессрочный rolling retention.

Пользователь с действиями на D2, D9 и D31: D7 = нет, W1 = да, W4 = да, R7–34 = да. Частое открытие приложения без выполненных задач не засчитывается в основной метрике.

03 / КОГОРТНАЯ ЛАБОРАТОРИЯ

Человек ещё не успел вернуться.
Не спешите считать его ушедшим.

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

Загрузка модельных данных…
Группы по неделе регистрации · доля вернувшихся и число людей: вернулись / зарегистрировались
Начало неделиПользователиD7W1W2W4R7–34

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

Почему нельзя просто соединить итоги столбцов линией

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

04 / РАЗБИРАЕМ ПАДЕНИЕ

Общий показатель снизился.
Но в каждом канале он вырос.

Сравним две группы периодов: зарегистрировавшихся 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 внутри каналов — наблюдение в синтетической выборке. Причинность, значимость и устойчивость роста здесь не доказаны. Сегментация по двум каналам не контролирует все различия людей, кампаний и сезонов.

05 / ЧТО СКРЫВАЕТ ВОЗВРАТ

Продолжил пользоваться,
вернулся после паузы
или только начал?

Возьмём одних и тех же 2 521 человека из базовых групп. Посмотрим, кто выполнял задачи на второй неделе (W1, дни 7–13), а кто — на третьей (W2, дни 14–20). Эти периоды уже полностью прошли. Разделим людей на пять групп без пересечений.

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

Почему это меняет решение

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

06 / ТО, ЧТО ЧАСТО ПРОПУСКАЮТ

Что легко упустить —
и как это меняет вывод

01 / ВРЕМЯ

Полночь не равна 24 часам

Регистрация в 23:57 и действие в 00:11 следующего дня дадут календарный D1 через 14 минут. В окне 24–48 часов это ещё D0. Зафиксируйте часовой пояс и тип окон до сравнения инструментов. Для timestamp сначала выполните перевод в выбранную зону, затем выделяйте дату.

02 / ЗРЕЛОСТЬ

Дозреть должен последний участник

У недельной когорты разные даты регистрации. Чтобы целиком оценить W4, наблюдаем последнего зарегистрированного до конца его D34. Дата начала когорты + 34 дня не подходит. «Сегодня» не включаем как полный день.

03 / ЗНАМЕНАТЕЛЬ

Не исключайте тех, кто так и не начал

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

04 / ВЕСА

Не усредняйте проценты без учёта размера групп

Объединённый retention = сумма вернувшихся / сумма участников зрелых когорт. Среднее строк отвечает другому вопросу — о средней когорте. Равные веса могут быть намеренным выбором, но его нельзя выдавать за долю всех пользователей.

05 / ИДЕНТИЧНОСТЬ

Переустановка не должна рождать нового человека

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

06 / СОБЫТИЕ

Автоматическое событие создаёт ложную привычку

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

07 / АТРИБУЦИЯ

Канал после возврата создаёт круговую логику

Если переназначать канал по последнему визиту, email-пользователи уже отобраны фактом возвращения. В кейсе канал фиксируется при регистрации. Для оценки влияния рассылки нужен эксперимент, а не сравнение получателей, которые открыли письмо, с остальными.

08 / АКТИВАЦИЯ

«Создал три задачи» ещё не причина удержания

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

09 / РИТМ

Ежедневный retention подходит не каждому продукту

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

10 / СРЕЗ

Действие произошло вчера, а данные пришли сегодня

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

11 / НЕОПРЕДЕЛЁННОСТЬ

Небольшая разница может оказаться случайной

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

12 / ПРИЧИННОСТЬ

До и после релиза — разные люди и календарь

Сезон, страна, устройство, цена, кампания и естественная частота задач могут менять retention одновременно с релизом. Декомпозиция локализует изменение, но не заменяет эксперимент. Постоянно ищущий «лучший» сегмент анализ особенно легко превращает случайность в историю.

07 / ПЛАН ДЕЙСТВИЙ

Как превратить разбор
в понятный план работы

ШагЧто делаемКакой результат нужен
Проверить измерениеЗафиксировать события, ID, UTC-окна, зрелость и доставку; пересчитать по журналуОдинаковые правила в SQL и продуктовом отчёте
Разобрать привлечениеДетализировать платный канал по кампании и намерению, соединить с затратамиСтоимость пользователя, достигшего ценности; экономика зрелых когорт
Найти ранние барьерыВремя до первой задачи, трудности онбординга, качественные интервьюПроверяемая гипотеза, а не выбранный постфактум «магический» порог
Спроектировать экспериментРандомизация при регистрации; основная W1 от всех назначенных; заранее заданные мощность и горизонтПричинная оценка изменения онбординга после дозревания всех наблюдений
Проверить устойчивостьW4, качество выполненных задач, отписки и частота нежелательных уведомленийРост регулярной ценности без давления на пользователей

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

08 / ДАННЫЕ И ВОСПРОИЗВОДИМОСТЬ

От строки события
до управленческого вывода

Паспорт данных и честные ограничения

13 317 пользователей, восемь недель регистрации с 3 августа по 27 сентября. 69 653 строки активности типа user × date × event_type. Это уникальные активные дни, а не полный поток событий. Количество выполненных задач из этой проекции восстановить нельзя.

Все данные сгенерированы, seed 739127. Внутри каналов намеренно задан рост W1 и рост доли платного привлечения — это демонстрация парадокса состава, не найденный факт о реальной компании. Для остальных окон активность синтезируется отдельно; модель не претендует на реалистичную зависимость поведения между неделями.

Срез после полного 29 сентября 2026, UTC; будущих событий в выгрузке нет. days и opens — смещения календарных дат от регистрации. Тестовые и удалённые аккаунты, поздние события и реальные дефекты трекинга не моделируются. Экономика, выручка и причинный эффект отсутствуют.

Как устроен SQL и что проверить при переносе

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-часовые окна. Правила этой страницы заданы явно и не обещают совпадения с настройками вашего инструмента.