DAU/WAU/MAU: сколько было живых

Слово, которое встречается в журнале Л. 214 раз

Дело не закроется, пока ты не выучишь язык, на котором оно написано. Начнём со слова DAU. — КВЕРИ

DAU (daily active users) — сколько уникальных пользователей были активны за день. WAU — за неделю, MAU — за месяц.

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

Цепочка: журнал → число

1. Берём журнал событий — строки с действиями пользователей.
2. Фильтруем период: оставляем строки, у которых время попадает в нужный день.
3. Фильтруем событие активности: оставляем только те строки, событие которых считается «активностью» по нашему определению.
4. Оставляем колонку user_id: всё остальное — время, сессии, свойства — больше не нужно.
5. Удаляем повторы: один пользователь = одна запись, сколько бы строк он ни оставил.
6. Считаем, сколько записей осталось. Это и есть DAU.

Пройдём по фрагменту журнала 14 марта из прошлого урока, взяв за активность app_open:

шаг 1: 9 строк журнала
шаг 2: все 9 — это один день
шаг 3: остаются только app_open → 4 строки (4412 утром, 7781, 4412 днём, 9003)
шаг 4: user_id → 4412, 7781, 4412, 9003
шаг 5: убираем повтор 4412 → 4412, 7781, 9003
шаг 6: DAU = 3

Обрати внимание на шаг 5. Кот 4412 открывал приложение дважды — утром и днём. В DAU он входит один раз. Именно поэтому DAU ≠ число запусков приложения и ≠ число сессий.

По той же причине WAU — это не сумма семи DAU. Кот, заходивший каждый день, даст 7 в сумму DAU и 1 в WAU:

        Пн Вт Ср Чт Пт Сб Вс
Барсик:  ●  ●  ●  ●  ●  ●  ●
Муся:    ●  ○  ●  ○  ●  ○  ●
Рыжик:   ●  ●  ○  ○  ○  ●  ●
DAU:     3  2  2  1  2  2  3   → сумма DAU = 15
                               → WAU = 3 (уникальных кота всего трое)

Отношение среднего DAU за неделю к WAU — самостоятельная метрика: она показывает, какая доля недельной аудитории активна в среднем за день. Чем ближе отношение к единице, тем больше дней в течение недели в среднем активен пользователь из недельной аудитории.

«Активный» — это конструкция, а не факт

Шаг 3 цепочки скрывает главное решение: какое событие считается активностью. В журнале нет колонки «активен: да/нет». Есть только события, и кто-то должен решить, какие из них означают активность пользователя.

Возьмём один день Котомаркета — 14 марта — и посчитаем DAU три раза по трём определениям. Данные одни и те же, цепочка одна и та же, меняется только шаг 3:

Самое большое число почти в пять раз больше самого маленького. И вот тезис, который стоит перечитать дважды: все три правильны — если именно такое определение выбрано и записано. Это не три попытки угадать «настоящий» DAU. Это три разные метрики, у каждой свой смысл:

• app_open меряет охват продукта: сколько людей вообще открыли его. Полезно, например, для оценки трафика и реакции на пуши;
• product_view меряет вовлечённость: человек не просто открыл продукт, а начал смотреть товары. Это уже более сильный сигнал интереса;
• add_to_cart меряет намерение купить. Это самое строгое из трёх определений и поэтому даёт самое маленькое число.

Л. в журнале спорит с командой: «Человек, который открыл пуш и тут же закрыл, — не активен. Он раздражён. Если мы записываем раздражение в актив, мы врём себе в лицо». Команда оставила app_open, потому что так считали конкуренты и хотелось сохранить сравнимость. Это тоже аргумент; главное, что решение было принято осознанно и записано.

Типичная ошибка — сравнивать DAU двух продуктов, не спросив про определения. «У них DAU миллион, у нас двести тысяч» само по себе ничего не значит, если у них активность = открыл, а у нас = совершил целевое действие. Под одним названием оказываются разные метрики — и прямое сравнение теряет смысл.

Аббревиатура не определяет окно

Второе решение прячется на шаге 2 — в периоде. У слова «неделя» есть как минимум два разных смысла, и они дают разные числа.

Календарное окно. Неделя — это понедельник–воскресенье. Месяц — с первого по последнее число. Такое окно удобно сравнивать («неделя 11 против недели 10») и легко объяснять, но периоды неодинаковы по условиям и длине: в неделе с праздником поведение может отличаться, а февраль короче марта на два или три дня.

Скользящее окно (rolling). «Последние 7 дней, считая сегодняшний» и «последние 30 дней». Такое окно есть у каждого дня — можно построить график rolling WAU по дням. Соседние точки обычно меняются менее резко, потому что шесть из семи дней у них общие: каждый новый день добавляет один день и выбрасывает один.

календарный WAU:   [Пн Вт Ср Чт Пт Сб Вс][Пн Вт Ср Чт Пт Сб Вс]
                    одно число за неделю  следующее число

rolling 7d WAU:    [Пн ... Вс] → [Вт ... Пн] → [Ср ... Вт] → ...
                    новое число КАЖДЫЙ день

Оба варианта законны. Проблема начинается, когда их путают, — а путают их постоянно, потому что называются они одинаково: «WAU».

Фраза «WAU за неделю» ничего не определяет. Аббревиатура говорит про недельный период, но не говорит, где проходят его границы. Спрашивай: календарная неделя или последние 7 дней?

Типичный сценарий беды: на дашборде «Пульта» линия rolling 30d MAU, а в презентации для инвесторов — календарный MAU за прошлый месяц. Числа не сходятся, и полдня уходит на поиск «ошибки», которой нет.

Есть и третья мелочь, которая ломает сравнения, — часовой пояс. Если один отчёт режет сутки по UTC, а другой по московскому времени, граница дня сдвинута на три часа: вечерние и ночные события попадают в разные календарные дни. Поэтому могут различаться и дневные метрики вроде DAU, а на почасовых графиках вдобавок появляются ложные «провалы» и «всплески» около границы суток.

Определение нельзя менять незаметно

Январь. В Котомаркете средний DAU за месяц считают по app_open — выходит 10 000.

Февраль. Новый аналитик решает, что «открыл и закрыл» — не активность, и переключает расчёт на product_view. Средний DAU за месяц падает до 7 500.

На дашборде «Пульта» это выглядит так:

январь  ████████████████████  10 000
февраль ███████████████       7 500   −25%

Руководство видит обвал на четверть и объявляет пожар. Ищут причину неделю: релиз? реклама? конкуренты? сезон?

Но причина — методика. В этом примере продукт не менялся вообще: изменился шаг 3 в цепочке — определение активного пользователя.

Это не гипотетическая история: на ней построена половина «загадочных провалов» в журнале Л. Отсюда — правило, которое сильнее любого дашборда:

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

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

Типичная ошибка — молча «улучшить» расчёт и никому не сказать, потому что новое определение объективно лучше. Даже когда оно действительно лучше, необъявленная смена превращает график в ложь: график обещает сравнимость, а сравнимости нет.

Запись №9 у Л.: «Три раза за год мы искали причину падения, которого не было. Каждый раз это был мой коллега, который что-то улучшил в запросе. Теперь у нас есть правило: любое изменение метрики — запись в журнал изменений и отметка на графике».