DAU, MAU и retention: как считать активную аудиторию приложения

Формулы и калькулятор Stickiness (DAU / MAU и DAU / WAU), разница между классическим Day N Retention и Rolling Retention, разбор притока и оттока в AppMetrica — и чёткая граница между отчётами по API в LidFly и тем, что смотрят в веб-интерфейсе.

1 ноября 2026 · Время чтения: 10 мин · LidFly

Знакомая ситуация в мобильном маркетинге: вы масштабировали закупку трафика, установки растут, а месячная аудитория (MAU) в отчёте прибавила 30%. Но выручка топчется на месте, а дневной онлайн (DAU) почти не сдвинулся. Пока смотришь только на верхнюю строчку MAU и цену установки, кажется, что реклама работает. Но стоит посчитать DAU / MAU и разделить аудиторию на новичков, вернувшихся и ушедших в отток, как вскрывается реальная картина: свежий трафик просто маскирует отток постоянных пользователей после неудачного релиза или широкого автотаргетинга.

В LidFly AppMetrica работает в одной связке с Яндекс Аудиториями и Яндекс Директом. ИИ во встроенном чате (или подключённый по MCP Claude, ChatGPT и Codex) запрашивает уникальную аудиторию по дням, неделям и месяцам без ручных выгрузок в таблицы, проверяет баланс новичков и «уснувших» пользователей, находит просадку на конкретной версии приложения или ОС и после вашего подтверждения создаёт сегмент в Яндекс Аудиториях для ретаргетинга. Если сначала нужно свести стоимость установки (CPI) и расходы кампаний с трекерами, начните с разбора рекламы мобильного приложения в Директе и AppMetrica, а полный перечень параметров инструментов смотрите в документации AppMetrica в LidFly.

DAU, WAU и MAU: что считают метрики и почему нельзя складывать дни

Базовые метрики мобильного приложения начинаются с подсчёта активной аудитории на трёх горизонтах времени — DAU, WAU и MAU. По данным Яндекс Вордстата (регион 225 — Россия, проверка 01.11.2026), связку «dau mau» ищут 781 раз в месяц («dau mau метрики» — 94, «dau wau mau метрики» — 39, «dau mau wau что это» — 27), а «метрики мобильного приложения» — ещё 102 раза. За всеми тремя аббревиатурами стоит один и тот же счётчик уникальных людей:

• DAU (Daily Active Users) — число уникальных пользователей, открывших приложение (выполнивших хотя бы одну сессию) за конкретные сутки. Если человек запустил приложение утром, в обед и вечером, в DAU этого дня он засчитывается один раз.
• WAU (Weekly Active Users) — число уникальных пользователей за 7 дней (календарную неделю или скользящее 7-дневное окно).
• MAU (Monthly Active Users) — число уникальных пользователей за 30 дней или календарный месяц.

Главная ошибка при ручной сборке дашбордов в Excel или BI — просуммировать столбец дневных DAU за 30 дней и назвать итог месячной аудиторией. Сумма дневных DAU даёт не число уникальных людей за месяц, а число человеко-дней активности.

Разберём на числах. Допустим, в октябре приложением доставки продуктов пользовались ровно 10 000 уникальных человек (это и есть истинный MAU = 10 000). Каждый из них делал заказ в среднем 6 раз в месяц в разные дни. Тогда средний дневной онлайн составит:

Средний DAU = (10 000 человек × 6 активных дней) ÷ 30 дней = 2 000 человек в сутки

Если сложить ежедневный DAU за все 30 дней (2 000 × 30), получится 60 000 — в шесть раз больше реальной базы. В AppMetrica уникальность внутри окна считается автоматически по метрике ym:ge:users (документация метрик активности AppMetrica):

• когда вы вызываете appmetrica_get_report_by_time с параметром group: "day", каждая точка ряда — это честный DAU конкретной даты;
• с параметром group: "week" каждая точка — WAU за календарную неделю без дублей внутри семи дней;
• с параметром group: "month" — MAU за календарный месяц;
• а если нужен MAU за произвольные 30 дней (например, с 15 сентября по 14 октября), вызывают appmetrica_get_report с metrics: "ym:ge:users" без группировок и берут поле totals.

Stickiness (DAU / MAU и DAU / WAU): формула и ориентиры по нишам

Сами по себе ни DAU, ни MAU не говорят, сформировалась ли у аудитории привычка открывать продукт. Если закупить 40 000 дешёвых мотивированных установок в конце месяца, MAU взлетит, хотя 90% этих людей закрыли приложение через минуту после первого запуска. Чтобы отделить реальную регулярность использования от рекламного наплыва, считают Stickiness (коэффициент «липучести» или возвращаемости):

