DAU/MAU и stickiness: когда простая метрика начинает врать

Коротко

DAU/MAU отвечает не на вопрос «хороший ли продукт», а на более узкий вопрос: какая доля месячной аудитории активна в обычный день. Это полезный сигнал частоты, но слабая замена retention, когортам и продуктовой логике.

• Для ежедневных продуктов смотрите DAU/MAU: игры, мессенджеры, соцсети, ежедневные рабочие инструменты.
• Для продуктов с недельным ритмом часто честнее WAU/MAU: CRM, таск-трекеры, обучение, документация.
• Для редких сценариев низкий DAU/MAU может быть нормой: e-commerce, билеты, страхование, крупные покупки.
• Не сравнивайте stickiness между разными типами продуктов без контекста частоты использования.

Что измеряет DAU/MAU

DAU/MAU показывает, какая доля месячной аудитории активна в среднем дне. Если MAU равен 10 000, а средний DAU за месяц равен 2 000, stickiness будет 20%. В бытовом переводе: примерно каждый пятый месячный пользователь появляется в продукте в обычный день.

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

Когда выбирать DAU, WAU или MAU

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

Одинаковый MAU, разная реальность

Представьте два продукта с одинаковым MAU: 10 000 активных пользователей за месяц. В первом продукте люди возвращаются почти каждый день маленькими порциями. Во втором — заходят волнами после рассылок и распродаж. MAU одинаковый, но управленческий смысл разный: один продукт строит привычку, другой живёт от повода до повода.

Именно поэтому DAU/MAU полезнее голого MAU. Он показывает плотность возвращения внутри месяца. Но даже здесь нужно смотреть форму графика, а не только итоговый процент.

SQL для DAU/MAU

Если статья про DAU объясняла зерно «пользователь в день», то здесь важно не смешать дневные и месячные окна. Запрос написан для учебной базы симулятора SQL-аналитика: таблица events хранит одно событие на строку, event_time записан по московскому времени (время в UTC сначала переводят в часовой пояс отчёта), активностью считается любое событие — как в статье про DAU.

Запрос считает stickiness по полным дням: собирает пары «пользователь — день», затем средний DAU и MAU внутри каждого месяца. 30 августа отрезано: события за этот день обрываются в 12:59; в рабочем запросе на этом месте стоит event_time < current_date. Результат — 14,7% в июне (153,5 / 1 042), 13,0% в июле (349,7 / 2 688) и 11,9% за 29 дней августа (486,9 / 4 102).

Отношение снижается, хотя средний DAU вырос втрое. Новички ведут себя почти одинаково: пришедшие в июне были активны в июне в среднем 4,42 дня, пришедшие в августе — 4,12 дня в августе. Вниз тянут старые когорты: в августе у июльской 3,27 дня, у июньской — 1,86. Июльская заходит реже, чем в свой первый месяц, — обычное остывание. У июньской число занижено ещё и самой учебной базой: события пользователя записаны только за первые 59 дней после регистрации, и в августе запись июньских обрывается. Без июньской когорты август дал бы 12,9%, а не 11,9%. В живом продукте такого обрыва нет, но ход разбора тот же: общий процент не показывает, чья частота изменилась.

with active_days as (              -- зерно: пользователь + день
  select distinct
    cast(event_time as date) as day,
    user_id
  from events
  where event_time < date '2026-08-30'   -- 30 августа неполное
),
daily as (
  select
    cast(date_trunc('month', day) as date) as month_start,
    day,
    count(*) as dau
  from active_days
  group by 1, 2
),
monthly as (
  select
    cast(date_trunc('month', day) as date) as month_start,
    count(distinct user_id) as mau
  from active_days
  group by 1
)
select
  m.month_start,
  count(*) as full_days,
  round(avg(d.dau), 1) as avg_dau,
  m.mau,
  round(100.0 * avg(d.dau) / m.mau, 1) as dau_mau_pct
from monthly m
join daily d on d.month_start = m.month_start
group by m.month_start, m.mau
order by m.month_start;

Где DAU/MAU начинает врать

DAU/MAU особенно коварен, когда команда смотрит только на итоговый процент. Метрика может улучшиться не потому, что продукт стал привычнее, а потому что из базы ушли редкие пользователи. Или наоборот: ratio падает, потому что маркетинг привёл много новых людей в MAU, хотя ядро продукта не ухудшилось.

• Сезонность: в будни продукт живой, в выходные проседает, а среднее сглаживает картину.
• Платный трафик: MAU растёт быстрее, чем привычка новых пользователей.
• Пуши и email-кампании: DAU подскакивает на день, но retention не меняется.
• Редкий сценарий: пользователь получает ценность раз в месяц, и низкий DAU/MAU не является проблемой.
• Смена трекинга: одно новое событие внезапно делает «активными» тех, кто раньше не попадал в расчёт.

Как читать падение stickiness

Если DAU/MAU падает, не начинайте с общего вывода «люди стали меньше пользоваться продуктом». Сначала разложите метрику на числитель и знаменатель. Иногда проблема в DAU: старые пользователи действительно возвращаются реже. Иногда «проблема» в MAU: пришло много новых людей, и они ещё не успели сформировать привычку.

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

• Сравните avg DAU и MAU отдельно, а не только ratio.
• Отделите новых пользователей от вернувшихся.
• Проверьте когорты регистрации или первой активации.
• Посмотрите каналы и платформы: органика, paid, iOS, Android, web.
• Сопоставьте stickiness с retention, core action rate и выручкой.

