Воронки, когорты и retention: вопросы для собеседования (часть 2)

Воронки конверсии, когортный анализ, retention по дням/неделям — ключевые инструменты продуктового аналитика. На собеседовании просят построить retention-кривую, объяснить, почему retention Day 1 важнее Day 30, или найти узкое место воронки. Без этих концепций невозможно оценить здоровье продукта.

A/B-тесты в продуктовой аналитикеОсновы продуктовой аналитикиРост, активация и онбордингИнструментация и качество данныхМонетизация и юнит-экономикаNorth Star, KPI и иерархия метрикПриоритизация и RICEПостановка задачи и PRDСегментация и позиционированиеСторителлинг и alignmentИсследование пользователей и JTBD

Вопросы 610 из 20

6Когорта регистрации 10 марта содержит 5000 уникальных пользователей. Какой знаменатель у удержания на день 7 (D7) этой когорты?
A5000 уникальных пользователей: размер исходной когорты регистрации, на день 0
BЧисло всех активных пользователей в продукте на день 7, без привязки к когорте
CЧисло пользователей, вернувшихся на день 7 (это числитель удержания, не знаменатель)
DЧисло событий открытия приложения на день 7 у пользователей всех когорт
Ответ: D7 — доля вернувшихся среди исходной когорты, поэтому знаменатель равен размеру когорты на день 0.

В удержании по когорте базой является количество пользователей в день 0, то есть размер когорты. На день 7 вы считаете, сколько из этих же пользователей проявило активность по выбранному определению. Числитель — вернувшиеся на день 7, а знаменатель — исходная когорта. Деление на аудиторию дня 7 нарушит смысл когортного удержания и даст несопоставимые числа.

Подробный разбор →
7В отчётах вы используете `device_id` как идентификатор для подсчёта уникальных пользователей. Один человек часто логинится на двух устройствах. Как это повлияет на знаменатель и удержание?
AУдержание удваивается, поскольку один человек регулярно возвращается на оба устройства и каждый визит засчитывается как отдельный возврат
BУдержание занижается, поскольку метрика теряет события входа на втором устройстве из-за конфликта идентификаторов в логах продукта
CЗнаменатель когорты завышен, удержание искажено: один человек считается двумя уникальными пользователями
DИзменений нет: `device_id` и пользователь по сути одно и то же, и склейка устройств в единый идентификатор не требуется
Ответ: Если идентификатор не соответствует человеку, уникальные пользователи, знаменатель и удержание искажаются.

При использовании `device_id` один человек с двумя устройствами становится двумя уникальными пользователями. Это увеличивает знаменатель в воронке и раздувает размер когорты. Удержание тоже искажается: человек может «вернуться» на другом устройстве и не быть распознан как тот же пользователь. Поэтому для продуктовой аналитики обычно используют `user_id` или правила склейки устройств в единый идентификатор.

Подробный разбор →
8Что означает скользящее удержание (rolling retention) D7 для когорты?
AДоля пользователей когорты, активных хотя бы раз в каждый из первых семи дней после старта без пропусков.
BДоля пользователей когорты, которые были активны ровно на седьмой день после даты старта без сдвига вперёд.
CДоля пользователей когорты, которые были активны на седьмой день или позже относительно даты старта когорты.
DДоля пользователей когорты, активных хотя бы один раз за первые семь дней после старта когорты по календарю.
Ответ: Скользящее удержание D7 считает удержанными тех, кто вернулся в день 7 или позже относительно даты старта когорты.

В отличие от классического D7, который требует активности ровно в седьмой день, скользящее удержание допускает возврат позже. Это полезно, когда поведение пользователей нерегулярно и точный день возврата плавает. Знаменатель остаётся равен размеру когорты — меняется только условие в числителе. Такой показатель обычно выше классического, потому что условие проще, поэтому сравнивать их напрямую нельзя.

Подробный разбор →
9В отчёте по воронке вы видите конверсию шага 1→2 = 130%. Шаг 1 = `add_to_cart`, шаг 2 = `purchase`. Какое объяснение наиболее вероятно?
AЭто нормально для пользовательской воронки на уровне `user_id`: при подсчёте уникальных пользователей `purchase` после `add_to_cart` корректно превышает 100%
BСчёт идёт по событиям без дедупликации пользователей или `order_id`, поэтому событий `purchase` оказывается больше, чем событий `add_to_cart`
CЭто значит, что знаменатель надо считать по всем пользователям продукта за период (`MAU`), а не только по тем, кто дошёл до `add_to_cart`
DЭто обязательно проблема удержания, а не расчёта воронки: пользователи возвращаются и повторяют `purchase` несколько раз без `add_to_cart`
Ответ: Если конверсия шага больше 100%, чаще всего это счёт на уровне событий без дедупликации пользователей.

При расчёте на уровне событий один пользователь может сделать несколько покупок или событие может дублироваться. Тогда числитель (события `purchase`) становится больше знаменателя (события `add_to_cart`). Для доли пользователей обычно используют воронку по уникальным пользователям. Либо вводят дедупликацию по `order_id`, если цель — конверсия заказов. Удержание и общий знаменатель по всему продукту — это отдельные сущности и не объясняют 130%.

Подробный разбор →
10После обновления клиента одно действие покупки генерирует два события `purchase`. Какая проверка лучше всего подтвердит влияние дублей на метрики воронки?
AСравнить общий доход за период до и после релиза без проверки соотношения событий `purchase` и числа уникальных заказов на пользователя
BПоднять первый шаг воронки на уровень `add_to_cart`, чтобы знаменатель стал больше и вклад дублей в долю шага визуально снизился
CПроверить дедупликацию по `order_id` и распределение числа событий `purchase` на одну покупку и на одного пользователя
DПересчитать удержание новичков на когорте после релиза, поскольку дубли событий обычно проявляются именно в этой группе пользователей
Ответ: Дубли в логах ломают воронку, поэтому важны дедупликация и уникальные ключи вроде `order_id`.

Если одно действие создаёт два события `purchase`, событийные метрики будут завышены. Даже анализ на уровне пользователя может пострадать, если дубли влияют на правила достижения шага или атрибуцию. Проверка по `order_id` показывает, соответствует ли число покупок числу уникальных заказов. Дополнительно полезно посмотреть распределение событий на заказ и сравнить состояние до и после релиза. После подтверждения проблему нужно чинить в логировании или вводить явную дедупликацию.

Подробный разбор →
1234

Хотите тренировать интерактивно?

В приложении — таймер, прогресс, стрики и 1700+ вопросов по всем темам.

Тренировать продукт в Telegram

Другие темы: Продуктовая аналитика

A/B-тесты в продуктовой аналитикеОсновы продуктовой аналитикиРост, активация и онбордингИнструментация и качество данныхМонетизация и юнит-экономикаNorth Star, KPI и иерархия метрикПриоритизация и RICEПостановка задачи и PRDСегментация и позиционированиеСторителлинг и alignmentИсследование пользователей и JTBD