10 вопросов по теме «аналитика данных: Метрики» на собеседовании

Короткий ответ: Хорошая метрика измерима, сравнима, понятна и трудно поддаётся накрутке (gameable), а главное — actionable: по ней можно принять решение. KPI — это та же метрика, но привязанная к цели и целевому значению на период; KPI — подмножество метрик, а не синоним.

Подробно:

1. Actionable, а не vanity — метрика должна менять чьё-то решение. Если число выросло, но никто не знает, что делать, — это vanity-метрика.
2. Сравнимость — используй ставки и отношения (конверсия, retention %), а не абсолютные счётчики: они сопоставимы между периодами и сегментами.
3. Устойчивость к накрутке — спрашивай «как это можно нагнать, не создав ценности?». «Клики» легко накрутить, «активированные пользователи» — труднее.
4. Ясное определение — один числитель, один знаменатель, окно и фильтры зафиксированы, иначе две команды считают по-разному.

⚠️ Частая ошибка: называть KPI всё подряд. KPI — это 3–5 метрик, по которым команду реально оценивают; остальное — диагностические метрики.

Короткий ответ: North Star — одна метрика, которая отражает ценность, получаемую пользователем, и которую команда двигает в долгую. Хорошая North Star коррелирует с выручкой, но измеряет реализованную ценность, а не деньги напрямую; входные метрики (inputs) — это рычаги, на которые команда влияет, и которые «лестницей» поднимаются к ней.

Подробно:

1. Отражает ценность, а не активность — например «еженедельно активные команды, отправившие сообщение» (Slack), а не «регистрации».
2. Опережает выручку — растёт раньше денег, поэтому годится как руль.
3. Раскладывается на inputs — North Star = функция нескольких управляемых рычагов; на них и ставят задачи командам.

            NORTH STAR
   (еженедельно активные команды)
        ▲          ▲          ▲
        │          │          │
   новые       активация   удержание
  команды   →  (aha-момент) →  W4
     ▲            ▲             ▲
  трафик      онбординг     вовлечённость

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

⚠️ Частая ошибка: брать North Star, равную выручке или общему числу регистраций. Это lagging-итог, на который нельзя влиять напрямую и который маскирует, создаёт ли продукт ценность.

Короткий ответ: DAU/WAU/MAU считают уникальных пользователей, совершивших определённое активное действие за день/неделю/месяц. Для фиксированных 30 дней средний DAU, делённый на MAU этого периода, показывает частоту активности: 0,2 соответствует в среднем шести активным дням на пользователя. Универсального «хорошего» порога для любых продуктов нет.

-- PostgreSQL: previous 30 complete days; day is a DATE
WITH active_events AS (
  SELECT day, user_id FROM events
  WHERE action = 'core_action'
    AND day >= CURRENT_DATE - 30
    AND day < CURRENT_DATE
), daily AS (
  SELECT day, COUNT(DISTINCT user_id) AS dau
  FROM active_events GROUP BY day
), monthly AS (
  SELECT COUNT(DISTINCT user_id) AS mau FROM active_events
)
SELECT (SELECT COALESCE(SUM(dau), 0) FROM daily)
       / 30.0 / NULLIF(mau, 0) AS stickiness
FROM monthly;

Подробно: Числитель и знаменатель должны использовать одинаковое определение активности, часовой пояс и период. Запрос делит на все 30 календарных дней, поэтому дни без активности дают ноль; AVG(dau) только по наблюдаемым датам пропустил бы их и завысил результат. NULLIF оставляет коэффициент неопределённым при отсутствии активных пользователей. Уникальных пользователей месяца считайте отдельно: не суммируйте DAU и не используйте неподдерживаемый DISTINCT в оконном агрегате.

Важно: Календарный месяц и скользящие 30 дней — разные определения. Зафиксируйте период и ключевое действие до сравнения продуктов или когорт.

Источник: Агрегаты PostgreSQL.

Короткий ответ: Retention — доля исходной когорты, удовлетворяющая выбранному правилу удержания. Для exact-week retention это активность именно на неделе N; для return-on-or-after — возвращение на неделе N или позже. Churn зависит от определения ухода и не равен автоматически 1 − exact-week retention.

Подробно:

1. Определите событие и окно — например, первая покупка задаёт когорту, а активность на четвёртой неделе — W4 retention. Пользователь, не активный в W4, может вернуться в W5, поэтому это не обязательно окончательный уход.
2. Когда есть дополнение — для одной фиксированной когорты, одного окна и взаимоисключающих состояний «сохранил подписку»/«ушёл» доли складываются в 100%. Метрики с другими знаменателями, реактивациями или выручкой требуют отдельных формул.
3. Сравнивайте одинаковый возраст — новые когорты ещё не имеют полной W4; неполные окна нельзя трактовать как нулевое удержание.

Удержание по активности на конкретной неделе (%)
Когорта │ W0   W1   W2   W3   W4
────────┼───────────────────────
Январь  │ 100   48   39   36   35
Февраль │ 100   45   37   34   33
Март    │ 100   38   28   24   22

Рост общей аудитории за счёт привлечения может скрывать ухудшение новых когорт. Стабильное плато полезно для оценки, но само по себе не доказывает product-market fit: важны ценность, частота использования, сегмент и экономика.

⚠️ Частая ошибка: превращать W4 retention 35% в «65% окончательно ушли за четыре недели». Сначала согласуйте определение, знаменатель и период наблюдения.

Короткий ответ: Воронка — последовательность шагов к цели; на каждом часть пользователей отваливается. Шаговая конверсия — доля прошедших с одного шага на следующий; сквозная (overall) — доля прошедших весь путь, это произведение всех шаговых. Главный отвал ищем по наибольшему относительному падению на шаге, а не по абсолютным числам.

