Retention rate: как удержать пользователей мобильного приложения
Удержание пользователей (retention rate) показывает, возвращаются ли люди в мобильное приложение после первого знакомства. Поводы для повторного визита различаются: кому-то нужен следующий заказ, кому-то — обновление ассортимента или доступные бонусы. Выбор механики удержания начинается с полезного действия, ради которого человек готов вернуться.
Что такое retention rate простыми словами
Retention rate — доля пользователей из выбранной группы, которые вернулись в мобильное приложение после первого взаимодействия. По-русски показатель называют удержанием или возвращаемостью. Он отвечает на вопрос: сохраняется ли интерес к продукту после установки и первого знакомства?
Группу с общим моментом начала называют когортой: например, люди, впервые запустившие приложение в одну неделю. В когортном отчёте AppMetrica можно отслеживать запуск приложения и целевые события после установки. Для бизнеса полезно разделять возврат к просмотру каталога и повторную покупку: они показывают разные стороны поведения.

Возврат пользователя и повторная покупка
Покупатель может открыть приложение, проверить бонусы и закрыть его без заказа. По событию запуска он вернулся; по событию покупки — ещё нет. Выберите действие, которое связано с ценностью продукта: просмотр актуального предложения, повторный заказ, запись на услугу. Считать только открытие достаточно для первого анализа, но решение о развитии требует сопоставления с результатом для клиента.
Удержание, конверсия и отток
Конверсия показывает долю людей, дошедших до действия, например от корзины до оплаты. Удержание оценивает возвращение одной группы во времени. Отток обозначает потерю активности по принятому правилу: отсутствие покупки в установленный период или прекращение подписки. Равенство «отток = 100% − удержание» применимо только при одинаковой группе, окне и взаимоисключающих определениях. Отсутствие запуска в один день ещё не означает окончательный уход.
Как рассчитать удержание пользователей
Расчёт начинается с определения начального события, события возврата и периода наблюдения. Для возврата в конкретный день формула такая: число уникальных пользователей когорты, вернувшихся в день N, ÷ исходное число пользователей когорты × 100%. Повторные открытия одним человеком не увеличивают числитель.
Учебный пример расчёта
Предположим, 1 сентября приложение впервые открыли 1 000 человек. На следующий день вернулись 300 из них, в седьмой день — 180, в тридцатый — 90. Получаем 30%, 18% и 9%. Это вымышленные данные для объяснения формулы, а не показатели рынка или проектов FITTIN. Новый пользователь, пришедший 8 сентября, в исходную тысячу не входит.
| Способ расчёта | Что считается возвратом | Для чего подходит |
|---|---|---|
| В конкретный день | Хотя бы одно выбранное действие именно в день N | Проверка раннего знакомства и регулярности использования |
| В интервале | Хотя бы одно действие внутри заданного окна, например с 7-го по 13-й день | Продукты с еженедельным или нерегулярным спросом |
| С дня N и позже | Хотя бы одно действие начиная с дня N до конца наблюдения | Оценка сохранения активности при редких возвращениях |
Различия способов расчёта
В варианте «с дня N и позже», который называют Rolling Retention, человек, вернувшийся на десятый день, будет учтён начиная с более ранних контрольных дней. Принцип описан в глоссарии AppMetrica. В расчёт для конкретного седьмого дня этот человек попадёт только при действии именно в седьмой день. Сравнивать показатели двух отчётов можно после сверки определений.
Дополнительно зафиксируйте часовой пояс и границы дня: календарные сутки и последовательные 24-часовые окна от первого запуска могут давать разные результаты. Укажите дату окончания наблюдения. Недавняя группа, для которой ещё не наступил тридцатый день, не должна получать нулевое значение за этот день.
Какой retention rate считать ориентиром для бизнеса
Рабочий ориентир формируют по частоте потребности и истории собственного продукта. У приложения доставки еды, магазина одежды и сервиса покупки мебели разные интервалы возвращения. Ежедневная активность важна там, где ежедневна сама задача пользователя; для редких покупок полезнее наблюдать более длинные окна и повторные заказы.

