Retention Rate: что это и как считать

Что означает Retention Rate

Retention Rate отвечает на простой вопрос: сколько людей из выбранной группы продолжили приносить продукту ценность после первого контакта. Если пользователь установил приложение и вернулся на следующий день, он попадает в Day 1 retention; если клиент купил снова через месяц, он попадает в месячное удержание.

Базовое значение метрики

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

Связь retention с churn

Retention rate и churn rate лучше смотреть вместе уже в начале диагностики. Retention показывает, какая часть исходной группы сохранилась или вернулась, а churn показывает, какая часть за тот же период ушла. Если база, период и объект совпадают, эти метрики помогают разложить один симптом на две стороны: где продукт удерживает людей и где он их теряет.

Бенчмарки и форма кривой

Рыночные ориентиры показывают, почему нельзя оценивать retention одним универсальным числом. Для мобильных приложений типичная кривая быстро падает после установки: около 26% пользователей возвращаются на Day 1, 13% - на Day 7, 10% - на Day 14 и около 7% - на Day 30. В программных продуктах картина обычно мягче: пользователь дольше принимает инструмент, а поздние интервалы сильнее зависят от рабочего цикла, команды и регулярности задачи.

Для мобильных приложений Adjust приводит ориентиры Day 1, Day 7, Day 14 и Day 30, которые помогают не путать нормальное падение ранней кривой с продуктовым провалом.

Форма кривой часто важнее одной точки. Резкое падение в первые 1-3 дня обычно указывает на проблему первого опыта: пользователь не понял ценность, не прошел регистрацию, не нашел нужное действие или пришел по обещанию, которое продукт не подтвердил. Плато через несколько недель показывает размер ядра аудитории - тех, для кого продукт стал повторяемой привычкой или рабочим инструментом. Если вы видите высокий Day 1 и слабый Day 30, основная гипотеза такая: первый интерес есть, устойчивого сценария нет. Если слабый уже Day 1, сначала проверяйте входной опыт и соответствие ожиданий.

Не называйте retention «лояльностью» без уточнения события. Лояльный клиент может редко заходить, но регулярно платить; активный пользователь может часто заходить и не покупать. Для отчета это разные диагнозы.

Стартовое событие, возвратное событие и когорта

Стартовое событие, возвратное событие и когорта задают смысл всей метрики. Если эти три элемента выбраны неаккуратно, Retention Rate превращается в красивый процент без диагностической силы.

Стартовое событие фиксирует точку отсчета

Стартовое событие - момент, с которого вы начинаете отсчет: первый визит, регистрация, установка, первая покупка, первый платеж или первое использование ключевой функции. В retention-отчете Mixpanel задаются два события: A criteria как стартовое событие, после которого пользователь попадает в когорту, и B criteria как возвратное событие, по которому он считается retained. Эта логика полезна и без Mixpanel: сначала вы определяете, кто входит в группу, затем проверяете, кто вернулся к нужному действию.

Возвратное событие показывает реальную ценность

Возвратное событие - действие, по которому пользователь считается вернувшимся. Для медиа достаточно повторного чтения, для сервиса доставки - повторного заказа, для B2B-продукта - рабочего действия внутри аккаунта. Когда возвратное событие слишком слабое, отчет завышает здоровье продукта. Когда событие слишком жесткое, он показывает только коммерческий слой и теряет ранние признаки интереса. Диагностический критерий здесь простой: если ваша команда спорит о значении retention, спросите не «какой процент правильный», а «кого мы считаем вернувшимся».

Когорта и окно расчета защищают от шума

Когорта пользователей - группа с общим стартовым признаком, например все, кто зарегистрировался в первую неделю мая или впервые купил после конкретной рекламной кампании. Ошибка настройки когорты часто выглядит невинно: для одной группы берут «первый визит», для другой - «первую покупку». В таком отчете retention смешивает качество трафика, входной опыт и готовность к покупке. Практический минимум для быстрых диагностик - держать размер когорты не ниже десятков пользователей, а для управленческих выводов - сотен пользователей; иначе 1-2 возврата меняют процент на несколько пунктов. При 20 пользователях один возврат - это уже 5 п.п., и такой скачок может быть шумом, а не изменением поведения.

