Когда человек только заходит в аналитику продукта, метрик вокруг сразу слишком много. DAU, MAU, retention, conversion, stickiness, ARPU, churn — все звучит знакомо, но в реальной работе часто путается:

  • что именно считать
  • за какой период считать
  • кого считать активным пользователем
  • почему метрика выросла, а бизнесу от этого не стало лучше

В этой статье разберем базовые продуктовые метрики спокойно и по-человечески: что они означают, как считаются, как читать их правильно и на каких местах чаще всего ошибаются.

1. Что такое продуктовые метрики

Продуктовые метрики — это численные показатели, которые помогают понять:

  • сколько людей пользуются продуктом
  • как часто они возвращаются
  • совершают ли полезные действия
  • приносят ли деньги
  • удерживает ли продукт аудиторию

Если очень упростить, то почти все метрики можно разделить на несколько блоков:

  • метрики аудитории: DAU, WAU, MAU
  • метрики вовлеченности: сессии, глубина, stickiness
  • метрики воронки: conversion rate
  • метрики удержания: retention, churn
  • денежные метрики: ARPU, ARPPU, LTV

Начнем с самого частого вопроса: что такое DAU, WAU и MAU.

2. Что такое DAU, WAU и MAU

Эти метрики показывают, сколько уникальных активных пользователей было у продукта за определенный период.

  • DAU — Daily Active Users, активные пользователи за день
  • WAU — Weekly Active Users, активные пользователи за неделю
  • MAU — Monthly Active Users, активные пользователи за месяц

Ключевое слово тут не просто “пользователи”, а именно активные.

3. Кто такой активный пользователь

Вот здесь и начинается самая важная часть.

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

Например:

  • открыл приложение и дошел до главного экрана
  • выполнил поиск
  • создал заказ
  • отправил сообщение
  • построил отчет
  • загрузил файл

Если определение активности выбрано плохо, то и DAU/WAU/MAU будут мало о чем говорить.

Пример плохого определения

Если считать активным любого, у кого сработал технический page_view, можно случайно включить:

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

Пример хорошего определения

Активным считается пользователь, который зашел в продукт и сделал одно из ключевых действий:

  • просмотрел дашборд
  • применил фильтр
  • экспортировал отчет
  • сохранил результат

То есть метрика начинает отражать не просто трафик, а реальное использование продукта.

4. Формулы DAU, WAU и MAU

Если у нас есть таблица событий, где каждый ряд — действие пользователя, то:

  • DAU = COUNT(DISTINCT user_id) за конкретный день
  • WAU = COUNT(DISTINCT user_id) за последние 7 дней
  • MAU = COUNT(DISTINCT user_id) за последние 30 дней или за календарный месяц — в зависимости от логики компании

Очень важно заранее договориться, что именно значит MAU:

  • за последние 30 дней
  • за календарный месяц

Это не одно и то же.

5. Простой пример на данных

Допустим, у нас есть такие события:

event_date user_id event_name
2026-04-01 101 login
2026-04-01 102 login
2026-04-01 101 create_report
2026-04-02 101 login
2026-04-02 103 login
2026-04-02 104 login
2026-04-03 101 login
2026-04-03 102 export
2026-04-03 104 login

DAU за 2026-04-01

Активные пользователи: 101, 102

DAU = 2

DAU за 2026-04-02

Активные пользователи: 101, 103, 104

DAU = 3

WAU за период 2026-04-01 … 2026-04-03

Уникальные пользователи за весь период:

  • 101
  • 102
  • 103
  • 104

WAU = 4

Обрати внимание: WAU — это не сумма дневных DAU.

Потому что один и тот же пользователь может заходить в несколько дней подряд.

6. Почему нельзя складывать DAU

Это одна из самых частых ошибок новичков.

Допустим:

  • в понедельник DAU = 100
  • во вторник DAU = 120
  • в среду DAU = 110

Это не значит, что за 3 дня было 330 уникальных пользователей.

Причина простая: один и тот же человек мог зайти во все три дня.

Поэтому:

  • сумма DAU показывает объем дневной активности
  • WAU/MAU показывают число уникальных людей за период

Это разные сущности.

7. SQL: как посчитать DAU

Представим таблицу events:

SELECT
    event_time,
    user_id,
    event_name
FROM events

Тогда DAU можно посчитать так:

SELECT
    CAST(event_time AS DATE) AS event_date,
    COUNT(DISTINCT user_id) AS dau