Сравнивайте сопоставимые группы
Разделите аудиторию по источнику привлечения, операционной системе, версии приложения и первому полезному действию. Сегменты AppMetrica позволяют ограничивать выборку пользователей. Общая цифра может измениться из-за состава трафика, даже если внутри каждой группы поведение осталось прежним.
Для приложения интернет-магазина отдельно изучают новых посетителей и действующих покупателей. Человек, перенёсший знакомый сценарий с сайта, и человек, впервые увидевший бренд в рекламе, начинают с разным уровнем доверия. Объединение этих групп затрудняет выбор доработки.
Задайте внутреннюю цель
Начните с нескольких полностью наблюдённых когорт за сопоставимые периоды. Учтите сезонность, акции и объём групп. Цель формулируйте как проверяемую гипотезу: «упростить повторный заказ и повысить долю повторных покупок в выбранном окне без увеличения скидочных затрат». Общий обзор аналитики мобильного приложения помогает связать этот показатель с остальными данными.
Почему пользователи перестают возвращаться
Причину ухода ищут на конкретном участке пути: от обещания рекламы до получения заказа. Сначала определяют, когда меняется поведение, затем сопоставляют данные с обращениями в поддержку и наблюдением за использованием приложения. Одна кривая удержания показывает симптом, но не объясняет его.
Первый запуск не приводит к полезному действию
Обязательная регистрация до просмотра каталога, длинное обучение и запросы разрешений без контекста увеличивают число шагов до результата. Проверьте, может ли человек выполнить основную задачу без инструкций. Если приложение уже работает, аудит UX/UI помогает разобрать экраны и последовательность действий, после чего гипотезу проверяют на пользователях.
Технические сбои мешают повторному использованию
Ошибка входа, потерянная корзина и зависание оплаты дают конкретный повод прекратить попытку. В рекомендациях Android по качеству выделены удобство взаимодействия, производительность и стабильность. Проверьте путь на разных устройствах, при прерывании связи и возвращении из фонового режима. Для существующего продукта результаты аудита кода связывают с наблюдаемыми сбоями.
Повторный визит не даёт новой ценности
После покупки пользователю нужен следующий повод: состояние заказа, пополнение расходуемого товара, подборка по интересам или использование накопленных бонусов. Если предложение не связано с потребностью, сообщение приводит к открытию, за которым не следует действие. Разбор обращений и бизнес-аналитика проекта помогают определить, какую задачу стоит развивать.
Какие механики помогают удерживать пользователей
Механику выбирают по найденной причине ухода. Сокращение пути до покупки помогает тому, кто затрудняется оформить заказ; напоминание подходит человеку с отложенной потребностью. Связь «проблема → изменение → проверка» позволяет оценить результат каждой доработки.

Понятное первое знакомство
Покажите пользу в первом сценарии: доступный каталог, условия доставки, возможность сохранить выбор. Обучающие подсказки привязывайте к действию. Регистрацию запрашивайте там, где она нужна для функции. После изменения измерьте достижение первого результата и возвращение этой же группы. Дизайн мобильного приложения должен учитывать этот путь, а не только внешний вид экранов.
Push-уведомления по событию
Сообщение о наличии выбранного товара или готовности заказа связано с ожиданием пользователя. Ссылка должна открывать нужный экран и сохранять контекст после входа. Дайте выбор тем и возможность отключить сообщения. В Android 13 и выше отправка обычных уведомлений связана с системным разрешением на уведомления; сценарий также проверяют на остальных целевых платформах.
При внедрении push-уведомлений настройте ограничение частоты и исключение людей, уже выполнивших действие. Сравнивайте вернувшихся и купивших с контрольной группой, а также отключения уведомлений. Подходы к содержанию сообщений разобраны в статье о push-уведомлениях в приложении.
Программа лояльности с понятной выгодой
Баланс бонусов, условия использования и история начислений должны быть доступны внутри приложения. Статус или персональное предложение дают повод вернуться, когда выгода соответствует привычкам покупателя. При запуске программы лояльности оценивают повторные покупки и затраты на вознаграждения вместе. Подробности механик описаны в статье о лояльности в приложении интернет-магазина.
Персонализация и удобный повторный заказ
Избранное, история покупок, доступные размеры и повтор заказа сокращают поиск при следующем визите. Для объединения действий на сайте и в приложении нужна интеграция с CRM — системой управления отношениями с клиентами. Например, партнёр FITTIN Mindbox может использоваться для сегментов и коммуникаций; конкретные события и обмен данными проектируют отдельно.
Геймификация под задачу магазина
Мини-игра, задания или календарь предложений создают дополнительный повод открыть приложение. В геймификации вознаграждение связывают с ассортиментом и программой лояльности. Проверяйте, переходят ли участники к покупке и возвращаются ли после завершения акции. Выбор формата раскрыт в статье о мини-играх в приложении магазина.
Как проверить, что изменение повысило удержание
До запуска проверки запишите гипотезу, целевую аудиторию, основной показатель и условия остановки. Если одновременно изменить регистрацию, скидку и частоту сообщений, будет трудно определить вклад каждого решения. Для первой проверки выберите одно изменение и измеримый результат.