Проверьте три базовых решения перед расчетом:

1. Зафиксируйте одно стартовое событие для всех сравниваемых групп.
2. Выберите возвратное событие, которое связано с реальной ценностью продукта.
3. Определите окно возврата: день, неделя, месяц или другой период.
4. Проверьте, что размер когорты достаточен для вывода.

Яндекс Реклама отмечает типовую ошибку когортного анализа: неверно выбрать период и целевое действие; для бизнеса с месячной подпиской релевантнее месячные когорты, а не дневные или недельные.

Формула Retention Rate

Формула Retention Rate считает долю удержанных пользователей от исходного размера когорты. Главный диагностический риск - случайно поставить в знаменатель всех активных пользователей за период и тем самым смешать удержание с новым притоком.

Базовая формула для когортного retention выглядит так: Retention Rate = количество пользователей из исходной когорты, совершивших возвратное событие в выбранное окно / количество пользователей в исходной когорте × 100. Знаменатель - это размер когорты на старте, например 1 000 пользователей, впервые установивших приложение 1 июня. Числитель - часть этих же 1 000 пользователей, которая вернулась на Day 7, Week 1 или Month 1. Новые пользователи, пришедшие позже, в эту дробь не входят. Если добавить их в знаменатель или числитель, расчет retention rate начнет отвечать на другой вопрос: насколько выросла активная база, а не насколько удержалась исходная группа.

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

1. Соберите исходную когорту по одному стартовому событию и одному периоду старта.
2. Посчитайте размер когорты до любых возвратных фильтров.
3. Найдите пользователей из этой же когорты, которые совершили возвратное событие в нужное окно.
4. Разделите число вернувшихся на исходный размер когорты и умножьте на 100.
5. Подпишите рядом тип окна: Day 7, Week 1, Month 1 или другой вариант.

Для клиентской базы часто используют Customer Retention Rate: ((клиенты на конец периода - новые клиенты за период) / клиенты на начало периода) × 100. В этой формуле «клиенты на конец периода» - все клиенты, оставшиеся к финальной дате; «новые клиенты за период» вычитаются, чтобы рекламный или органический приток не замаскировал потерю старой базы; «клиенты на начало периода» - исходная база, с которой сравнивают результат. В наших разборах платного трафика эта часть с вычитанием новых клиентов особенно важна: кампания может привести много новых лидов, но retention старой когорты при этом не улучшится.

Нельзя подставлять в знаменатель всех активных пользователей за период, если считается когортный retention: знаменатель должен быть исходным размером когорты, иначе новые пользователи размоют показатель. Простой пример: 1 000 пользователей зарегистрировались в понедельник, 120 из них вернулись через неделю. Day 7 retention равен 12%. Если за неделю пришли еще 2 000 новых пользователей и вы случайно делите 120 на 3 000, получится 4% - это уже не retention понедельничной когорты, а ошибка базы расчета.

Держите рядом с процентом абсолютные числа: 120 из 1 000 читается сильнее и честнее, чем просто 12%. Так вы сразу видите, где вывод устойчив, а где процент вырос из маленькой выборки.

Return On и Return On or After

Return On и Return On or After, или скользящий retention, отвечают на разные диагностические вопросы. Первый проверяет точный возврат в конкретный интервал, второй - факт возврата в этот интервал или позже.

Return On считает пользователя удержанным только если он вернулся в точный интервал: например, Day 5 retention учитывает возврат именно на пятый день после стартового события. Такой подход подходит продуктам с жестким ритмом: ежедневная игра, социальное приложение, рабочий инструмент, который должен открываться каждый день. Если пользователь вернулся на Day 6, точный Day 5 retention его не засчитает. Диагноз: если продукт должен использоваться ежедневно, а Return On на Day 1 и Day 3 падает резко, проблема лежит в ранней ценности или регулярном поводе вернуться.

Return On or After считает пользователя удержанным, если он вернулся в заданный интервал или в любой более поздний интервал. Mixpanel называет этот режим более подходящим для большинства бизнесов и использует его как default в Retention report. Такой расчет выше, чем точный Return On, потому что он накапливает поздние возвраты. Для маркетплейса, доставки, travel, B2B-сервиса или подписки это часто ближе к реальности: пользователь может не возвращаться ровно на Day 7, но при этом остаться ценным клиентом на горизонте месяца.