FROM events
GROUP BY CAST(event_time AS DATE)
ORDER BY event_date;

Если активностью считается не любое событие, а только полезные:

SELECT
    CAST(event_time AS DATE) AS event_date,
    COUNT(DISTINCT user_id) AS dau
FROM events
WHERE event_name IN ('login', 'create_report', 'export')
GROUP BY CAST(event_time AS DATE)
ORDER BY event_date;

8. SQL: как посчитать WAU и MAU

Если нужен WAU по каждому дню как rolling-метрика, логика такая:

  • берем текущий день
  • смотрим назад на 6 дней плюс текущий
  • считаем уникальных пользователей

В чистом SQL реализация зависит от базы. Универсальный вариант через self join может выглядеть так:

WITH daily_events AS (
    SELECT DISTINCT
        CAST(event_time AS DATE) AS event_date,
        user_id
    FROM events
),
calendar AS (
    SELECT DISTINCT event_date
    FROM daily_events
)
SELECT
    c.event_date,
    COUNT(DISTINCT d.user_id) AS wau
FROM calendar c
JOIN daily_events d
    ON d.event_date BETWEEN c.event_date - INTERVAL '6 day' AND c.event_date
GROUP BY c.event_date
ORDER BY c.event_date;

Аналогично для MAU, только окно уже будет шире:

WITH daily_events AS (
    SELECT DISTINCT
        CAST(event_time AS DATE) AS event_date,
        user_id
    FROM events
),
calendar AS (
    SELECT DISTINCT event_date
    FROM daily_events
)
SELECT
    c.event_date,
    COUNT(DISTINCT d.user_id) AS mau
FROM calendar c
JOIN daily_events d
    ON d.event_date BETWEEN c.event_date - INTERVAL '29 day' AND c.event_date
GROUP BY c.event_date
ORDER BY c.event_date;

Если в компании MAU считают по календарному месяцу, то запрос будет другим:

SELECT
    DATE_TRUNC('month', event_time) AS month_start,
    COUNT(DISTINCT user_id) AS mau
FROM events
GROUP BY DATE_TRUNC('month', event_time)
ORDER BY month_start;

9. Что такое stickiness

Stickiness показывает, насколько часто месячная аудитория возвращается в продукт.

Чаще всего используют формулу:

Stickiness = DAU / MAU

Иногда умножают на 100%.

Пример

Если:

  • DAU = 2 000
  • MAU = 10 000

То:

Stickiness = 2 000 / 10 000 = 0.2 = 20%

Это значит, что в среднем дневная активная аудитория составляет 20% от месячной.

Как интерпретировать

  • чем выше DAU/MAU, тем чаще пользователи возвращаются
  • но сравнивать надо только похожие продукты

Например:

  • у банковского приложения один нормальный ритм использования
  • у корпоративного BI-сервиса другой
  • у мессенджера третий

Нельзя сказать, что “20% — всегда плохо” или “40% — всегда хорошо” без контекста.

10. Что такое retention

Retention показывает, какая доля пользователей вернулась через определенное время после первого визита или первого целевого действия.

И здесь очень важный момент, который часто путают:

Retention почти всегда считается не по всем пользователям продукта сразу, а по конкретной когорте.

Когорта — это группа пользователей, объединенных общим признаком. Чаще всего:

  • по дате первой регистрации
  • по дате первой покупки
  • по дате первого запуска
  • по источнику привлечения
  • по стране
  • по платформе

Когда говорят, например, про Day 7 retention, обычно имеют в виду:

  • взяли пользователей, которые впервые пришли в продукт в конкретный день
  • посмотрели, сколько из них вернулось через 7 дней
  • разделили число вернувшихся на размер исходной когорты

То есть в знаменателе стоят именно пользователи из исходной когорты, а не все пользователи продукта.

Самые частые варианты:

  • Day 1 retention
  • Day 7 retention
  • Day 30 retention

Формула

Retention Day N = 
кол-во пользователей, вернувшихся в день N
/ 
кол-во пользователей в исходной когорте

Кого именно мы рассматриваем

Допустим, 1 апреля зарегистрировались 100 новых пользователей.

Это и есть наша когорта.

Дальше мы смотрим только на этих 100 человек:

  • сколько из них вернулось 2 апреля
  • сколько из них вернулось 8 апреля
  • сколько из них вернулось 30 апреля

Пользователи, которые зарегистрировались 2 апреля, 3 апреля или раньше марта, в этот расчет уже не входят.

Пример

