Вопросы по теме «A/B-тесты в продуктовой аналитике»
Как выбрать метрику для эксперимента, интерпретировать результаты и принять решение о раскатке — продуктовый взгляд на A/B-тесты. На собеседовании дают кейс: «тест показал рост кликов, но падение retention — что делать?» Здесь важна не статистика, а продуктовое мышление и умение балансировать метрики.
Всего в этом разделе 20 вопросов. Каждый — с правильным ответом и кратким разбором теории. Разбито на 4 части по 5 вопросов.
Вопросы 1–5 из 20
1Эксперимент длился 2 дня и пришёлся только на выходные, а в будни поведение заметно другое. Какой риск наиболее важен?
AРиск `SRM`, потому что в выходные всегда другой сплит групп
BРиск `peeking`, потому что два дня — это слишком мало
CРиск `seasonality`: результат может не переноситься на обычную неделю и может быть смещён календарным эффектом
DРиск `rollout`, потому что выкатывать можно только по понедельникам
Ответ: Короткий тест на «особые» дни может быть искажен `seasonality` и плохо переноситься на другие периоды.
В выходные меняется состав трафика и сценарии использования, поэтому эффект может отличаться от будней. Это и есть риск `seasonality`: вы измеряете не только влияние фичи, но и календарный контекст. Обычно эксперимент планируют так, чтобы покрыть типичный цикл (например, неделю) или как минимум сопоставимые дни недели.
2Когда `A/B test` обычно предпочтительнее, чем сразу делать полный `rollout` изменения?
AКогда можно случайно разделить пользователей на `control` и `treatment` и измерить эффект по `primary metric` и `guardrail metric` до выката на всех
BКогда изменение уже точно полезно и не требует проверки
CКогда нет возможности мерить метрики, но нужно быстро выкатывать
DКогда вы хотите сравнить результат с прошлым месяцем без `control`
Ответ: `A/B test` полезен, когда вы можете рандомизировать `control/treatment` и до `rollout` проверить эффект и риски.
Полный `rollout` без проверки увеличивает риск выкатить ухудшение и долго его искать. `A/B test` позволяет изолировать эффект изменения и проверить, что `primary metric` улучшается без провала по `guardrail metric`. Сравнение с прошлым месяцем часто смешивает эффект фичи с `seasonality` и другими внешними изменениями.
3Вы увеличиваете частоту push-уведомлений, ожидая рост заказов. Какая метрика наиболее уместна как `guardrail metric`?
AКоличество отправленных push
BКоличество открытий push
CСреднее число заказов на активного пользователя
DДоля отключивших уведомления (`opt_out_rate`) или жалобы на спам
Ответ: `guardrail metric` защищает от ухудшения опыта пользователя и рисков, даже если `primary metric` растёт.
Увеличение push часто повышает краткосрочные метрики, но может раздражать пользователей. Поэтому важно контролировать `guardrail metric`, которая отражает негативный опыт: отключения уведомлений, жалобы, отписки. Количество отправок и открытий — это скорее механика и промежуточные показатели, а не ограничение риска.
4Какой подход к остановке эксперимента лучше всего снижает риск `peeking` (подглядывания) и спорных выводов?
AСмотреть результаты каждый час и останавливать, как только стало лучше
BЗаранее зафиксировать длительность или правило остановки по `primary metric` и `guardrail metric` и следовать ему
CОстановить сразу, если в первый день метрика немного выросла
DОстановить, когда руководителю станет комфортно принять решение
Ответ: Чтобы снизить риск `peeking`, заранее фиксируют правило остановки и придерживаются его.
Если постоянно подглядывать и останавливать по удобному моменту, возрастает шанс принять случайный шум за эффект. Поэтому командно договариваются о длительности, критерии успеха по `primary metric` и ограничениях по `guardrail metric`. Такой процесс делает решение воспроизводимым и снижает вероятность самообмана.
5Вы планировали сплит 50/50 между `control` и `treatment`, но стабильно видите 62/38 по пользователям. Что это наиболее вероятно и что делать?
AЭто нормально: просто один вариант более популярный
BЭто признак `seasonality`, нужно подождать выходных
CЭто означает, что `primary metric` нужно заменить
DЭто похоже на `SRM`; сначала проверьте назначение варианта и сбор данных, а потом интерпретируйте эффект
Ответ: Сильный перекос сплита часто указывает на `SRM` и требует проверки пайплайна до анализа метрик.
`SRM` (sample ratio mismatch) обычно означает проблему с рандомизацией, таргетингом или логированием. При `SRM` группы могут стать несопоставимыми, и эффект по `primary metric` может быть неверным. Правильный шаг — проверить механизм назначения `control/treatment`, фильтры, дедупликацию пользователей и только затем продолжать анализ.
Хотите тренировать интерактивно?
В приложении — таймер, прогресс, стрики и 1700+ вопросов по всем темам.
Тренировать в TelegramДругие темы: Продуктовая аналитика