Retention по когортам и каналам: как считать D1, D7 и D30

Коротко

Retention показывает, какая доля пользователей вернулась в продукт после первого значимого действия. Это не просто «сколько людей осталось», а проверка продуктовой привычки, качества активации и качества привлечения.

• Сначала зафиксируйте стартовое событие: регистрация, первая покупка, первая сессия или первая активация.
• Потом выберите return event: действие, которое правда означает возвращение к ценности.
• Смотрите retention по когортам, а не только одним средним числом.
• Не сравнивайте D7 у когорт, которым ещё не исполнилось семь дней.
• Обязательно дели retention по каналам, платформам и ключевым сегментам.

Что такое retention

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

Здесь важны две границы. Первая — кто попадает в когорту. Вторая — что считается возвращением. Если в когорту попали все регистрации, а return event — любое открытие приложения, метрика будет отвечать на один вопрос. Если в когорту попали активированные пользователи, а return event — повторное core action, это уже совсем другой вопрос.

Что считать возвращением

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

Рабочее определение зависит от продукта. Для игры возвращение — новая сессия или значимый игровой шаг. Для SaaS — повторное выполнение рабочего сценария. Для маркетплейса — поиск, просмотр товара, сообщение продавцу или заказ. Для BI-сервиса — открытый дашборд, запущенный запрос или отправленный отчёт.

D1, D7 и D30 не отвечают на один вопрос

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

Из-за этого нельзя чинить D30 теми же действиями, которыми чинят D1. Если падает D1, смотрите onboarding, первый сценарий, скорость до ценности и ошибки в первые минуты. Если D7 в порядке, а D30 слабый, проблема может быть в глубине продукта, повторной мотивации, контенте, ассортименте или регулярной пользе.

Когортная таблица показывает форму проблемы

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

Читать её нужно по строкам и столбцам. Строка отвечает за когорту: например, неделя регистрации и канал. Столбец отвечает за возраст пользователя: D1, D3, D7, D14, D30. Если вся новая строка светлее старых, проблема появилась в конкретной когорте. Если светлеет только D7+, пользователи проходят первый опыт, но не формируют повторный сценарий.

Диагональ тепловой карты — это календарь, а не возраст когорты

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

В карте ниже когорты дневные, пять подряд. Найдите пять ячеек, которые выпадают из своих столбцов: 11% на D5 у когорты 10 июня, 12% на D4 у 11 июня, 13% на D3 у 12 июня, 16% на D2 у 13 июня, 21% на D1 у 14 июня. Сложите дату и возраст: 10 + 5, 11 + 4, 12 + 3, 13 + 2, 14 + 1 — каждый раз 15 июня. В продукте не сломался ни onboarding, ни второй визит: 15 июня приложение полдня не пускало пользователей по сохранённой сессии.

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

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

Вторая причина, по которой полосу не видно, — цветовая шкала. Квантильная раскраска растягивает контраст по распределению значений, поэтому 21% и 22% в одном столбце получают заметно разные оттенки, а настоящая просадка вдвое теряется среди этого шума. Для поиска формы нужна линейная шкала от нуля, с подписанными границами, и возможность переключиться на числа. Цвет отвечает на вопрос «где смотреть», решение принимается по числам и размеру когорты.

И последнее про последнюю строку. Дневная когорта в 1 220 человек даёт на D1 погрешность около ±1,2 п.п. — то есть 21% против 44% здесь сигнал, а разница 43% и 45% между соседними строками не значит ничего. Бледность свежей строки часто объясняется не поведением, а тем, что её правые ячейки ещё не дозрели; про это отдельный разговор ниже.

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

Почему общий retention опасен

Retention редко падает равномерно. В большинстве рабочих кейсов есть источник, сегмент или платформа, где проблема появилась раньше остальных. Если один канал резко вырос по объёму и при этом приводит слабую аудиторию, общий D7 может просесть даже без изменений в продукте. Команда начинает чинить onboarding, хотя настоящая проблема сидит в закупке.

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