Мы видим скрытый риск в сравнении рекламных кампаний: одна и та же когорта может выглядеть слабой по Return On и приемлемой по Return On or After. Для daily-use продукта это сигнал проблемы привычки; для e-commerce или B2B-лида точный Day 7 может быть слишком жестким окном. Поэтому метод расчета нужно выбирать до оптимизации ставок, креативов и посадочных страниц, а не после того, как цифры уже понравились или разочаровали.

Смотрите на retention как на проверку качества трафика после клика. Если кампания дешевая по CPL, но ее когорта не возвращается к выбранному событию, масштабирование усилит слабую связку. Зафиксируйте старт, возврат, окно и тип расчета. Сначала методика.

Дневной, недельный и месячный retention

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

В мобильных приложениях часто смотрят Day 1, Day 3, Day 7, Day 14, Day 28 и Day 30; Day 1 считается одним днем после установки или первого открытия приложения. По бенчмаркам Business of Apps за 2025 год Day 1 retention для Android и iOS был около 26%, Day 7 - 11% на Android и 12% на iOS, Day 30 - около 6% на обеих платформах. Эти числа не говорят, что 6% всегда хорошо или плохо. Они дают диагностический масштаб: если у consumer-приложения Day 1 уже близок к нулю, проблема ранняя; если Day 1 держится, но Day 30 провален, ищите отсутствие повторяемой ценности.

Бенчмарки Business of Apps за 2025 год показывают разные уровни Day 1, Day 7 и Day 30 retention для Android и iOS.

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

Для выбора окна используйте такую логику:

• если ценность должна появиться в первой сессии, смотрите Day 1 и Day 3;
• если продукт нужен по рабочему или учебному циклу, сравнивайте Week 1 и Week 4;
• если покупка или оплата повторяется редко, ставьте Month 1, Month 3 и Month 6;
• если рекламная кампания обещает быстрый результат, проверяйте ранние окна отдельно от поздних.

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

Как построить когортный анализ

Когортный анализ строит retention как матрицу: строки показывают группы пользователей, столбцы - возраст этих групп, ячейки - процент возврата. Такой формат помогает отличить общий спад от проблемы конкретной когорты.

Когорта в маркетинге - это не просто сегмент аудитории, а группа с общей точкой старта. В retention-таблице строки обычно задают дату или событие старта: неделя регистрации, месяц первой покупки, первая установка после рекламной кампании. Столбцы показывают возраст когорты: Day 0, Day 1, Day 7, Week 1, Month 1. Ячейка отвечает на один вопрос: какая доля исходной строки вернулась в этот возраст. Если смотреть таблицу по диагонали, вы видите свежие когорты; если смотреть по столбцу Day 7, сравниваете разные когорты на одинаковом возрасте.

Рабочий порядок построения:

1. Выберите стартовое событие и период группировки: день, неделю или месяц.
2. Соберите стабильный идентификатор пользователя, чтобы один человек не распался на несколько записей.
3. Назначьте возвратное событие, связанное с ценностью продукта.
4. Постройте матрицу: строки - когорты, столбцы - возраст, ячейки - retention.
5. Пометьте маленькие когорты и неполные интервалы, чтобы не сравнивать шум с полными данными.

В AppMetrica retention analysis показывает, сколько пользователей возвращаются в приложение после первого запуска или другого стартового события через заданный период, и помогает увидеть момент, когда пользователи начинают терять интерес. Для ручного когортного анализа в Excel или BI обязательны стабильные user_id и единая таймзона; иначе один пользователь может попасть в несколько когорт, а события около полуночи разъедутся по разным дням. В когортной таблице последние когорты выглядят как «лестница»: у свежей когорты еще нет данных за поздние интервалы, поэтому ее нельзя сравнивать с полной 30-дневной историей старых когорт.

AppMetrica описывает retention analysis как отчет, который показывает возврат пользователей после первого запуска или другого стартового события через заданный период.