Чеклист перед выводом

Хороший вывод по DAU/MAU обычно звучит длиннее, чем одно число. Он объясняет, у какого сегмента изменилась частота, когда это началось и какую гипотезу стоит проверять дальше.

• Определение active action одинаковое для DAU, WAU и MAU?
• Период метрики соответствует естественному ритму продукта?
• Сегодняшний неполный день не попал в сравнение с полными днями?
• Ratio не улучшился только из-за ухода редких пользователей из MAU?
• Падение не объясняется ростом новых пользователей, которые ещё не успели вернуться?
• Есть соседняя метрика: retention, revenue, conversion или core action rate?

Stickiness нужно читать в ритме продукта

DAU/MAU предполагает, что дневной ритм важен. Это хорошая гипотеза для мессенджера или игры, но не для сервиса, которым пользуются по понедельникам, в конце месяца или только перед отчётностью. В таком случае дневной числитель искусственно делает продукт «липким» или «нелипким», хотя пользовательский сценарий работает ровно так, как задумано.

Перед выбором ratio опишите естественную частоту задачи. Если пользователь обычно возвращается два-три раза в неделю, WAU/MAU будет ближе к реальности. Если ценность возникает раз в месяц, смотрите месячную повторную активность, долю пользователей с core action и retention на более длинном горизонте. Название метрики не должно диктовать ритм продукта.

Потолок DAU/MAU равен 29%, если продукт нужен дважды в неделю

У отношения есть вторая запись, которая сразу показывает его границы. Средний DAU, делённый на MAU, равен среднему числу активных дней на одного месячного пользователя, делённому на число дней в периоде. Условные 20% из начала статьи в этой записи читаются как шесть активных дней из тридцати на человека — и пока это чистая арифметика, без единого предположения о продукте.

Предположение появляется на следующем вопросе: сколько дней вообще возможно. Таск-трекер, в котором команда планирует спринт в понедельник и закрывает задачи в четверг, даёт пользователю два повода в неделю — это восемь-девять дней в месяц, то есть 2/7 ≈ 29%. Не хороший результат и не плохой: потолок. Даже если бы все 10 000 месячных пользователей ходили строго по своему ритму и ни один не отвалился, отношение не поднялось бы выше 29%. Двадцать процентов на таком продукте — это 70% от физически достижимого, и разговор из «почему у нас так мало» превращается в «кто из пользователей пропускает свои два дня».

У продукта, живущего по рабочим дням, тот же потолок двигает календарь. В месяце с 20 рабочими днями из 30 предел равен 67%, в месяце с 23 рабочими из 31 — 74%: семь пунктов разницы без единого изменения в поведении. Поэтому квартальные сравнения stickiness на рабочем инструменте частично измеряют количество выходных, а январский и майский провалы в России — это праздники, а не отток. Дневное отношение ещё и штрафует продукт за то, что он не нужен в субботу.

Для недельного ритма знаменатель меняют, и потолок возвращается к 100%. Пользователь, которому продукт нужен раз в неделю, попадает в каждую недельную аудиторию и в месячную, поэтому WAU/MAU читается как доля месячной аудитории, дожившая до конкретной недели, и падает только тогда, когда люди начали пропускать недели. DAU/WAU отвечает на соседний вопрос — сколько дней внутри активной недели человек действительно работал: два из семи у трекера, пять из семи у дежурной панели. WAU при этом считается тем же core action, что DAU и MAU: требование из раздела про SQL действует и здесь, иначе два отношения станут несравнимыми между собой.

Разрешение у дневного и недельного отношения разное, и это видно на одном условном продукте. За полгода DAU/MAU сполз с 20% до 17% — три пункта, которые легко списать на длинные выходные и пару праздников. WAU/MAU за тот же период упал с 65% до 49%. Оба ряда описывают одну аудиторию: шесть активных дней, разложенные по трём неделям из четырёх с небольшим, дают примерно 65%. Но когда пользователи начинают пропускать целую неделю, недельное отношение реагирует в пять раз сильнее дневного, потому что дневное делит тот же сигнал на все тридцать дней месяца.

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

Разложение ratio: числитель, знаменатель и когорты

Когда stickiness меняется, полезно записать его как отношение двух рядов: средний DAU и MAU. Затем добавьте когорты. Новые пользователи могут расширить MAU быстрее, чем успеют вернуться; старые пользователи могут сохранять прежнюю частоту. Средний ratio упадёт, хотя ядро продукта не стало хуже. Обратная ситуация тоже возможна: редкие пользователи уйдут из месячного окна, и ratio вырастет просто из-за изменения состава базы.

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

• Покажите avg DAU и MAU рядом с ratio.
• Разделите аудиторию на новые, существующие и воскресшие когорты.
• Сравнивайте только одинаковые календарные окна и таймзоны.
• Проверяйте, не изменился ли состав MAU из-за кампании или оттока.
• Для редкого сценария замените stickiness на метрику повторного результата.

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

Для сверки терминов полезно посмотреть, как DAU, WAU, MAU и stickiness описывают продуктовые аналитические платформы и KPI-справочники. Но чужие бенчмарки лучше использовать как ориентир, а не как норму: продуктовый ритм важнее красивого процента.