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

Что такое DAU и зачем его считать

DAU — Daily Active Users. Сколько уникальных пользователей сделали определённое действие за календарные сутки. Базовая метрика вовлечённости почти любого продукта, особенно с ежедневным сценарием использования: соцсетей, мессенджеров, игр, тренажёров.

Зачем считать:

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

DAU не одинок. Обычно идёт в паре с MAU (Monthly Active Users) и WAU (Weekly Active Users). Соотношение DAU/MAU называется stickiness — насколько часто среднестатистический активный пользователь возвращается. Это отдельная метрика, разберём её в другом материале.

Главное помнить: DAU — это про "приходят", а не про "довольны". Высокий DAU не означает счастье, низкий — не всегда катастрофа.

Что считать активным пользователем

Самая важная и недооценённая часть. От определения "активного" зависит всё остальное.

Возможные определения:

• Залогинился.
• Открыл приложение.
• Сделал любое целевое действие.
• Сделал ключевое действие (например, прошёл задачу в тренажёре).

Чем строже определение — тем меньше DAU, но честнее. "Залогинился" — слабый сигнал, особенно если стоит автологин. "Прошёл хотя бы 1 задачу" — гораздо ближе к реальности.

Хорошая практика — выбрать одно "северное звёздное" действие и считать DAU по нему. В Карьернике, например, имеет смысл считать DAU как "юзеры, которые ответили хотя бы на один вопрос за день", а не просто "открывшие бот". Открытие — это часть воронки, не активность.

Определение фиксируем в одном месте (метрик-словарь, dbt, доке) и не меняем без объявления. Иначе графики ломаются и начинаются священные войны "у меня по другому считается".

Как считать DAU в SQL

Базовый шаблон по таблице событий:

SELECT
  DATE(event_time AT TIME ZONE 'Europe/Moscow') AS day,
  COUNT(DISTINCT user_id) AS dau
FROM events
WHERE event_name = 'question_answered'
  AND event_time >= NOW() - INTERVAL '60 day'
GROUP BY 1
ORDER BY 1;

Несколько важных моментов:

• COUNT(DISTINCT user_id) — обязательно distinct, иначе посчитаем события, а не уникальных юзеров.
• DATE(... AT TIME ZONE ...) — считаем по таймзоне продукта, не по UTC. Иначе получим "ползущие" сутки.
• Фильтр по event_name — определяет, что у нас "активность".
• Окно 60 day — для графика, не для одного дня.

Если хочется одной строкой получить DAU за вчера:

SELECT COUNT(DISTINCT user_id) AS dau_yesterday
FROM events
WHERE event_name = 'question_answered'
  AND event_time >= (CURRENT_DATE - 1) AT TIME ZONE 'Europe/Moscow'
  AND event_time <  CURRENT_DATE AT TIME ZONE 'Europe/Moscow';

При больших объёмах оптимизируйте через предагрегированную таблицу daily_user_activity — пересчитывать DISTINCT по сырому event-логу каждый раз дорого.

Как читать график DAU

DAU редко смотрят как одно число — почти всегда как тренд за 30/60/90 дней. На графике важно видеть три вещи:

1. Тренд. Растёт, стабилен, падает.
2. Сезонность. Дни недели и праздники: понедельник обычно выше воскресенья, в России 1–10 января — провал.
3. Аномалии. Резкие скачки часто означают баги (двойной счёт, релиз, отвалившийся ETL), а не реальный рост.

Полезно накладывать DAU и 7-дневный rolling average — резкие шумы уходят, виден реальный тренд.

Не сравнивайте день к дню — сравнивайте неделю к неделе или day-of-week к day-of-week. Среда к среде, а не среда к воскресенью.

Чем DAU обманывает

DAU — не самая надёжная метрика, если смотреть на неё в одиночку.

Несколько типичных ловушек:

• Низкое определение активности. Считаем "открыл" — DAU красивый, retention врёт.
• Боты и сервисы. Если у вас публичные ручки, в DAU может попасть мониторинг и боты.
• Скрытое падение качества. DAU стабилен, но половина пользователей — новые из платного трафика, старые отваливаются. Это виден только в cohort-анализе.
• Маркетинговая накачка. Запустили кампанию, DAU вырос, через 2 недели вернулся — вы не выросли, вы просто покрутили волну.
• Технические инциденты. Релиз сломал часть событий — DAU "просел", хотя на самом деле всё нормально.

Поэтому DAU всегда смотрят в связке: с retention, с stickiness, с cohort-анализом, с outcome-метриками (доход, ключевые действия).

Частые ошибки

• COUNT вместо COUNT DISTINCT. Считаем события, не уникальных юзеров.
• UTC вместо локальной таймзоны. Сутки сдвинуты, графики кривые.
• Менялось определение активности, никто не сказал. Падение или рост на графике — не всегда продукт, иногда логика.
• Сравнивают DAU день к дню. Без учёта дня недели сравнение бесполезно.
• DAU без MAU и retention. Одна метрика не показывает картину.
• Игнорируют ботов. Особенно болезненно для open API.

Связанные темы

• MAU: как считать и интерпретировать
• DAU/MAU stickiness
• Что такое product analytics
• Cohort analysis простыми словами

FAQ

Что лучше — считать DAU по логину или по ключевому действию?

По ключевому действию. Логин — слабый сигнал, особенно при автологине.

Можно ли считать DAU по сессиям?

Можно как дополнение, но основная метрика — уникальные юзеры за сутки. Сессии полезны для отдельной аналитики.

Какой нормальный DAU?

"Нормального" нет — зависит от продукта и сегмента. Смотрите на тренд и DAU/MAU, а не на абсолютное число.

Как часто пересчитывать DAU?

Раз в сутки в ETL после закрытия дня в нужной таймзоне. Real-time DAU обычно не нужен.

DAU надо считать по новым или по всем юзерам?

По всем активным. Отдельно полезно смотреть DAU только новых и DAU старых — это даёт сигнал о здоровье когорт.

Когда DAU плохой ориентир?

Когда продукт не предполагает ежедневное использование (например, B2B-сервис подачи отчётности). Тогда лучше WAU или MAU.

---

Хочешь прокачать продуктовые метрики? Открой тренажёр Карьерника — задачи на DAU, retention, stickiness и SQL.