Типичный порог для интерпретации когорт: если когорта меньше 100 пользователей, один пользователь равен 1 п.п.; при 20 пользователях один возврат меняет retention уже на 5 п.п., поэтому маленькие строки лучше помечать как предварительные. Это особенно важно в разрезах по каналам: платная кампания может дать малую когорту, и один повторный заказ сделает график убедительным визуально, хотя статистически вывод еще слабый. Диагностируйте такие строки как гипотезы, а не бюджетное решение.

Не сравнивайте свежую когорту на неполном Day 30 со старой когортой, у которой прошло все окно. Это не ускоренная аналитика, а смешение разных возрастов когорты.

Retention и churn: что сравнивать

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

Retention показывает долю оставшихся или вернувшихся пользователей, churn rate - коэффициент оттока, то есть долю потерянных за тот же период. При одинаковой базе и периоде эти метрики складываются в 100%. Если из 1 000 клиентов к концу месяца активными остались 900, retention равен 90%, churn - 10%. Но это работает только при одной и той же базе. Если retention считается по пользователям, а churn - по выручке, связь ломается. В SaaS возможна ситуация: user churn положительный, но revenue retention выше 100% за счет expansion revenue, когда часть оставшихся клиентов расширила тариф или докупила места.

Для B2B SaaS в 2025 году средний churn указан как 3,5%: 2,6% voluntary churn и 0,8% involuntary churn; consumer-facing SaaS часто находится в диапазоне 6,5-8%.

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

Сравнивайте retention и churn только после трех проверок:

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

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

Почему значения разных инструментов расходятся

Расхождение retention между GA4, Mixpanel, AppMetrica, CRM и BI чаще объясняется методикой, а не ошибкой одной системы. Инструменты по-разному видят пользователя, окно времени и возвратное событие.

Первый источник расхождений - идентификация пользователя. Один инструмент может считать cookie или device_id, другой - logged-in user_id, третий - CRM-клиента после оплаты. Если человек открыл сайт с телефона, потом купил с ноутбука и вошел в аккаунт только на втором устройстве, разные системы могут увидеть одного или двух пользователей. Удаление cookies, блокировщики, переустановка приложения и неполная авторизация меняют размер исходной когорты и число возвратов. Диагноз: если retention в продуктовой аналитике выше, чем в веб-аналитике, проверьте, где появляется устойчивый user_id.

Mixpanel retention считает уникальных пользователей, а не количество событий: пользователь может быть учтен один раз в одном bucket, но попадать в несколько buckets, если выполняет стартовое событие в разные периоды.

Второй источник - календарное окно. Rolling 24 hours и календарный день по таймзоне проекта могут по-разному отнести один и тот же возврат к Day 0 или Day 1. Если пользователь зарегистрировался в 23:50 и вернулся через 20 минут, один отчет может посчитать возврат на следующий календарный день, а другой - внутри первых 24 часов. Третий источник - определение активного пользователя: «открыл приложение», «создал сессию», «совершил целевое действие» и «оплатил» измеряют разные уровни возврата. Смена такого определения может менять retention сильнее, чем сама продуктовая динамика.

Стандартные обзоры раннего retention полезны как первый экран диагностики, но они не заменяют произвольную когортную модель в BI. Если продукт живет месячными платежами или редкими повторными покупками, короткий горизонт может показать первый опыт, но не закрыть весь цикл удержания.

Когда два отчета расходятся, не усредняйте их. Сначала выпишите правила: кто пользователь, какое стартовое событие, какое возвратное событие, какая таймзона и какой тип retention.

Порядок проверки расхождений:

1. Сравните идентификатор пользователя в каждом инструменте.
2. Проверьте, совпадает ли стартовое событие.
3. Проверьте возвратное событие и фильтры активности.
4. Сверьте таймзону и правило Day 0/Day 1.
5. Посмотрите, считает ли отчет точный Return On или возврат в интервал или позже.

Как сегментировать удержание

Сегментация удержания нужна, когда общий Retention Rate скрывает разные причины поведения. Разрез должен помогать выбрать гипотезу: проблема в канале, устройстве, регионе, первом опыте, тарифе или типе аудитории.