SQL для D1, D7 и D30 по каналам

Запрос написан для учебной базы симулятора SQL-аналитика: users содержит дату регистрации и канал, events — события поведения, возвращением считается app_open, единственное действие, которое в этой базе повторяется. В расчёт попадают только зрелые когорты — зарегистрированные по 30 июля: у них тридцатый день наступил не позже 29 августа, последнего полного дня событий (в рабочем запросе на месте этой даты — вчерашний день). Это защищает отчёт от частой ошибки, когда свежие когорты выглядят хуже просто потому, что им ещё не исполнилось 30 дней.

В примере используется календарный день: D7 означает активность на седьмой календарный день после регистрации. Для продуктов, где важны точные 24-часовые окна, логику нужно менять на rolling interval. Когорты месячные: недельные по каналам в этой базе чаще меньше порога в 100 человек.

Результат — семь строк. У июльской когорты (регистрации 1–30 июля) D1 равен 65,6% у рекомендаций, 60,8% у органики, 42,5% у партнёров и 34,3% у платного поиска; D7 — 24,1, 23,2, 17,2 и 11,5%; D30 — 11,2, 9,8, 8,6 и 7,2%. Разрыв между органикой и платным поиском на D1 и D7 — 26,5 и 11,7 п.п. при когортах в 564 и 469 человек — намного больше шума. На D30 за процентами стоят 20–55 вернувшихся, и соседние каналы там неразличимы. Платный поиск запущен 1 июля, в июне его строки нет, поэтому каналы честно сравнивать только внутри июля. Как те же каналы различаются по первой оплате и выручке на пользователя, показано в анализе рекламного канала от воронки до выручки.

with cohorts as (
  select
    user_id,
    channel,
    signup_date,
    cast(date_trunc('month', signup_date) as date) as cohort_month
  from users
  where signup_date + 30 <= date '2026-08-29'   -- D30 наступил к последнему полному дню
),
activity as (
  select distinct
    user_id,
    cast(event_time as date) as active_day
  from events
  where event_name = 'app_open'
)
select
  c.cohort_month,
  c.channel,
  count(distinct c.user_id) as cohort_size,
  round(
    100.0 * count(distinct c.user_id) filter (where a.active_day = c.signup_date + 1)
    / count(distinct c.user_id),
    1
  ) as d1_retention_pct,
  round(
    100.0 * count(distinct c.user_id) filter (where a.active_day = c.signup_date + 7)
    / count(distinct c.user_id),
    1
  ) as d7_retention_pct,
  round(
    100.0 * count(distinct c.user_id) filter (where a.active_day = c.signup_date + 30)
    / count(distinct c.user_id),
    1
  ) as d30_retention_pct
from cohorts c
left join activity a on a.user_id = c.user_id
group by c.cohort_month, c.channel
having count(distinct c.user_id) >= 100
order by c.cohort_month, c.channel;

Где retention начинает врать

Retention выглядит строгой метрикой, но у него много бытовых ловушек. Самая частая — сравнить когорты разного возраста. Вторая — считать возвращением событие, которое не связано с ценностью. Третья — смотреть только процент и забыть про размер когорты: 40% из 50 пользователей и 12% из 50 000 требуют разного разговора.

Есть и менее очевидная ошибка: считать retention только по всем новым пользователям. Иногда продуктовая проблема находится не в новичках, а в текущей базе. Для зрелых продуктов полезно отдельно смотреть new user retention, current user retention и resurrected users: кто впервые пришёл, кто уже был активен, кто вернулся после паузы.

• Не смешивайте календарный и rolling retention в одном отчёте.
• Не сравнивайте D7 у когорт, которым меньше семи дней.
• Не считайте push_open или login достаточным возвращением без проверки core action.
• Не делайте вывод по проценту без размера когорты.
• Не забывайте сегменты: канал, платформа, страна, тариф, lifecycle stage.

Как сформулировать продуктовый вывод

