Воронки, когорты и retention: вопросы для собеседования (часть 4)
Воронки конверсии, когортный анализ, retention по дням/неделям — ключевые инструменты продуктового аналитика. На собеседовании просят построить retention-кривую, объяснить, почему retention Day 1 важнее Day 30, или найти узкое место воронки. Без этих концепций невозможно оценить здоровье продукта.
Вопросы 16–20 из 20
16В воронке шаг 1 = `landing_view`, шаг 2 = `signup`, шаг 3 = `purchase`. Вы хотите конверсию 1→3 по `unique users`. Что является `denominator`?
A`unique users` на шаге 2
B`unique users` на шаге 1
CВсе `unique users` продукта за период
D`unique users` на шаге 3
Ответ: Конверсия 1→3 в воронке делит достигших шага 3 на базу шага 1, то есть на входной `denominator`.
Метрика 1→3 отвечает на вопрос: какая доля тех, кто увидел лендинг, в итоге купила. Поэтому `denominator` — `unique users` шага 1. Если делить на шаг 2, получится другая метрика — 2→3. Если делить на всю аудиторию продукта, вы смешаете пользователей, которые не видели лендинг, и метрика станет менее полезной.
17Вы сравниваете `D30 retention` у когорты сентября и когорты ноября, но с `cohort date` ноября прошло только 12 дней. В чём проблема и что корректнее сделать?
AПроблемы нет: `D30 retention` можно считать в любой момент
BНужно удалить сентябрьскую когорту, потому что старые когорты всегда ниже
CНужно заменить `denominator` на число активных пользователей в ноябре
DЭто `right censoring`: нужно дождаться 30 дней или сравнивать когорты одинакового возраста
Ответ: Нельзя корректно сравнить `D30 retention`, если когорта ещё не прожила 30 дней; это `right censoring`.
Когорта ноября физически не могла показать активность на дне 30, потому что прошло только 12 дней. Поэтому `D30 retention` будет занижена не из-за поведения, а из-за неполного окна наблюдения. Корректно дождаться, когда когорте исполнится 30 дней, или сравнивать когорты одинакового возраста. Иногда метрику просто не публикуют, пока окно не закрылось.
18В середине периода команда переименовала шаг 2: раньше был `complete_profile`, теперь `profile_saved`. Вы сравниваете конверсию в воронке месяц к месяцу и видите резкое падение. Что наиболее корректно сделать?
AПринять падение как продуктовый факт и немедленно менять UX
BСчитать только первые дни месяца со старым событием и игнорировать остальное
CСчитать только новое событие и сравнить с прошлым без пересчёта, чтобы быстрее принять решение
DУнифицировать определение шага 2 (маппинг/версионирование), пересчитать историю по единой логике и явно описать изменение `logging`
Ответ: Если шаги воронки меняются из-за `logging`, нужно версионировать определения и пересчитывать по единой логике.
Когда событие шага переименовали, старые данные и новые данные перестали быть сопоставимыми. В результате кажется, что конверсия упала, хотя изменилось только определение шага 2. Корректный подход — сделать маппинг `complete_profile` ↔ `profile_saved` (или хранить версию события) и пересчитать шаги для всего сравниваемого периода. Также важно задокументировать изменение в описании метрики и контролировать, что дедупликация пользователей работает одинаково. После унификации можно уже делать продуктовые выводы.
19События логируются в UTC, а отчёты по `retention` бизнес смотрит по локальным дням. Вы считаете `D1 retention` по UTC-дням и видите провал. Что наиболее корректно сделать?
AУвеличить окно и считать `D2 retention` вместо `D1 retention`
BПоменять `denominator` на число активных на день 1, чтобы провал исчез
CИгнорировать: `retention` не зависит от границ дня
DПривести `cohort date` и `event date` к единым границам дня (одно правило/таймзона), затем пересчитать `retention`
Ответ: В `retention` важно, чтобы `cohort date` и `event date` считались по одной логике дней.
Если день 0 определяется по одной таймзоне, а активность на день 1 — по другой, часть пользователей будет сдвинута между днями. Это искусственно занижает `D1 retention` и создаёт ложные провалы. Первое действие — согласовать правило построения дней и привести времена к одной логике. Затем пересчитать `retention` и проверить, что аномалия исчезла. Только после этого имеет смысл искать продуктовые причины.
20Общая `step conversion` в воронке выросла, но в каждом канале трафика (`ads`, `organic`) она снизилась. Какое объяснение наиболее вероятно?
AЭто обязательно ошибка подсчёта `unique users`
BЭто означает, что `retention` вырос, а не `конверсия`
CЭто происходит только из-за отсутствия дедупликации пользователей
DИзменился микс каналов: выросла доля канала с более высокой базовой конверсией, поэтому общий показатель поднялся
Ответ: Когда общий показатель и показатели по сегментам расходятся, часто меняется состав сегментов в `denominator`.
Если доля канала с высокой базовой конверсией выросла, общий `step conversion` может увеличиться даже при падении внутри каждого канала. Это ловушка смещения микса, похожая на эффект Симпсона (`Simpson’s paradox`). Проверьте распределение пользователей по каналам на шаге 1 (`denominator`) и сравните по фиксированным весам. Также убедитесь, что сегментация применяется одинаково на всех шагах воронки.
Хотите тренировать интерактивно?
В приложении — таймер, прогресс, стрики и 1700+ вопросов по всем темам.
Тренировать в TelegramДругие темы: Продуктовая аналитика