Воронки, когорты и retention: вопросы для собеседования (часть 2)
Воронки конверсии, когортный анализ, retention по дням/неделям — ключевые инструменты продуктового аналитика. На собеседовании просят построить retention-кривую, объяснить, почему retention Day 1 важнее Day 30, или найти узкое место воронки. Без этих концепций невозможно оценить здоровье продукта.
Вопросы 6–10 из 20
6Когорта `signup` 10 марта содержит 5000 `unique users`. Какой `denominator` у `D7 retention` этой когорты?
A5000 (размер когорты по `unique users`)
BЧисло всех активных пользователей в продукте на день 7
CЧисло пользователей, вернувшихся на день 7 (это `numerator`)
DЧисло событий `event 'app_open'` на день 7
Ответ: `D7 retention` — доля вернувшихся среди исходной `когорта`, поэтому `denominator` равен размеру когорты.
В `retention` базой является количество пользователей в день 0, то есть размер когорты. На день 7 вы считаете, сколько из этих же пользователей проявило активность по выбранному определению. Числитель — вернувшиеся на день 7, а знаменатель — исходная когорта. Деление на аудиторию дня 7 нарушит смысл `cohort retention`.
7В отчётах вы используете `device_id` как идентификатор для `unique users`. Один человек часто логинится на двух устройствах. Как это повлияет на `denominator` и `retention`?
A`denominator` (размер `когорта`) будет завышен, а `retention` может исказиться, потому что один человек становится двумя `unique users`
B`retention` всегда вырастет ровно в 2 раза
CНичего не изменится, потому что `device_id` и есть пользователь
DКонверсия станет 100%, потому что два устройства компенсируют потери
Ответ: Если идентификатор не соответствует человеку, то `unique users`, `denominator` и `retention` искажаются.
При использовании `device_id` один человек с двумя устройствами становится двумя пользователями. Это увеличивает `denominator` в воронке и раздувает размер когорты. `retention` тоже может исказиться: человек может «вернуться» на другом устройстве и не быть распознан как тот же пользователь. Поэтому для продуктовой аналитики обычно используют `user_id` или правила склейки устройств.
8Что означает `rolling retention` D7 для когорты?
AДоля пользователей из `когорта`, которые были активны на дне 7 или позже относительно `cohort date`
BДоля пользователей, активных ровно на дне 7
CДоля пользователей, активных каждый день с 1 по 7
DДоля пользователей, активных хотя бы раз в первые 7 дней
Ответ: `Rolling retention` D7 считает удержанными тех, кто вернулся в день 7 или позже относительно `cohort date`.
В отличие от классического `D7 retention`, который требует активности ровно в день 7, `rolling retention` допускает возврат позже. Это полезно, когда поведение пользователей нерегулярно и точный день возврата плавает. База (`denominator`) остаётся размером когорты. Такой показатель обычно выше классического, потому что условие проще.
9В отчёте по воронке вы видите `step conversion` 1→2 = 130%. Шаг 1 = `add_to_cart`, шаг 2 = `purchase`. Какое объяснение наиболее вероятно?
AЭто нормально для `user-level` воронки, так и должно быть
BЭто значит, что надо делить на всех пользователей продукта, а не на шаг 1
CСчёт идёт по `events` без `дедупликация пользователей` (или `order_id`), поэтому событий `purchase` может быть больше
DЭто обязательно проблема `retention`, а не расчёта воронки
Ответ: Если `step conversion` больше 100%, часто это `event-level` счёт без дедупликации пользователей.
В `event-level` расчёте один пользователь может сделать несколько покупок или событие может дублироваться. Тогда числитель (события `purchase`) становится больше знаменателя (события `add_to_cart`). Для доли пользователей обычно используют `user-level` воронку по `unique users`. Либо вводят дедупликацию по `order_id`, если цель — конверсия заказов.
10После обновления клиента одно действие покупки генерирует два события `purchase`. Какая проверка лучше всего подтвердит влияние дублей на метрики воронки?
AСравнить только общий доход, не глядя на события
BПроверить дедупликацию по `order_id` и распределение числа `events` на одну покупку/пользователя
CСразу поменять `шаг 1` в `воронка`, чтобы `конверсия` стала выше
DПересчитать `retention`, потому что `воронка` не зависит от `logging`
Ответ: Дубли в `logging` ломают воронку, поэтому важны дедупликация и уникальные ключи вроде `order_id`.
Если одно действие создаёт два `purchase`, событийные метрики будут завышены. Даже `user-level` анализ может пострадать, если дубли влияют на правила достижения шага или атрибуцию. Проверка по `order_id` показывает, соответствует ли число покупок числу уникальных заказов. Дополнительно полезно посмотреть распределение `events per order` и сравнить до/после релиза. После подтверждения проблему нужно чинить в `logging` или вводить явную дедупликацию.
Хотите тренировать интерактивно?
В приложении — таймер, прогресс, стрики и 1700+ вопросов по всем темам.
Тренировать в TelegramДругие темы: Продуктовая аналитика