Слабый вывод звучит так: «D7 retention упал, нужно улучшать продукт». Он не говорит, где проблема, кого она затронула и что делать завтра. Сильный вывод связывает метрику, сегмент, период и вероятную причину.

Например, на условных числах: «В июле общий D7 снизился с 18% до 14%. В органике D7 остался около 21%, а падение пришло из paid social: канал вырос в объёме в 2,1 раза, но его D7 просел до 8%. Продуктовая проблема в первом опыте не подтверждается без отдельного сигнала в органике; следующий шаг — разобрать кампании, креативы и соответствие обещания лендинга реальному onboarding».

• Назовите горизонт: D1, D7, D30 или другой.
• Покажите, какие когорты сравниваются и дозрели ли они.
• Разложите изменение на канал, платформу или сегмент.
• Проверьте соседние метрики: activation, DAU/MAU, revenue, conversion.
• Отделите продуктовую гипотезу от гипотезы про качество трафика.

Три режима retention, которые нельзя смешивать

Классический N-day retention отвечает на вопрос: какая доля когорты была активна ровно на N-й день после старта? Он удобен для D1, D7 и D30, но чувствителен к тому, попал ли пользователь в конкретную дату. Unbounded retention спрашивает, возвращался ли пользователь в любой день начиная с N-го. Он лучше показывает, не потеряли ли мы аудиторию совсем, но обычно выше классического. Rolling retention фиксирует последний день активности и полезен для продуктов, где возврат может быть нерегулярным.

В отчёте всегда подписывайте режим расчёта. Фраза «D30 retention = 22%» без уточнения может описывать три разные кривые. Для ежедневной игры классический D7 может быть естественным. Для B2B-инструмента, которым пользуются раз в неделю, лучше заранее договориться о weekly retention или о возвращении в течение окна. Сравнивать проценты можно только при одинаковом определении.

Bounded и unbounded D7 на одной когорте: 37,5% и 62,5%

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

Bounded D7 спрашивает про седьмой день: активны ровно на нём u1, u2 и u5, то есть 3 из 8 — 37,5%. Unbounded D7 спрашивает про седьмой день или любой следующий: добавляются u3, который пришёл на девятый и двадцать первый, и u6 со своим недельным ритмом на 12–14 днях. Выходит 5 из 8 — 62,5%. Те же люди, то же событие возврата, одна когорта, разница почти вдвое. Если в двух отчётах стоит «D7 retention» без уточнения режима, спор о причинах расхождения будет спором ни о чём.

У двух определений разная форма кривой, и это не артефакт маленькой выборки. Unbounded по построению не может расти с возрастом: множество «вернулся на 12-й день или позже» вложено в «вернулся на 7-й или позже». Bounded расти может. На графике ниже он падает до 12,5% на D12 и поднимается до 25% на D14 — потому что u6 заходит раз в неделю и на двенадцатый день просто не его смена. Горб на bounded-кривой не означает ошибку в запросе; он означает, что у продукта есть ритм, и точечный срез по одному дню этот ритм ловит.

У unbounded есть своя плата: число зависит от даты отчёта. Посчитайте ту же когорту, оборвав наблюдение на десятом дне: u6, который вернётся на двенадцатый, ещё не вернулся, и unbounded D7 падает с 62,5% до 50%. Поведение когорты при этом не менялось — изменилось только то, сколько мы успели посмотреть. Поэтому unbounded-проценты сравнимы между когортами лишь при одинаковом окне наблюдения, а в подписи к графику обязана стоять его длина: «D7+, окно 30 дней».

Маленькая когорта показывает и третью вещь — насколько тощим может быть числитель. u5 был активен один раз, ровно на седьмой день, и он составляет треть всего bounded D7. u4 выгорел к пятому дню, но в bounded D1 он честно попал и выглядит там как удержанный пользователь. Процент не отличает человека, который пользуется продуктом, от человека, который однажды попал в нужную дату: для этого рядом нужно число активных дней или частота.

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

Зрелость когорты важнее красивой тепловой карты

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

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

