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