Stickiness (месячный) = (Средний DAU за период ÷ MAU за тот же период) × 100%

Stickiness (недельный) = (Средний DAU за неделю ÷ WAU за ту же неделю) × 100%

Среднее число активных дней в месяц = (Средний DAU ÷ MAU) × 30

В числителе обязательно берут средний DAU за анализируемый месяц (а не пиковый день распродажи или провальное воскресенье), а в знаменателе — MAU за те же даты. Например, при среднем DAU = 8 400 и MAU = 42 000:

Stickiness = (8 400 ÷ 42 000) × 100% = 20,0%
Среднее число активных дней в месяц = 0,20 × 30 = 6,0 дня

Недельный коэффициент DAU / WAU работает аналогично на коротком цикле: если средний DAU равен 8 400, а за неделю зашли 21 000 уникальных человек (WAU), то DAU / WAU = 40%, то есть активный за неделю пользователь открывает приложение в среднем 0,40 × 7 = 2,8 дня из 7. Этот срез быстрее реагирует на продуктовые поломки: не нужно ждать конца месяца, чтобы увидеть просадку после вторничного релиза.

Сравнивать Stickiness аптеки или сервиса бронирования отелей с мессенджером бессмысленно: если человек покупает лекарства раз в три недели, его естественный предел DAU / MAU — около 5–7%. Зато падение собственного Stickiness приложения с 18% до 12% при растущем MAU — точный сигнал: либо рекламная кампания приводит случайных людей, либо новый билд мешает пользователям возвращаться.

Day N Retention и Rolling Retention: две формулы удержания

В отличие от Stickiness, который оценивает всю смешанную базу (и давних клиентов, и вчерашних новичков), Retention Rate (коэффициент удержания) всегда считается по когортам — группам людей, установивших или впервые открывших приложение в один и тот же период (День 0). Именно поэтому запросы «retention rate» (888 показов в месяц в Вордстате), «retention метрика» (394), «retention как рассчитать» (79) и «retention приложения» (65) сводятся к одному вопросу: какая доля новичков остаётся в продукте спустя 1, 7, 14 или 30 дней после первого запуска.

В мобильной аналитике и в интерфейсе AppMetrica используют две формулы удержания:

1. Классический Retention (Classic / Day N Retention)

Показывает процент пользователей когорты Дня 0, которые зашли в приложение строго в день N после установки:

Day N Retention = (Пользователи когорты, активные ровно в день N ÷ Размер когорты в день 0) × 100%

• День 0 (D0) — день первой сессии после установки (например, 1 октября приложение установили 2 000 человек).
• День 1 (D1) — следующие сутки (2 октября). Проверяет качество онбординга, скорость загрузки и соответствие приложения рекламному обещанию.
• День 7 (D7) — ровно через неделю (8 октября). Показывает, прошёл ли пользователь первый недельный цикл.
• День 30 (D30) — ровно на тридцатые сутки после установки. Отражает сформированную привычку.

2. Скользящий Retention (Rolling Retention / Unbounded Retention)

Показывает процент пользователей когорты Дня 0, которые зашли в приложение в день N или в любой день после него (вплоть до даты построения отчёта):

Rolling Retention Day N = (Пользователи когорты, активные в день N или позже ÷ Размер когорты в день 0) × 100%

Посмотрите, как расходятся оба показателя на одной и той же когорте из 2 000 установок интернет-магазина зоотоваров, где корм заказывают раз в 2–3 недели:

У Rolling Retention есть особенность, которая часто путает при сверке отчётов: его прошлые значения могут подрастать задним числом. Если пользователь из октябрьской когорты не открывал приложение весь октябрь, а вернулся 5 ноября, при ноябрьском пересчёте он добавится в числитель Rolling Retention для D7, D14 и D30. Классический Day N Retention фиксируется сразу после окончания суток N и больше не меняется.

Калькулятор Stickiness и Retention Rate

Подставьте свои цифры из отчёта AppMetrica, чтобы сразу посчитать месячный и недельный Stickiness, среднее число активных дней в месяц, а также сравнить классический Day N Retention и Rolling Retention для выбранной когорты:

Структура активной базы: новые, вернувшиеся и «уснувшие» пользователи

Когда график DAU или MAU идёт вверх или вниз, одной цифры ym:ge:users мало: по ней не видно, держится ли продукт на постоянном ядре, свежем рекламном трафике или реактивации старой базы. Чтобы разложить активную аудиторию по составу, в AppMetrica используют пространство имён ym:u (справочник метрик пользователей AppMetrica) — в LidFly его запрашивают через appmetrica_get_report или appmetrica_get_report_by_time:

• ym:u:activeUsers — все активные пользователи за выбранный интервал.
• ym:u:newUsers (и доля ym:u:newUsersShare) — новые пользователи, которые впервые открыли приложение в этом периоде.
• ym:u:resurrectedUsers (и доля ym:u:resurrectedUsersShare) — вернувшиеся пользователи: они уже пользовались приложением раньше, затем пропустили предыдущий период (ушли в неактивные), а в текущем снова запустили приложение.
• ym:u:dormantUsers (и доля ym:u:dormantUsersShare) — неактивные («уснувшие») пользователи: были активны в предыдущем периоде, но ни разу не открыли приложение в текущем.

Соотношение этих четырёх метрик сразу показывает здоровье воронки. Если ym:u:newUsers и ym:u:dormantUsers растут синхронно, а ym:u:activeUsers стоит на месте — перед вами классическое «дырявое ведро»: маркетинг заливает новые установки, но столько же людей из прошлого периода засыпает. Если же после пуш-рассылки или ретаргетинговой кампании в Директе подскакивает ym:u:resurrectedUsersShare, вы видите прямой объём реактивированной базы в числах.

Второй проверочный слой — глубина вовлечённости внутри самой сессии (пространство ym:s, метрики сессий AppMetrica): среднее число сессий на пользователя ym:s:sessionsPerUser и суммарное время в приложении на пользователя ym:s:totalSessionDurationPerUser. Когда после релиза ym:s:sessionsPerUser падает с 3,8 до 1,4, пользователи спотыкаются на старте — задолго до того, как это отразится в месячном отчёте MAU.

Что считает LidFly по API AppMetrica, а где нужен веб-интерфейс

Перед тем как строить отчёты через ИИ, стоит разделить метрики, которые отдаёт публичный Reporting API AppMetrica (/stat/v1/data и /stat/v1/data/bytime), и отчёты, доступные только в веб-интерфейсе Яндекса. В полном справочнике метрик и группировок Reporting API (таблица всех метрик и атрибутов AppMetrica API) нет отдельной метрики когортного retention или rolling retention.

Поэтому рабочий процесс между LidFly и кабинетом AppMetrica делится так:

Два рабочих сценария с готовыми промптами

Ниже — два типовых сценария на условных цифрах, где расчёт активной аудитории соединяется с диагностикой релиза и ретаргетингом в Директе.

Сценарий 1. MAU вырос на 30% после рекламного флайта, но Stickiness упал: ищем причину

Типовой сценарий. У приложения доставки еды за октябрь MAU вырос с 42 000 до 55 000 после запуска новой кампании, но заказы не прибавили, а средний DAU застрял на отметке 6 600 (Stickiness просел с 15,7% до 12,0%). Вместо того чтобы наугад отключать рекламу или переписывать креативы, маркетолог в чате LidFly просит ИИ разложить аудиторию по слоям за четыре шага:

1. Получить список приложений через appmetrica_get_applications и общую сводку appmetrica_get_app_overview за 30 дней.
2. Выгрузить дневной ряд DAU (group: "day") и недельный WAU (group: "week") через appmetrica_get_report_by_time по метрике ym:ge:users, а точный 30-дневный MAU взять из totals в appmetrica_get_report, чтобы рассчитать честный DAU / MAU и DAU / WAU.
3. В отдельных запросах проверить баланс притока и оттока (ym:u:activeUsers, ym:u:newUsers, ym:u:resurrectedUsers, ym:u:dormantUsers) и глубину сессий (ym:s:sessionsPerUser, ym:s:totalSessionDurationPerUser).
4. Разрезать активную аудиторию и сессии по ym:ge:appVersion и ym:ge:operatingSystem, а также по партнёру установки ym:ge:profilePublisher.

Четыре запроса к API показывают: на iOS в версии 4.8.2 среднее число сессий стабильно (4,1 на пользователя), а на Android в сборке 4.8.2 показатель рухнул до 1,5 сессии из-за бага сброса авторизации при повторном входе. После этого продакт открывает веб-интерфейс AppMetrica в отчёте «Retention-анализ», фильтрует когорту по версии 4.8.2 на Android и подтверждает провал Day 1 Retention перед выпуском хотфикса.

Промпт для чата LidFly (диагностика DAU/WAU/MAU, Stickiness и срезов по версиям):