Минимальный набор сегментов для retention: канал привлечения, платформа или устройство, география, первый сценарий активации, тариф или платежный статус, новая или возвращенная аудитория. Но сегмент ради сегмента только увеличивает шум. Если разбить 1 000 новых пользователей на 5 каналов, 2 платформы и 4 региона, средняя ячейка будет около 25 пользователей до учета фактической неравномерности трафика. При таком размере один возврат меняет процент на 4 п.п., и отчет легко превращается в набор случайных победителей.

В AppsFlyer-глоссарии для iOS Finance Day 30 retention указан 10,74%, а для iOS Entertainment - 4,42%; разрыв показывает, что категория продукта может менять ожидания более чем в 2 раза.

Практический паттерн сегментации: пользователи, завершившие activation event в первой сессии, обычно имеют кратно выше D7/D30 retention, чем пользователи без активации; поэтому activation cohort часто важнее демографического сегмента. По нашим наблюдениям в платном трафике связка «источник → объявление → посадочная страница → первое действие → возвратное действие» дает больше пользы, чем десятки поверхностных разрезов. Если одна кампания приводит пользователей, которые регистрируются, но не возвращаются к действию, это не только вопрос ставки. Это сигнал проверить обещание объявления, первый экран и следующий шаг после регистрации.

Сильные сегменты для диагностики:

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

В сегментации по размеру компании полезно смотреть не только Month 1. На малых аккаунтах раннее принятие продукта может выглядеть сильнее, а на крупных аккаунтах преимущество часто проявляется позже, когда продукт проходит первый рабочий цикл. В нашем аналитическом разборе это хорошо показывает скрытый сдвиг: лидер по удержанию может меняться в зависимости от горизонта. Если вы смотрите только Month 1, вы диагностируете раннее принятие продукта; если Month 3 - устойчивость после цикла.

Если рекламная когорта выглядит сильной по первой конверсии, проверьте возвратное событие в нужном окне. В GA4 Cohort exploration когорты можно группировать с дневной, недельной или месячной гранулярностью, а критерий возврата задается как Any event, transaction, conversion или конкретное событие. Для рекламы это причина считать не только вход, но и следующий осмысленный возврат.

Чек-лист корректного отчета

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

Retention-отчет должен явно фиксировать: стартовое событие, возвратное событие, размер когорты, период старта, окно возврата, таймзону, тип retention, фильтры и способ идентификации пользователя. Если в отчете нет размера когорты рядом с процентом, 50% retention может означать как 500 из 1 000 пользователей, так и 1 из 2; управленческий вес этих результатов принципиально разный. Сравнение когорт корректно только на одинаковом возрасте когорты: Day 7 одной когорты сравнивают с Day 7 другой, а не с календарной неделей или неполным Day 30 свежей когорты.

Проверьте отчет перед тем, как принимать решение:

• Указано стартовое событие и оно одинаково для сравниваемых когорт.
• Указано возвратное событие и оно связано с ценностью продукта.
• Рядом с процентом показан размер когорты.
• Подписан возраст когорты: Day 1, Day 7, Week 4, Month 1 или другой горизонт.
• Указан тип retention: Return On, Return On or After или bracket.
• Зафиксированы таймзона, фильтры и способ идентификации пользователя.
• Отмечены изменения продукта, тарифов, onboarding, рекламного канала или сезонной акции.

В чек-листе полезно держать два слоя вывода: абсолютный retention по всем пользователям и segmented retention по ключевым сегментам. Если менялись onboarding, paywall, тарифы, сезонная акция или рекламный канал, это нужно отмечать рядом с когортой; иначе изменение retention можно ошибочно принять за эффект продукта. Для платного трафика добавьте источник, кампанию, креатив и посадочную страницу: без этой связки CPA, ROAS и тесты объявлений будут оптимизироваться по неполной картине.

Начинайте диагностику retention с определения события, а не с поиска «хорошего» процента. Зафиксируйте когорту, окно, тип расчета и размер базы; затем сравните retention с churn на одинаковой основе и только после этого режьте данные по каналам, устройствам и сценариям активации. Главная ошибка - лечить общий график, не поняв, какая гипотеза объясняет ваш случай: слабый первый опыт, неверное окно, шум маленькой когорты, технический сбой учета или потеря ценности продукта.