Пример проверки повторного заказа
Учебная гипотеза: кнопка повторного заказа в истории покупок увеличит долю клиентов, оформивших следующий заказ в течение выбранного периода. Подходящих пользователей случайно распределяют между текущим интерфейсом и новым. Основной результат — повторная покупка, дополнительные проверки — ошибки оформления, возвраты и затраты на скидки. Пользователь остаётся в назначенной группе на протяжении проверки.
Длительность и размер групп определяют по исходной доле покупок, ожидаемому изменению и допустимой неопределённости. Не завершайте проверку при первом удачном колебании. Дождитесь полного окна наблюдения для обеих групп. Если случайное распределение невозможно, сравнение до и после рассматривайте с учётом сезонности и состава трафика: оно даёт менее определённый вывод о причине изменения.
Дополнительные показатели проверки
| Показатель | Какой вопрос решает | Что может исказить вывод |
|---|---|---|
| Возврат к выбранному действию | Сохранилась ли активность исходной группы? | Другое окно или неполное наблюдение |
| Повторная покупка | Возвращается ли клиент за товаром или услугой? | Сезонная акция, изменения наличия и цен |
| Доход и расходы на вознаграждения | Оправдана ли механика для бизнеса? | Рост покупок только за счёт дополнительных скидок |
| Ошибки и отключения сообщений | Сохраняется ли качество пользовательского опыта? | Оценка только по открытиям уведомлений |
Практический вывод делают по результату для клиента и бизнеса вместе. При росте открытий без повторных заказов пересмотрите содержание предложения. Если после доработки появились ошибки, их устранение включают в техническую поддержку приложения, прежде чем расширять охват.
Чек-лист внедрения работы с удержанием
Организуйте работу как последовательность проверяемых решений. За отчёт и гипотезы нужен ответственный со стороны бизнеса; за события, интерфейс и интеграции — исполнители с согласованным составом работ. Совместный список задач помогает не потерять связь между доработкой и показателем.

- Определить полезное действие. Зафиксировать момент начала группы, событие возврата и частоту потребности.
- Проверить данные. Исключить тестовые устройства и дубли; сверить покупки с учётной системой.
- Построить исходный отчёт. Выбрать полностью наблюдённые группы и одинаковые окна.
- Найти участок потери. Сопоставить поведение с ошибками, обращениями и наличием товаров.
- Выбрать одну гипотезу. Описать аудиторию, изменение, основной показатель и дополнительные ограничения.
- Проверить результат. Выдержать срок наблюдения, оценить неопределённость и затраты.
- Принять решение. Расширить охват, доработать или остановить механику и сохранить вывод.
Состав и стоимость работ
Бюджет зависит от состояния аналитики, готовности событий, интеграций, изменений экранов и объёма тестирования. Запросите отдельную оценку настройки измерений и реализации механики. Требования фиксируют в техническом задании, чтобы одинаково понимать результат и способ приёмки. Если готового приложения нет, сначала проверяют основной сценарий продукта, а затем расширяют механики удержания.
В платформе FITTIN используются модули каталога, корзины, лояльности и аналитики; изменения под конкретный сценарий согласуют отдельно. Модель платформы включает единоразовую интеграцию, ежемесячную лицензию с технической поддержкой и новый функционал с оплатой фактически затраченного времени по Time & Materials. Оценку часов согласуют до начала задачи; условия и состав поддержки приведены в тарифах.
Примеры из проектов: что подтверждают опубликованные данные
Открытые кейсы показывают реализованные механики и результаты отдельных проектов. В них не опубликован единый retention rate по одинаковой методике, поэтому показатели продаж и участия нельзя выдавать за измеренный рост удержания.