• D7 показывайте только для когорт, которым исполнилось семь дней.
• Не превращайте «ещё не наблюдали» в ноль.
• Фиксируйте когорту по одному стартовому событию.
• Показывайте cohort size рядом с процентом.
• Сравнивайте сегменты на одинаковом горизонте и режиме расчёта.

От кривой retention к проверяемой гипотезе

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

Хорошая практика — заранее сопоставить каждый участок кривой с действием команды. D1 отвечает за первый результат, D7 — за повторную ценность, D30 — за устойчивость привычки или жизненного цикла. Это не универсальная трактовка, но она помогает перевести график из отчёта в список проверок.

Churn не равен 1 − retention, и разница — это пауза

Соблазн посчитать отток вычитанием возникает у каждого, кто уже собрал когортную таблицу. В условной тепловой карте выше у органики июня D30 = 12%, значит отток 88% — и дальше это число уходит в презентацию. Но 88% отвечает на вопрос «кого не было ровно на тридцатый день», а не «кто ушёл». Из 3 420 человек той когорты на тридцатый день активны 410, а хотя бы раз на тридцатый день или позже возвращались 925, то есть 27%. Значит, не вернулись 2 495 человек — 73%, а не 88%. Разница в 515 человек — это не ушедшие, а те, у кого тридцатый день просто не совпал с их ритмом.

Дальше расхождение растёт, потому что у retention и у churn разные знаменатели. Retention считается по когорте и привязан к её возрасту. Отток в подписке считают по базе на начало периода: на 1 сентября платили 10 000, в течение месяца отменили 1 000 — monthly churn 10%. Поделите те же отмены на базу конца месяца вместе с новичками — 1 000 / 9 600 = 10,4%, и отчёт начнёт зависеть от темпа привлечения, а не от удержания. Знаменатель фиксируется до первого расчёта и не меняется между периодами.

Ещё одна арифметика, на которой часто спотыкаются: месячный отток не умножается на двенадцать. При 10% в месяц до конца года доживает 0,9 в двенадцатой степени — 28,2% базы, то есть годовой отток 71,8%, а не 120%. Числа больше ста процентов в отчёте об оттоке обычно означают именно это умножение.

В продукте без подписки отменять нечего, и активное состояние приходится задавать окном бездействия. Длину окна берут не из головы, а из ритма живых пользователей. Если медианный интервал между core action 6 дней, а девяностый процентиль 23 дня, то порог «28 дней без действия» отделяет настоящий уход, а порог «7 дней» объявит ушедшими 38% нормально работающих людей — и отдел роста будет догонять письмами тех, кто и так вернётся в понедельник.

Отток полезно раскладывать по причине, иначе вывод уходит не в ту команду. Из тех же 1 000 отмен 280 — это отказ карты при списании, involuntary churn: лечится цепочкой повторных попыток и напоминанием об истечении срока карты, а не переделкой продукта. Остальные 720 — добровольный отток, и только он говорит о ценности. Смешанные в одном проценте, они дают ровную линию, по которой ничего нельзя решить.

Главное ограничение churn как метрики — он описывает прошлое и не оставляет пространства для действия. Между активным и ушедшим состоянием есть зона риска: 1 800 пользователей, у которых 14–28 дней без core action, падает частота, растут ошибки или не прошла первая ценность. Действовать можно здесь. И не забывайте, что состояние обратимо: около 12% ушедших возвращаются в следующем квартале, поэтому churn и retention не складываются в сто процентов — один человек может быть в сентябрьском оттоке и в ноябрьских активных одновременно.

• Не получай отток вычитанием retention: у них разные знаменатели и разные вопросы.
• Зафиксируйте базу начала периода и не пересчитывайте её задним числом.
• Разделите добровольный отток и отказ оплаты до первого вывода.
• Для продукта без подписки выберите окно по распределению интервалов, а не по удобству.
• Держите рядом зону риска: на ушедших уже нельзя повлиять, на неё — можно.

Частые вопросы

Что почитать дальше

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