Подробно:

1. Шаговая vs сквозная — сквозная = шаг₁ × шаг₂ × … Отдельные шаги по 90% дают всего 0,9⁴ ≈ 66% сквозной за 4 шага.
2. Где чинить — целься в шаг с худшей шаговой конверсией: там наибольший потенциал.
3. Задай окно и порядок — за какой срок и обязателен ли строгий порядок шагов; иначе конверсия неоднозначна.

Воронка checkout (шаговая % → следующий шаг)
Просмотр   ████████████████████ 10 000
  ↓ 40%
В корзину  ████████          4 000
  ↓ 75%
Оформление ██████            3 000
  ↓ 30%  ◄── главный отвал
Оплачено   ██                  900
Сквозная: 900 / 10 000 = 9%

⚠️ Частая ошибка: усреднять конверсию по шагам или гнаться за абсолютными числами. Самый большой относительный отвал (здесь 30% на оплате) — вот где спрятан рост.

Короткий ответ: Сначала проверяю, реальное ли это падение или дефект данных, затем сегментирую, чтобы локализовать, потом отделяю внутренние причины (релиз, эксперимент) от внешних (праздник, выходной партнёр, сезонность). Цель — сузить от «всё упало» до «упал сегмент X из-за Y».

Подробно:

1. Реально или артефакт? — не сломался ли логгер/ETL, нет ли дублей, не сместилось ли определение метрики, полные ли данные за период.
2. Сегментируй по измерениям — платформа, версия приложения, гео, новые vs вернувшиеся, канал. Резкий обрыв в одном срезе = локальная причина.
3. Внутреннее vs внешнее — совпадает ли с деплоем/флагом/A/B; внешнее — праздник, сбой у партнёра по оплате, выкатка конкурента.

Метрика −15%
├─ Данные целы? ──нет──► чинить пайплайн (ложная тревога)
│        └─да
├─ Один сегмент? ─да──► iOS v4.2 → регресс релиза
│        └─ все сегменты
└─ Совпало с релизом? ─да─► откат
         └─нет──► внешнее: сбой платёжного провайдера

⚠️ Частая ошибка: сразу строить гипотезы о продукте, не исключив поломку инструментирования. Половина «обвалов» — это сломанный трекинг или неполные данные.

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

Подробно:

1. Среднее маскирует разброс — стабильное общее число может скрывать растущий и падающий сегменты, которые гасят друг друга.
2. Парадокс Симпсона — сдвиг микса сегментов меняет общий результат, даже когда каждый сегмент улучшается.
3. Полезные срезы — новые vs вернувшиеся, платформа, гео/язык, канал привлечения, тариф.

Общая конверсия «упала», хотя ни один сегмент не ухудшился — изменился только микс. Без разреза вывод был бы ложным.

⚠️ Частая ошибка: докладывать одно усреднённое число и принимать по нему решения. Всегда спрашивай «среднее по чему?» и режь на сегменты, прежде чем делать вывод.

Короткий ответ: CAC — стоимость привлечения одного платящего клиента; LTV — суммарная маржинальная прибыль с клиента за всё время жизни. Здоровым ориентиром считают LTV:CAC ≈ 3:1 и payback period ≤ 12 месяцев (для SaaS). Меньше 1:1 — убыток на каждом клиенте; намного выше 3:1 — возможно, вы недоинвестируете в рост.

Подробно:

1. CAC = все расходы sales+marketing / число новых клиентов за период (а не на лида).
2. LTV = ARPU × валовая маржа × средняя длительность жизни (или ARPU×маржа / churn-rate). Бери маржу, не выручку.
3. Payback = CAC / (месячная выручка с клиента × маржа): за сколько месяцев клиент окупает своё привлечение.
4. Отношение = LTV / CAC: единица здоровья юнит-экономики.

⚠️ Частая ошибка: считать LTV от выручки, а не от валовой маржи, и игнорировать payback. Красивое 4:1 бесполезно, если окупаемость 24 месяца, а денег на разрыв нет.

Короткий ответ: Vanity-метрика приятно растёт, но не меняет решений (суммарные регистрации, просмотры страниц); actionable — привязана к решению и контролируема (активация, конверсия, retention). Guardrail — это защитная метрика рядом с целевой: оптимизируя одно, легко сломать другое, и guardrail не даёт «выиграть» ценой вреда.

Подробно:

1. Vanity всегда растёт — накопительные счётчики не падают и потому бесполезны для решений. Бери ставки и свежие когорты.
2. Actionable = решение + контроль — ясно, что делать при росте/падении и за что отвечает команда.
3. Goal + guardrail — целевую метрику двигаем, guardrail держим не хуже порога.

⚠️ Частая ошибка: оптимизировать целевую метрику без guardrail. Можно нагнать клики кликбейтом и обвалить доверие — рост метрики при разрушении продукта.

Короткий ответ: Lagging-индикатор измеряет итог, который уже случился (выручка, квартальный churn) — точный, но запоздалый и трудноуправляемый. Leading-индикатор измеряет раннее поведение, предсказывающее итог (активация, вовлечённость в неделю 1) — на него можно влиять сейчас. Аналитику нужны оба: leading, чтобы рулить, lagging, чтобы подтверждать.

Подробно:

1. Lagging = результат — надёжно подводит черту, но узнаёшь, когда менять поздно.
2. Leading = ранний сигнал — управляем и прогностичен, но связь с итогом надо проверять на данных, иначе гонишься за шумом.
3. Пара рычаг → итог — выбирай leading, который статистически предсказывает нужный lagging.

⚠️ Частая ошибка: управлять продуктом только по lagging-метрикам вроде выручки. К моменту, когда упадёт квартальный итог, причина возникла недели назад — следи за опережающими сигналами.