DAISYKNIT: повод вернуться к коллекции
В кейсе DAISYKNIT описаны игровые механики и работа с программой лояльности. При миграции также зафиксирована 100% сохранность клиентской базы и интеграций. Это показатель переноса данных, который не равен доле вернувшихся покупателей. Для проверки удержания игровой аудитории нужны группы участников и сравнение с людьми без механики за одинаковый период.
Gulliver: приложение как канал покупок
В проекте Gulliver опубликована доля дохода через приложение — 50%. Этот результат показывает значение канала для бренда. Он не раскрывает, сколько людей вернулись в конкретный день после установки. Для анализа повторного поведения дополнительно нужны история заказов и дата первого действия каждого покупателя.
Итог: начните с измерения полезного возврата
Оптимальный порядок работы связывает понятное определение удержания, сопоставимые группы и проверку одной гипотезы. Сначала выберите действие и окно, затем найдите причину ухода и оцените доработку. Возвращение к полезному сценарию и повторная покупка дают бизнесу больше информации, чем рост числа открытий сам по себе.
Что делать дальше
- Неясна причина ухода из существующего продукта — согласуйте аудит приложения.
- Понятна проблема интерфейса — определите состав проверки UX/UI.
- Нужны уведомления или бонусные сценарии — оцените push-коммуникации и программу лояльности под выбранную группу.
- План изменений готов — передайте его команде для оценки.
Часто задаваемые вопросы
Что такое retention rate в мобильном приложении?
Это доля пользователей исходной группы, которые вернулись к выбранному действию после первого взаимодействия. Группу формируют по дате установки, первого запуска или покупки. При расчёте нужно назвать событие возврата и период: запуск в конкретный день, действие внутри интервала либо начиная с выбранного дня. Показатель помогает оценить повторный интерес к продукту, но сам по себе не объясняет причины поведения и не заменяет анализ покупок.
Как рассчитать retention rate?
Для конкретного дня разделите число уникальных пользователей исходной группы, совершивших выбранное действие в день N, на размер этой группы и умножьте на 100%. Например, из условной группы в 1 000 человек в седьмой день вернулись 180: показатель составляет 18%. Новые пользователи других групп не входят в расчёт. Повторные действия одного человека учитываются один раз. Для расчёта в интервале числитель определяют по этому интервалу.
Какой retention rate считается хорошим?
Ориентир зависит от категории приложения, частоты потребности, события возврата и способа расчёта. Для доставки еды и покупки мебели одинаковая ежедневная цель может быть неуместна. Сравнивайте полностью наблюдённые группы своего продукта при одинаковых условиях, учитывайте источники привлечения, сезонность и размер выборки. Цель улучшения связывайте с полезным действием и повторной покупкой. Универсальное значение без этих уточнений не даёт достаточного основания для решения.
Чем отличаются удержание на 1-й, 7-й и 30-й день?
Эти показатели описывают возвращение исходной группы в разные моменты после начального действия. Следующий день помогает оценить первое знакомство, последующие контрольные дни — сохранение интереса во времени. При расчёте для конкретного дня возвращение на восьмой день не попадает в седьмой. Если используется интервал или расчёт с выбранного дня и позже, правило другое. Перед сравнением уточните границы дня, часовой пояс и событие возврата.
Как повысить удержание пользователей приложения?
Начните с проверки данных и поиска участка, где люди прекращают пользоваться продуктом. Затем выберите соответствующее изменение: упростить первое действие, исправить сбои, сделать повторный заказ удобнее, показать бонусы или напомнить о нужном товаре. Проверяйте одну гипотезу на сопоставимых группах. Вместе с возвращаемостью измеряйте покупки, затраты на вознаграждения и качество работы. Расширяйте механику после полного окна наблюдения, когда результат подтверждается выбранным способом проверки.
Помогают ли push-уведомления удерживать пользователей?
Они создают повод вернуться, когда сообщение связано с потребностью: товар появился в наличии, заказ готов или доступны подходящие бонусы. Эффект зависит от содержания, частоты, доступности уведомлений и экрана, который открывает ссылка. Сравнивайте возвраты и покупки с контрольной группой, учитывайте отключения сообщений. Одно открытие уведомления не подтверждает устойчивое удержание. Если результата нет, пересмотрите сценарий, прежде чем увеличивать количество отправок.
Как связаны retention rate и повторные покупки?
Пользователь может вернуться в приложение без покупки: посмотреть ассортимент, проверить заказ или бонусы. Поэтому запуск и повторный заказ считают отдельно для одной группы. Рост возвращаемости даёт повод изучить поведение, но не доказывает рост дохода. Для коммерческого приложения анализируют также долю повторных покупателей, результат заказов и затраты на стимулирование. Показатели связывают через одинаковые окна наблюдения и согласованные события, а не подменяют один другим.
Источники
Документация проверена 6 октября 2026 года. Числа учебного расчёта вымышлены; данные проектов приведены отдельно со ссылками на опубликованные кейсы.
- AppMetrica: когортный анализ.
- AppMetrica: определения удержания и групп пользователей.
- AppMetrica: сегменты аудитории.
- Android Developers: качество приложения.
- Android Developers: разрешение на уведомления.
Материал носит информационно-аналитический характер, отражает оценку команды FITTIN на дату публикации.