В продукт 1 апреля пришло 100 новых пользователей.

  • 2 апреля вернулось 35
  • 8 апреля вернулось 18
  • 30 апреля вернулось 9

Тогда:

  • D1 retention = 35%
  • D7 retention = 18%
  • D30 retention = 9%

Retention отвечает на очень важный вопрос: продукт нужен людям или они исчезают после первого касания.

Почему retention почти всегда когортный

Если брать “всех пользователей сразу”, метрика становится размытой:

  • в продукте смешиваются старые и новые пользователи
  • часть аудитории уже очень лояльна
  • часть только пришла
  • маркетинг мог резко поменять состав трафика

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

Именно поэтому retention обычно считают по когортам.

10.1. Основные виды retention

На практике retention считают не одним способом, а несколькими. И это важно, потому что цифры могут отличаться очень сильно.

Classic retention

Это самый строгий вариант.

Он отвечает на вопрос: вернулся ли пользователь ровно в день N.

Пример:

  • пользователь пришел 1 апреля
  • зашел снова 8 апреля
  • значит, он попадает в D7 retention
  • если он зашел 7 апреля или 9 апреля, а 8 апреля не зашел, то в строгий D7 retention он уже не попадет

Такой вариант часто используют в продуктах, где важен конкретный ритм возврата.

Rolling retention

Этот вариант мягче.

Он отвечает на вопрос: вернулся ли пользователь в день N или позже.

Пример:

  • пользователь пришел 1 апреля
  • для D7 rolling retention мы проверяем, был ли он активен начиная с 8 апреля и позже
  • если он зашел 10 апреля, он уже считается удержанным

Rolling retention обычно выше, чем classic retention.

Unbounded retention

По смыслу он похож на rolling retention, но часто акцент делается на том, что пользователь вернулся хотя бы один раз после определенного срока.

Например:

  • был ли пользователь активен после 30-го дня
  • сделал ли он хотя бы одно повторное целевое действие после 7-го дня

Bracket retention

Иногда retention считают не по конкретному дню, а по диапазону.

Например:

  • вернулся ли пользователь в интервале 1-7 день
  • вернулся ли пользователь в интервале 8-30 день

Это удобно, когда продуктом пользуются не каждый день, а реже.

Retention по событию, а не по логину

Иногда недостаточно просто проверить, что пользователь “зашел”.

Полезнее считать:

  • сделал ли повторную покупку
  • создал ли второй отчет
  • отправил ли второй заказ
  • вернулся ли к использованию ключевой функции

Такой retention обычно ближе к бизнес-смыслу продукта.

10.2. Пример, как один и тот же набор пользователей дает разный retention

Пусть есть когорта из 5 пользователей, которые пришли 1 апреля.

user_id первый визит повторный визит
101 2026-04-01 2026-04-02
102 2026-04-01 2026-04-08
103 2026-04-01 2026-04-10
104 2026-04-01 нет
105 2026-04-01 2026-04-20

Тогда:

  • D1 classic retention = 1 / 5 = 20%
  • D7 classic retention = 1 / 5 = 20%, потому что ровно на 8 апреля вернулся только 102
  • D7 rolling retention = 3 / 5 = 60%, потому что 102, 103 и 105 вернулись на 7-й день или позже

Это очень важное место: если не уточнить вид retention, можно сравнить две цифры, которые на самом деле считаются по разной логике.

10.3. SQL-пример retention по когорте

Пусть у нас есть таблица событий:

SELECT
    user_id,
    CAST(event_time AS DATE) AS event_date
FROM events

Ниже пример идеи для D1 retention по когорте первого визита:

WITH first_touch AS (
    SELECT
        user_id,
        MIN(CAST(event_time AS DATE)) AS first_date
    FROM events
    GROUP BY user_id
),
activity AS (
    SELECT DISTINCT
        user_id,
        CAST(event_time AS DATE) AS event_date
    FROM events
)
SELECT
    f.first_date AS cohort_date,
    COUNT(DISTINCT f.user_id) AS cohort_size,
    COUNT(DISTINCT a.user_id) AS retained_users_d1,
    1.0 * COUNT(DISTINCT a.user_id) / NULLIF(COUNT(DISTINCT f.user_id), 0) AS d1_retention
FROM first_touch f
LEFT JOIN activity a
    ON a.user_id = f.user_id
   AND a.event_date = f.first_date + INTERVAL '1 day'
GROUP BY f.first_date
ORDER BY cohort_date;

