Воронки, когорты и retention: вопросы для собеседования (часть 3)
Воронки конверсии, когортный анализ, retention по дням/неделям — ключевые инструменты продуктового аналитика. На собеседовании просят построить retention-кривую, объяснить, почему retention Day 1 важнее Day 30, или найти узкое место воронки. Без этих концепций невозможно оценить здоровье продукта.
Вопросы 11–15 из 20
11Вы хотите оценить долю пользователей, которые сделали `search` и затем `purchase` в течение недели, независимо от количества сессий. Какую логику воронки лучше выбрать?
A`event-level` отношение `purchase`/`search` по числу событий
B`session-level`: считать `unique sessions` вместо пользователей
C`user-level` воронка по `unique users` с дедупликацией пользователей на каждом шаге
DСчитать среднее число покупок на пользователя и назвать это `step conversion`
Ответ: Если вопрос про долю людей, выбирайте `user-level` воронку по `unique users` с дедупликацией пользователей.
Событийный подход отвечает на другой вопрос: сколько покупок на количество поисков, и может исказиться частотой действий. `Session-level` тоже меняет смысл: один и тот же человек в разных сессиях учитывается несколько раз. `User-level` воронка делает показатель вероятностным: был ли поиск и была ли покупка у пользователя. Это соответствует формулировке про долю пользователей.
12В расчёте `D1 retention` по `unique users` пользователь открыл приложение 20 раз в день 1. Как он учитывается в `numerator`?
A20 раз, потому что это 20 событий
B0 раз, потому что слишком много событий
C1 раз, потому что в `retention` есть дедупликация пользователей по дню
DЗависит от размера `denominator`
Ответ: В `retention` считают пользователей, а не число событий, поэтому `numerator` требует `дедупликация пользователей`.
Для `D1 retention` важно, вернулся ли пользователь в день 1 хотя бы один раз. Двадцать открытий приложения всё равно означают одного вернувшегося пользователя. Поэтому в `numerator` он учитывается как 1 `unique user` на день 1. Событийный счёт здесь исказил бы `retention`, делая его зависимым от частоты открытия.
13В checkout есть два пути: `add_to_cart` и `buy_now`, оба ведут к `purchase`. В воронке шаг 2 задан только как `add_to_cart`, и конверсия выглядит низкой. Что лучше сделать?
AОставить как есть: `buy_now` не относится к этой воронке
BПереопределить шаг 2 как `start_checkout`, включив `add_to_cart` и `buy_now`, или построить две воронки по путям
CИсключить пользователей `buy_now` из данных, чтобы не портить `denominator`
DСделать шаг 1 сразу `purchase`, чтобы `конверсия` была 100%
Ответ: Шаги воронки должны отражать реальные пути, иначе `denominator` и потери по шагам искажаются.
Если часть пользователей покупает через `buy_now`, они не обязаны проходить `add_to_cart`. Тогда ваш шаг 2 становится не универсальным, и конверсия выглядит хуже, чем есть на самом деле. Решение — сделать шаг, который описывает общий смысл (например, `start_checkout`), или разнести пути в две `воронка`. Так вы сможете честно понять, где теряются пользователи и какой путь эффективнее.
14Вы строите когорту покупателей для `retention`, где день 0 — первая покупка. Как правильно определить `cohort date` для пользователя?
A`cohort date` = дата `event 'signup'`
B`cohort date` = дата последнего `event 'purchase'` в периоде
C`cohort date` = дата первого `purchase` пользователя (с дедупликацией пользователей)
D`cohort date` = любая дата `purchase`, поэтому один пользователь может быть в нескольких когортах
Ответ: Для когорты покупки `cohort date` равен первой покупке пользователя, чтобы не было повторного попадания в когорты.
Если день 0 — первая покупка, базой является момент первого `purchase` для каждого пользователя. Это требует дедупликации пользователей и выбора минимальной даты события. Если использовать последнюю покупку, вы сместите возраст пользователя и исказите `retention`. Если разрешить попадание в несколько когорт, сравнения между когортами станут некорректными.
15Аналитик считает `retention` так: берёт всех `unique users`, активных на неделе 1, и делит число активных на неделе 2 на эту базу. Почему это может быть ошибкой, если нужна когортная логика?
AЭто всегда правильный `retention` и не зависит от `когорта`
BОшибка только в том, что надо считать по `events`, а не по `unique users`
CБаза меняется и смешивает пользователей разного 'возраста'; для `cohort retention` нужна фиксированная `когорта` по `cohort date`
DНужно делить на число установок приложения, а не на активных пользователей
Ответ: Для `cohort retention` база должна быть фиксированной когортой, иначе вы смешиваете пользователей разного возраста.
Если каждый раз брать 'активных на неделе', состав базы меняется и включает пользователей, пришедших в продукт в разные даты. Такой показатель ближе к общей повторной активности, а не к `cohort retention`. Для когортного анализа нужно зафиксировать `cohort date` (например, `event 'signup'`) и дальше смотреть возвраты по возрасту: `W1 retention`, `W2 retention` и так далее. Тогда сравнения между когортами будут честными.
Хотите тренировать интерактивно?
В приложении — таймер, прогресс, стрики и 1700+ вопросов по всем темам.
Тренировать в TelegramДругие темы: Продуктовая аналитика