DAU: как считать активных пользователей так, чтобы метрика не врала

Коротко

DAU полезен, когда за ним стоит честное определение активности и понятная граница дня. Само число без разрезов быстро превращается в витрину: приятно смотреть, трудно принимать решения.

• Сначала выбери active action: действие, которое показывает реальное использование продукта.
• Считай пользователя один раз в день, даже если он сделал десятки событий.
• Разделяй общий DAU на новых, вернувшихся и воскресших пользователей.
• Не делай вывод по DAU без retention, core action rate, выручки или другой соседней метрики.

Что такое DAU

DAU, daily active users, показывает, сколько уникальных пользователей совершили значимое действие в продукте за один день. Ключевое слово здесь не “день”, а “значимое”. Для игры это может быть старт сессии или завершение уровня, для SaaS — работа в основном сценарии, для маркетплейса — поиск, просмотр товара, сообщение продавцу или заказ.

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

Как выбрать active action

Фраза “активный пользователь — это любой пользователь с событием” почти всегда опасна. В event stream живут технические события: открытие экрана, refresh токена, автосинхронизация, push_received. Если они попадают в DAU, метрика начинает показывать шум инфраструктуры, а не поведение людей.

Выбор active action зависит от сценария и частоты продукта. Ежедневная игра, B2B-отчётность раз в неделю и маркетплейс с длинным циклом покупки не должны жить под одним определением активности. Чем реже нормальный пользователь возвращается, тем аккуратнее нужно читать дневную метрику.

SQL для DAU

Минимальный запрос должен считать одного пользователя один раз в день, даже если он сделал десять событий. В примере ниже таблица events имеет зерно “одно событие”, а occurred_at уже хранится в бизнесовой таймзоне или заранее приведён к ней. Запрос берёт 30 полных дней и не смешивает сегодняшний неполный день с историей.

with active_events as (
  select
    date_trunc('day', occurred_at)::date as day,
    user_id
  from events
  where occurred_at >= current_date - interval '30 days'
    and occurred_at < current_date
    and event_name in ('session_start', 'core_action_completed')
    and user_id is not null
)
select
  day,
  count(distinct user_id) as dau
from active_events
group by 1
order by 1;

Почему DAU нужно делить на новых и вернувшихся

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

Поэтому рядом с DAU почти всегда стоит смотреть new DAU и returning DAU. Если растут только новые, нужно смотреть закупку, активацию и качество каналов. Если проседают вернувшиеся, разговор уже про продуктовую ценность, качество релиза, сезонность или retention.

• new DAU: пользователь впервые стал активным в этот день;
• returning DAU: пользователь уже был активен раньше и вернулся сегодня;
• resurrected users: пользователь вернулся после длинной паузы.

Когда рост DAU обманывает

Рост DAU не всегда хорошая новость. Он может появиться после агрессивных пушей, распродажи, рекламной волны или изменения трекинга. Если вместе с DAU не растёт core action rate, retention или выручка, команда радуется активности, которая не превращается в ценность.

Сильный аналитический вывод звучит не “DAU вырос на 12%”, а так: “DAU вырос на 12%, но рост пришёл из новых paid-пользователей; returning DAU не изменился, D7 ниже среднего, поэтому это сигнал качества трафика, а не улучшения продукта”.

• Смотри DAU по каналам и платформам.
• Сравни новых и вернувшихся пользователей.
• Проверь DAU/MAU, но не используй его без контекста частоты продукта.
• Сопоставь DAU с retention, revenue, core action rate или конверсией.

Чеклист аналитика

Перед тем как отправить DAU в отчёт или дашборд, пройди короткий контрольный список. Это скучная часть работы, но она занимает меньше времени, чем потом объяснять команде, почему метрика месяц считалась неправильно.

• Определено ли active action и согласна ли с ним продуктовая команда?
• Пользователь считается один раз в день, а не по количеству событий?
• Исключены ли боты, тестовые аккаунты, сотрудники и технические события?
• Понятна ли таймзона и граница дня?
• Есть ли разрезы по новым, вернувшимся, каналам, платформам и когортам?
• Есть ли соседняя метрика, которая подтверждает продуктовую ценность?

Как выбрать действие для разных продуктов

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

Иногда одного события недостаточно. Для сервиса аналитики активностью может быть не просто открытие дашборда, а просмотр виджета с последующим запуском запроса. Для игры — не app_open, а начало полноценной сессии. Для маркетплейса — не показ пуша, а поиск, просмотр карточки или сообщение продавцу. Такой выбор делает DAU ближе к реальному поведению, но требует договорённости с продуктом и стабильного трекинга.

Как разложить изменение DAU до рабочего решения

Для диагностики удобно двигаться от общего числа к четырём слоям. Сначала проверь общий DAU и границу периода. Затем раздели пользователей на новых, вернувшихся и воскресших. После этого посмотри платформу, канал и версию продукта. В конце сравни долю пользователей, которые сделали core action, и их ближайшее возвращение. Такой порядок помогает не перепутать рост охвата с ростом ценности.

Представь, что DAU вырос на 18% после рекламной кампании. Если 80% прироста дали новые пользователи, а returning DAU и D7 не изменились, решение должно быть маркетинговым: проверить качество закупки и обещание объявления. Если просели только iOS-пользователи после релиза, сначала нужен технический разбор. Если DAU вырос и одновременно выросла доля core action, D7 и выручка на активного пользователя, можно обсуждать продуктовую гипотезу увереннее.

• Сначала зафиксируй абсолютное изменение и период.
• Отдельно сравни новых, returning и resurrected пользователей.
• Найди сегмент, который объясняет большую часть разницы.
• Проверь качество активности: core action rate, ошибки и время в сценарии.
• Назначь следующий шаг: трекинг, канал, релиз или продуктовый эксперимент.

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

Для базовой сверки полезно посмотреть, как DAU объясняют продуктовые аналитические платформы и маркетинговые инструменты. Но финальное определение всё равно должно исходить из механики конкретного продукта. Если продукт зарабатывает не на открытии приложения, открытие приложения не должно быть главным доказательством активности.