По такой же логике можно считать D7, D30 и строить retention-таблицу по когортам.

10.4. Когда какой retention уместен

  • Day 1 / Day 7 / Day 30 classic retention хорошо подходит для продуктовых команд, где важна дисциплина возврата
  • rolling retention полезен, когда продуктом пользуются нерегулярно
  • event-based retention лучше подходит там, где важен не сам визит, а повторное полезное действие

Главное правило простое: retention должен отражать реальную ценность продукта, а не просто факт открытия приложения.

11. Что такое churn

Churn — это отток пользователей.

Проще говоря, это доля пользователей, которые перестали пользоваться продуктом.

Одна из логик расчета:

Churn rate = 
кол-во ушедших пользователей
/
кол-во пользователей в начале периода

Пример:

  • в начале месяца было 1 000 активных клиентов
  • 120 перестали пользоваться продуктом

Тогда:

Churn = 120 / 1 000 = 12%

Retention и churn часто идут рядом:

  • retention показывает, кто остался
  • churn показывает, кто ушел

12. Что такое conversion rate

Conversion rate показывает, какая доля пользователей дошла до нужного целевого действия.

Формула

Conversion rate =
кол-во пользователей, совершивших целевое действие
/
кол-во пользователей, вошедших в этап воронки

Пример

На сайт пришло 5 000 пользователей:

  • 800 зарегистрировались
  • 240 оформили подписку

Тогда:

  • конверсия в регистрацию = 800 / 5 000 = 16%
  • конверсия в оплату от всех посетителей = 240 / 5 000 = 4.8%
  • конверсия из регистрации в оплату = 240 / 800 = 30%

Очень важно всегда проговаривать, из чего именно считается конверсия.

13. Что такое ARPU и ARPPU

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

ARPU

ARPU = Average Revenue Per User

Средняя выручка на одного пользователя.

ARPU = revenue / users

Пример:

  • выручка за месяц = 500 000
  • пользователей = 20 000
ARPU = 500 000 / 20 000 = 25

ARPPU

ARPPU = Average Revenue Per Paying User

Средняя выручка только на платящего пользователя.

ARPPU = revenue / paying_users

Если из 20 000 пользователей платили только 2 000:

ARPPU = 500 000 / 2 000 = 250

Это уже совсем другой взгляд на монетизацию.

14. Что такое LTV

LTV — Lifetime Value, суммарная ценность пользователя за все время жизни в продукте.

Считать LTV можно по-разному, от очень грубых оценок до продвинутых моделей.

Один из простых подходов:

LTV = ARPU * средняя длительность жизни пользователя

Или:

LTV = средний доход от пользователя за период * число периодов жизни

Но в реальной жизни этого объяснения обычно мало, потому что сразу возникают вопросы:

  • за какой период брать доход
  • каких пользователей брать в расчет
  • считать выручку или прибыль
  • как учитывать retention
  • что делать с пользователями, которые еще не “дожили” до конца жизненного цикла

14.1. Что именно показывает LTV

LTV отвечает на вопрос:

Сколько ценности в среднем приносит один пользователь за все время жизни в продукте.

В зависимости от задачи под ценностью могут понимать:

  • выручку
  • валовую прибыль
  • маржинальный доход

Для быстрой аналитики часто используют именно выручку. Для финансовых решений лучше смотреть на более “чистую” экономику, например contribution margin.

14.2. Самый простой расчет LTV

Самая базовая идея:

LTV = средний доход за период * среднее число периодов жизни

Например:

  • пользователь в среднем приносит 300 рублей в месяц
  • средняя жизнь пользователя — 8 месяцев

Тогда:

LTV = 300 * 8 = 2 400 рублей

Это удобно для быстрой оценки, но очень грубо.

14.3. LTV через ARPU и churn

Есть популярная приближенная формула:

LTV = ARPU / churn

Или, если точнее:

LTV = ARPU * средняя длительность жизни

А среднюю длительность жизни иногда грубо оценивают как:

Lifetime = 1 / churn

Пример

Пусть:

  • ARPU = 500 рублей в месяц
  • месячный churn = 0.1

Тогда:

Lifetime = 1 / 0.1 = 10 месяцев
LTV = 500 / 0.1 = 5 000 рублей

Это удобная модель, но она опирается на сильные допущения:

  • churn относительно стабилен
  • выручка по периодам примерно стабильна
  • поведение пользователей не меняется радикально между когортами

В живом продукте это не всегда так.