Найди наше приложение в AppMetrica и проведи аудит активной аудитории за последние 30 дней:
1. Выгрузи динамику ym:ge:users по дням (DAU) и по неделям (WAU) через appmetrica_get_report_by_time, а также точный итоговый MAU за 30 дней через appmetrica_get_report. Посчитай средний DAU, Stickiness (DAU / MAU и DAU / WAU) и среднее число активных дней в месяц.
2. Отдельным запросом в пространстве ym:u покажи баланс аудитории по неделям: ym:u:activeUsers, ym:u:newUsers, ym:u:resurrectedUsers и ym:u:dormantUsers.
3. Отдельным запросом в пространстве ym:s проверь ym:s:sessionsPerUser и ym:s:totalSessionDurationPerUser.
4. Сделай срез ym:ge:users и ym:ge:sessions по ym:ge:appVersion и ym:ge:operatingSystem, чтобы проверить, нет ли просадки на свежем релизе.
В конце выдели узкое место и напиши, какой когортный срез Day 1 / Day 7 Retention дополнительно открыть в веб-интерфейсе AppMetrica.

Сценарий 2. Возвращаем «уснувших» пользователей и установки без первого заказа через Яндекс Аудитории

Типовой сценарий. По отчёту ym:u:dormantUsers и списку событий appmetrica_get_events видно, что за месяц накопился пласт людей, которые установили приложение, прошли регистрацию (registration_complete), но не оформили первый заказ (order_paid) и перестали заходить.

Пытаться выгрузить список их device_id или googleAID через отчёты AppMetrica не нужно (и технически нельзя: LidFly блокирует идентификаторы устройств в группировках). Вместо этого работает прямая связка с Яндекс Аудиториями (документация API Яндекс Аудиторий):

1. Если нужен сегмент по всем пользователям приложения (например, чтобы исключить текущую базу из кампании на привлечение корректировкой −100% или собрать Look-alike), в LidFly достаточно application_id из appmetrica_get_applications.
2. Если нужен узкий поведенческий сегмент («установили, но не купили за 14 дней» или «не заходили 30 дней»), вы сохраняете его в веб-интерфейсе AppMetrica и копируете числовой ID сегмента.
3. В чате LidFly ИИ сначала проверяет через audience_get_segments (type: "appmetrica"), нет ли уже такого сегмента, а затем готовит вызов audience_create_appmetrica_segment (name, object_type: "segment" для сохранённого сегмента или "application" для всего приложения, object_id). Запись выполняется только после вашего текстового подтверждения.
4. После создания ИИ перечитывает audience_get_segments с фильтром type: "appmetrica" и проверяет статус обработки. Как только Яндекс переведёт сегмент в статус «Готов» (usable_in_direct: true), в ответе появится готовый direct_goal_id для добавления в условие ретаргетинга в Яндекс Директе (правила условий подбора аудитории в Директе). О том, как делить базу на смысловые группы по давности и ценности, подробно разобрано в статье про сегментацию аудитории для рекламы.

Промпт для чата LidFly (проверка событий и создание сегмента в Яндекс Аудиториях):

1. Проверь в нашем приложении AppMetrica за последние 30 дней объём неактивных пользователей (ym:u:dormantUsers) и список ключевых событий через appmetrica_get_events.
2. Посмотри существующие сегменты типа appmetrica в Яндекс Аудиториях через audience_get_segments: какие из них уже в статусе «Готов» (usable_in_direct=true) и какой у них direct_goal_id.
3. Подготовь создание нового сегмента в Яндекс Аудиториях через audience_create_appmetrica_segment для сохранённого сегмента AppMetrica с ID [УКАЖИТЕ_ID_СЕГМЕНТА] и названием «AppMetrica — неактивные 14+ дней». Ничего не создавай без моего текстового подтверждения.

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

Источники

• AppMetrica Reporting API: метрики активной аудитории и событий (ym:ge:*) (проверено 01.11.2026).
• AppMetrica Reporting API: метрики новых, вернувшихся и неактивных пользователей (ym:u:*) (проверено 01.11.2026).
• AppMetrica Reporting API: метрики сессий и вовлечённости (ym:s:*) (проверено 01.11.2026).
• AppMetrica Reporting API: полный справочник метрик и группировок (/stat/v1/data и /stat/v1/data/bytime) (проверено 01.11.2026).
• Документация API Яндекс Аудиторий: сегменты из AppMetrica (проверено 01.11.2026).
• Справка Яндекс Директа: условия подбора аудитории и ретаргетинг (проверено 01.11.2026).
• Яндекс Вордстат (регион 225 — Россия), частотность запросов за последние 30 дней, проверено 01.11.2026.