A/B-тесты в продуктовой аналитике: вопросы для собеседования (часть 4)
Как выбрать метрику для эксперимента, интерпретировать результаты и принять решение о раскатке — продуктовый взгляд на A/B-тесты. На собеседовании дают кейс: «тест показал рост кликов, но падение retention — что делать?» Здесь важна не статистика, а продуктовое мышление и умение балансировать метрики.
Вопросы 16–20 из 20
16Почему A/B-тест обычно запускают параллельно на контрольную и тестовую группы, а не сравнивают тестовую группу с прошлым месяцем?
AСравнение с прошлым месяцем смешивает эффект изменения с сезонностью и внешними факторами, а параллельная контрольная группа помогает их учесть
BПараллельный запуск делает поэтапную раскатку ненужной, поэтому фичу можно сразу выкатывать на 100% пользователей без рисков
CПрошлый месяц всегда меньше по трафику, чем текущий, и потому абсолютные значения метрик не сопоставимы между периодами
DПараллельный запуск автоматически устраняет несоответствие долей групп, и проверять баланс пользователей после запуска уже не нужно
Ответ: Параллельные контрольная и тестовая группы лучше изолируют эффект и снижают влияние сезонности и внешних факторов.
При сравнении с прошлым месяцем меняются рекламные кампании, праздники, конкуренты и другие условия. Это делает вывод «фича улучшила метрику» сомнительным, потому что нет сопоставимой контрольной группы. В A/B-тесте группы идут одновременно, поэтому внешние факторы действуют на обе стороны примерно одинаково, и разница ближе к эффекту изменения. Параллельность не отменяет ни поэтапную раскатку, ни проверку долей групп — это отдельные практики безопасности экспериментов.
Подробный разбор → 17Команда хочет иметь возможность останавливать эксперимент раньше, если эффект явно плохой или явно хороший. Что лучше всего сделать, чтобы снизить риск подглядывания?
AОстанавливать тест в момент, когда менеджер субъективно решает, что данных уже достаточно для уверенного вывода по эффекту
BВсегда смотреть метрики каждый час и останавливать на пике, чтобы зафиксировать максимальный наблюдаемый эффект как итоговый
CЗаранее зафиксировать правила ранней остановки и применять согласованный критерий (например, последовательный подход) по основной и страховочным метрикам
DЗапускать тест только в выходные, чтобы быстрее увидеть эффект и принять решение об остановке по высокому всплеску активности
Ответ: Если нужна ранняя остановка, правила должны быть заранее определены, иначе многократные проверки делают выводы ненадёжными.
Ранняя остановка возможна, но она должна быть частью заранее согласованного процесса. Иначе вы многократно проверяете гипотезу и рискуете остановиться на случайном колебании. Правильная практика — зафиксировать, при каких условиях эксперимент останавливается по основной метрике и страховочным метрикам, и придерживаться этих условий. Решения «по ощущениям менеджера», ежечасный мониторинг или запуск только в выходные не контролируют ошибку и подменяют процесс импровизацией.
Подробный разбор → 18Эксперимент попал на распродажу, которая сильно меняет поведение. Какое утверждение наиболее корректно про сезонность в этом случае?
AСезонность не влияет на результат, если тест идёт несколько циклов продаж: эффект распродажи усредняется и не искажает оценку
BСезонность опасна: результат может отражать влияние распродажи, поэтому важен параллельный контроль в те же даты и аккуратная интерпретация переносимости эффекта
CСезонность совпадает с Sample Ratio Mismatch по сути: при сезонности группы автоматически делятся неравномерно по составу пользователей в выборке
DЛучше убрать контрольную группу во время распродажи, чтобы все пользователи попали в тестовую и быстрее набралась статистическая мощность теста
Ответ: Сезонность и внешние события могут менять базовый уровень метрик, поэтому важны параллельная контрольная группа и осторожная интерпретация.
Даже при корректном A/B-тесте распродажа может менять состав трафика и мотивацию пользователей, поэтому эффект фичи может проявляться иначе, чем в обычные дни. Параллельная контрольная группа помогает сравнивать варианты в одинаковых условиях. Но при сильной сезонности важно проверить, как эффект выглядит по дням и сегментам, и оценить, переносится ли он на обычный период перед раскаткой.
Подробный разбор → 19Вы подозреваете SRM: в тестовой группе меньше пользователей, чем ожидалось, и перекошены платформы. Что уместнее всего проверить в первую очередь?
AПерерисовать графики метрики, чтобы тренд выглядел ровнее и не пугал стейкхолдеров на ближайшем демо
BСразу запустить раскатку на 100%, чтобы быстрее собрать данные и компенсировать перекос объёмом
CПроверить логику назначения групп, фильтры включения, дедупликацию идентификаторов и логирование варианта
DЗаменить основную метрику, потому что текущая «ломает» распределение и мешает увидеть реальный эффект
Ответ: SRM чаще всего вызван проблемой назначения или сбора данных, поэтому начинать нужно с пайплайна групп.
При SRM (Sample Ratio Mismatch) разница между группами появляется не из-за фичи, а из-за багов: часть пользователей не попадает в эксперимент, вариант не логируется или меняется между сессиями. Поэтому первое действие — проверить логику назначения, критерии включения и идентификаторы, по которым дедуплицируются пользователи. Только после устранения причины SRM можно доверять результатам A/B-теста. Раскатка или замена метрики проблему не решат.
Подробный разбор → 20A/B-тест дал рост основной метрики, но слегка ухудшились две защитные метрики (например, ошибки и отписки). Какой подход к решению наиболее зрелый?
AСчитать защитные метрики ограничениями: оценить серьёзность ухудшения, разобраться в причинах и раскатывать только при приемлемом риске
BИгнорировать защитные метрики как второстепенные: они не должны блокировать релиз при подтверждённом росте основной метрики продукта
CОткатывать изменение при любом ухудшении защитной метрики, независимо от масштаба эффекта, контекста запуска и причин снижения
DСрочно увеличить долю тестовой группы для быстрого подтверждения статистикой, что просадка защитных метрик это случайный шум
Ответ: Защитные метрики работают как ограничения риска: их ухудшение требует оценки и действий, а не автоматического игнорирования.
В продукте часто бывают компромиссы: рост результата может сопровождаться побочными эффектами. Зрелый подход — заранее определить, какие защитные метрики критичны и какие изменения неприемлемы, а также понимать причины деградации. Часто решение — доработка, ограниченное раскатывание на безопасный сегмент или запуск с усиленным мониторингом, а не автоматическое игнорирование или откат без анализа.
Подробный разбор → Другие темы: Продуктовая аналитика