14.4. Почему когортный LTV обычно полезнее

Сильнее всего LTV раскрывается, когда его считают по когортам.

Например:

  • пользователи, пришедшие в январе
  • пользователи, пришедшие в феврале
  • пользователи из рекламы
  • пользователи из органики

Тогда можно увидеть:

  • какая когорта дольше живет
  • какая когорта платит больше
  • какой канал приводит более ценных пользователей

Пример

Есть две когорты по 100 пользователей.

Когорта A:

  • средняя выручка за весь срок на пользователя = 1 800

Когорта B:

  • средняя выручка за весь срок на пользователя = 900

Если стоимость привлечения у них одинаковая, то когорта A в два раза ценнее для бизнеса.

14.5. Как считать LTV на практике

Есть как минимум три рабочих подхода.

1. Исторический LTV

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

Historical LTV =
суммарная выручка когорты
/
число пользователей в когорте

Это самый понятный и честный вариант, но он плохо работает для свежих когорт, потому что они еще не успели “дозреть”.

2. Предиктивный LTV

Пытаемся предсказать будущую ценность пользователя по ранним сигналам:

  • источник привлечения
  • первые действия
  • частота использования
  • ранние покупки

Это уже более продвинутая задача, часто с участием data science.

3. Грубый бизнесовый LTV

Когда нужна быстрая оценка на уровне стратегии, используют приближенные формулы через ARPU, churn и средний lifetime.

Этот вариант подходит для первого приближения, но не для точной финансовой модели.

14.6. SQL-идея для исторического LTV по когорте

Допустим, есть таблица платежей:

SELECT
    user_id,
    payment_date,
    revenue
FROM payments

И есть дата первого появления пользователя в продукте.

Тогда исторический LTV по месячным когортам можно посчитать примерно так:

WITH first_touch AS (
    SELECT
        user_id,
        DATE_TRUNC('month', MIN(event_time)) AS cohort_month
    FROM events
    GROUP BY user_id
),
cohort_revenue AS (
    SELECT
        f.cohort_month,
        f.user_id,
        COALESCE(SUM(p.revenue), 0) AS lifetime_revenue
    FROM first_touch f
    LEFT JOIN payments p
        ON p.user_id = f.user_id
    GROUP BY f.cohort_month, f.user_id
)
SELECT
    cohort_month,
    COUNT(*) AS users_cnt,
    SUM(lifetime_revenue) AS total_revenue,
    AVG(lifetime_revenue) AS ltv
FROM cohort_revenue
GROUP BY cohort_month
ORDER BY cohort_month;

Смысл здесь простой:

  • находим когорту пользователя
  • собираем всю выручку, которую он принес
  • усредняем по пользователям внутри когорты

14.7. Почему LTV нельзя смотреть без CAC

Сам по себе LTV полезен, но бизнес-решение обычно принимают через сравнение с CAC.

CAC — это стоимость привлечения клиента.

Если:

  • LTV = 5 000
  • CAC = 7 000

то экономика плохая: пользователь приносит меньше, чем стоит его привлечение.

Если:

  • LTV = 5 000
  • CAC = 1 500

то модель может быть очень здоровой.

Поэтому в реальном бизнесе часто смотрят не просто на LTV, а на:

  • LTV/CAC
  • срок окупаемости привлечения
  • retention платящих пользователей

14.8. Частые ошибки при расчете LTV

  • смешивать выручку и прибыль
  • считать слишком свежие когорты и сравнивать их со старыми
  • не учитывать возвраты, отмены, скидки
  • считать LTV по всем пользователям, когда бизнес-логика требует считать по платящим
  • делать выводы по одной усредненной цифре без разрезов по каналам и когортам

Метрика полезная, но ее часто считают слишком грубо и потом делают из этого слишком смелые выводы.

15. Какие метрики смотреть вместе

Одна метрика почти никогда не дает полной картины.

Лучше смотреть связки.

Для роста аудитории

  • DAU
  • WAU
  • MAU
  • новые пользователи
  • источники трафика

Для вовлеченности

  • DAU/MAU
  • число сессий на пользователя
  • средняя длина сессии
  • глубина взаимодействия

Для удержания

  • retention
  • churn
  • доля повторных пользователей

Для воронки

  • посещение
  • регистрация
  • активация
  • оплата

Для монетизации

  • ARPU
  • ARPPU
  • LTV
  • доля платящих пользователей

16. Частые ошибки при работе с DAU, MAU и другими метриками

Вот где аналитики особенно часто спотыкаются.

