Воронки и когортные рассуждения: вопросы для собеседования (часть 3)
Логика построения воронок: какие шаги включить, как обрабатывать повторные визиты, почему конверсия между шагами может быть больше 100%. На собеседовании дают ошибочную воронку и просят найти проблему. Когортные рассуждения проверяют, умеет ли кандидат корректно сравнивать группы пользователей во времени.
Вопросы 11–15 из 20
11События логируются в UTC, а продуктовые отчёты построены по локальным дням. Вы считаете удержание `D1` по UTC-дням и видите неожиданный «провал». Что наиболее разумно сделать в первую очередь?
AПроверить границы дней и привести расчёт к одной логике: единая таймзона и одинаковое правило привязки события ко дню для когорты и активности
BИгнорировать наблюдение полностью: удержание не зависит от часовых поясов и провалы в отчётах объясняются обычным разбросом метрики
CПоменять знаменатель на число активных пользователей в первый день, чтобы аккуратно сгладить провал и избежать лишних вопросов от продактов
DИсключить из расчёта пользователей, которые активны ночью, потому что иначе появляется смещение между UTC и локальными днями
Ответ: Для удержания важно единообразно определять границы дня и связь с когортой.
Если день 0 и день 1 режутся по разным часовым поясам, возвраты могут сдвигаться между днями. Тогда удержание `D1` будет выглядеть хуже или лучше только из-за календарной логики, а не из-за поведения. Приведение времени события к единой таймзоне и одинаковое правило построения когорты обычно устраняет такие артефакты.
Подробный разбор → 12Вы строите воронку регистрации, но шаг 1 определили как событие открытия приложения для всех пользователей. Пошаговая конверсия до регистрации получилась очень низкой. Какое объяснение наиболее вероятно и что исправить?
AЗаменить знаменатель на количество событий регистрации: пошаговая конверсия станет корректной для всей воронки регистрации в любой когорте
BПрекратить строить эту воронку и перейти к анализу удержания: регистрация плохо отражает качество продукта на ранних этапах
CУвеличить период наблюдения за пользователями: пошаговая конверсия вырастет до приемлемого уровня без изменения определения шага
DШаг 1 включает уже зарегистрированных пользователей: базу воронки нужно сузить до пользователей без аккаунта или видевших экран регистрации
Ответ: Если шаг 1 слишком широкий, знаменатель включает нерелевантных пользователей и занижает пошаговую конверсию.
Пользователи с аккаунтом редко проходят регистрацию повторно, поэтому они не должны попадать в базу воронки регистрации. Когда вы ограничиваете шаг 1 до релевантной аудитории, пошаговая конверсия начинает отражать реальное качество пути. Это изменение определения метрики, а не «улучшение» продукта само по себе.
Подробный разбор → 13В воронке шаг 2 — событие `complete_profile`. После релиза конверсия шага 1→2 резко упала на Android, а на iOS почти не изменилась. Что наиболее разумно проверить в первую очередь?
AСначала пересчитать конверсию шага без учёта новых пользователей: их доля могла вырасти и исказить базовый уровень для Android
BПроверить логирование события complete_profile на Android: разрезы по версии приложения, доля пользователей с событием и возможные потери
CСравнить распределение Android-пользователей по версиям до и после релиза: возможно, поменялся срез аудитории по причинам, не связанным с продуктом
DСопоставить шаги 1 и 2 на iOS до и после релиза: если на iOS соотношение тоже сместилось, искать общую причину, а не Android-специфичную
Ответ: Падение шага в одном сегменте часто связано с проблемами логирования, поэтому нужен разбор по разрезам.
Если проблема только на Android, скорее всего изменился клиент или потерялось событие на этой платформе. Проверьте долю уникальных пользователей с `complete_profile` по версиям приложения и каналу релиза, а также целостность схемы события. Лишь после проверки логирования корректно делать выводы о реальной воронке. Смена знаменателя, исключение Android и снятие дедупликации только маскируют проблему, а не решают её.
Подробный разбор → 14Что такое скользящее удержание (rolling retention) для дня 7?
AДоля пользователей, активных строго в день 7 относительно дня 0, без учёта активности до и после этой даты
BДоля пользователей, активных каждый день подряд с 1 по 7 относительно дня 0, иначе пользователь считается ушедшим
CДоля пользователей, активных хотя бы раз в первые 7 дней после дня 0, без учёта активности после окна
DДоля пользователей, у которых хотя бы одна активность зафиксирована в день 7 или позже относительно дня 0
Ответ: Скользящее удержание для дня N считает пользователя удержанным, если хотя бы одна активность была в день N или позже относительно дня 0.
Скользящее удержание (rolling retention) для дня 7 включает в числитель тех, кто был активен в день 7 либо в любой день после него — поэтому метрика монотонно невозрастающая по N. Классическое (N-day) удержание требует активности именно в день 7, а bounded — хотя бы раз в окне 0..7. Скользящее удобно для оценки долгосрочной лояльности, но менее чувствительно к мгновенному оттоку.
Подробный разбор → 15Вы считаете пошаговую конверсию в воронке на уровне событий как количество `purchase` / количество `add_to_cart` и получаете 130%. Какое объяснение наиболее вероятно?
AВы считаете по событиям без дедупликации, и один пользователь мог сделать несколько `purchase` на один `add_to_cart`
BЭто обязательно ошибка статистики: пошаговая конверсия по определению никогда не может оказаться больше 100% в воронке
CЭто означает, что знаменатель должен быть размером всей аудитории периода, а не количеством событий шага `add_to_cart`
DЭто признак того, что когорта собрана неверно, поэтому нужно пересчитать удержание и пересобрать аудиторию воронки
Ответ: В воронке на уровне событий без дедупликации количество событий может давать пошаговую конверсию больше 100%.
При расчёте по событиям вы сравниваете числа событий, а не доли пользователей. Если пользователи делают несколько покупок или шаги логируются с разной частотой, отношение может стать больше 1. Чтобы получить интерпретируемую конверсию, обычно используют воронку на уровне пользователей или вводят дедупликацию по пользователю или заказу. Версии «ошибка статистики», «пересчитать когорту» или «знаменатель — вся аудитория» не объясняют значение больше 100% корректно.
Подробный разбор →