Ошибка 1. Не договориться, кто считается активным

Если сегодня активный пользователь — это любой page_view, а завтра — только purchase, метрика становится несравнимой.

Ошибка 2. Сравнивать несопоставимые периоды

Например:

  • будний день с выходным
  • февраль с декабрем
  • обычную неделю с промо-неделей

Без контекста такие сравнения могут ввести в заблуждение.

Ошибка 3. Складывать уникальных пользователей

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

Ошибка 4. Не учитывать сезонность

У продукта могут быть:

  • выходные провалы
  • рост в конце месяца
  • всплески в дни зарплаты
  • сезонный спрос

Иногда “падение” — это просто нормальный ритм бизнеса.

Ошибка 5. Смотреть только на объем, но не на качество

Допустим, DAU вырос. Звучит хорошо.

Но если:

  • retention падает
  • конверсия ухудшается
  • платящая аудитория не растет

то рост аудитории сам по себе еще не означает успех.

Ошибка 6. Менять логику трекинга и забыть об этом

Если разработчики поменяли события, часть пользователей могла “исчезнуть” из метрик не потому, что продукт стал хуже, а потому что сломалась логика учета.

17. Пример продуктового чтения метрик

Представим такую картину:

  • MAU вырос с 40 000 до 55 000
  • DAU вырос с 4 000 до 4 500
  • DAU/MAU упал с 10% до 8.2%
  • D7 retention упал с 24% до 17%

На первый взгляд кажется, что все хорошо: месячная аудитория выросла.

Но если смотреть глубже:

  • люди приходят
  • но возвращаются хуже
  • вовлеченность снижается

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

Вот почему сильный аналитик смотрит не на одну метрику, а на систему метрик.

18. SQL-пример: DAU, registrations, conversion в одном запросе

Пусть есть таблица событий:

SELECT
    event_time,
    user_id,
    event_name
FROM events

Тогда базовый дневной срез можно посчитать так:

SELECT
    CAST(event_time AS DATE) AS event_date,
    COUNT(DISTINCT user_id) AS dau,
    COUNT(DISTINCT CASE WHEN event_name = 'sign_up' THEN user_id END) AS signups,
    COUNT(DISTINCT CASE WHEN event_name = 'purchase' THEN user_id END) AS buyers
FROM events
GROUP BY CAST(event_time AS DATE)
ORDER BY event_date;

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

SELECT
    CAST(event_time AS DATE) AS event_date,
    COUNT(DISTINCT user_id) AS dau,
    COUNT(DISTINCT CASE WHEN event_name = 'purchase' THEN user_id END) AS buyers,
    1.0 * COUNT(DISTINCT CASE WHEN event_name = 'purchase' THEN user_id END)
        / NULLIF(COUNT(DISTINCT user_id), 0) AS purchase_conversion_from_dau
FROM events
GROUP BY CAST(event_time AS DATE)
ORDER BY event_date;

19. Как отвечать на собеседовании про DAU и MAU

Если на собеседовании спрашивают, что такое DAU и MAU, хороший ответ звучит примерно так:

DAU и MAU — это число уникальных активных пользователей за день и месяц. Ключевой момент в том, что нужно заранее определить, какое действие считать активностью. Сам расчет обычно идет через COUNT(DISTINCT user_id), но интерпретировать метрики отдельно от retention, conversion и stickiness опасно, потому что рост аудитории не всегда означает рост ценности продукта.

Такой ответ сразу показывает, что ты понимаешь:

  • формулу
  • бизнес-смысл
  • ограничения метрики

20. Какие метрики точно стоит знать junior аналитику

Если брать минимум, который реально стоит держать в голове, это:

  • DAU
  • WAU
  • MAU
  • stickiness
  • retention
  • churn
  • conversion rate
  • ARPU
  • ARPPU

А если работа связана с продуктовой аналитикой, то без этих метрик уже трудно принимать адекватные решения.

Вывод

DAU, WAU и MAU — это не просто модные аббревиатуры, а базовый язык продуктовой аналитики. Но сами по себе они почти ничего не значат, если не определить, кто считается активным пользователем, не учесть retention, не проверить конверсию и не посмотреть на качество аудитории.

Хороший аналитик не просто умеет посчитать метрику. Он понимает:

  • что именно стоит за числом
  • как это число появилось
  • можно ли ему доверять
  • какое бизнес-решение из него вообще следует

Именно это и отличает механический расчет от настоящей аналитики.