A/B-тесты в продуктовой аналитике: вопросы для собеседования (часть 3)
Как выбрать метрику для эксперимента, интерпретировать результаты и принять решение о раскатке — продуктовый взгляд на A/B-тесты. На собеседовании дают кейс: «тест показал рост кликов, но падение retention — что делать?» Здесь важна не статистика, а продуктовое мышление и умение балансировать метрики.
Вопросы 11–15 из 20
11Команда хочет оценивать успех по 6 метрикам сразу и «выбирать лучшую после теста». Как корректнее поступить до старта A/B-теста?
AЗаранее зафиксировать одну основную метрику, остальные оформить как диагностические и защитные
BНазначить все 6 метрик основными одновременно, чтобы не упустить ни одну возможную победу
CНе фиксировать метрики и критерии успеха до старта, чтобы оставить свободу анализа после данных
DОпираться на ту метрику, по которой получился самый большой рост в результатах теста
Ответ: Одна основная метрика снижает риск «найти победу» случайно, а защитные метрики ограничивают риск побочных эффектов.
Когда метрик успеха много, легко выбрать «понравившуюся» постфактум и получить неверное решение. Хорошая практика — заранее определить основную метрику, по которой принимается решение, и список диагностических показателей. Защитные метрики фиксируют как ограничения: если они ухудшаются, даже рост основной метрики может быть неприемлем.
Подробный разбор → 12Эксперимент показал улучшение основной метрики и отсутствие проблем по защитным метрикам. Какой план запуска чаще всего считается наиболее безопасным?
AСразу выкатить функцию на 100% аудитории и перестать смотреть метрики, потому что эксперимент уже подтвердил эффект
BПовторять эксперимент бесконечно на тех же пользователях и не выкатывать функцию никогда, чтобы исключить любые возможные риски
CСделать поэтапную раскатку (например, 5% → 25% → 50% → 100%) с мониторингом защитных метрик на каждом шаге запуска
DСделать раскатку только на новых пользователей и игнорировать остальных пользователей продукта в дальнейших шагах
Ответ: Поэтапная раскатка снижает риск и позволяет заметить деградацию защитных метрик на ранних шагах запуска.
Даже успешный эксперимент может не покрыть редкие баги, нагрузки или новые сегменты трафика. Поэтому часто делают постепенную раскатку с контролем защитных метрик (стабильность, ошибки, отписки) и готовностью откатиться при деградации. Это превращает запуск в управляемый процесс, а не в одноразовое решение, и снижает риск массовых жалоб от пользователей.
Подробный разбор → 13Вы тестируете изменение в рекомендациях, и один пользователь может зайти несколько раз. Какой выбор единицы рандомизации чаще всего снижает риск смешения контрольной и тестовой групп для одного и того же человека?
AРандомизация на уровне отдельного события: быстрее набрать выборку и за тот же период получить больше точек данных для статзначимости
BРандомизация на уровне пользователя: один и тот же человек попадает в одну группу и не видит сразу оба варианта изменения
CРандомизация на уровне отдельной страницы: один и тот же пользователь видит оба варианта и команда сразу собирает обратную связь
DРандомизация на уровне региона или города: проще анализировать результаты по геозонам и не пересекаться с маркетинговыми кампаниями
Ответ: Для большинства продуктовых метрик безопаснее фиксировать вариант на уровне пользователя, чтобы не смешивать контроль и тест.
Если один пользователь видит разные варианты, его поведение может зависеть от сравнения или путаться, и эффект станет трудно интерпретировать. Рандомизация по пользователю помогает избежать загрязнения: человек остаётся либо в контрольной, либо в тестовой группе. Это особенно важно, когда основная метрика измеряется на уровне пользователя или заказа. Рандомизация по событию или странице приводит к смешению вариантов внутри одного пользователя.
Подробный разбор → 14После запуска вы выяснили, что часть пользователей видит тестовую версию на вебе и контрольную в приложении из-за разных систем флагов. В чём главная проблема?
AПроисходит смешение тестовой и контрольной групп, и эффект эксперимента становится трудно интерпретировать корректно
BЭто улучшает учёт сезонности, потому что охватывается больше каналов и поведение пользователей усредняется по платформам
CНичего страшного: так выборка только увеличивается, а эффект усредняется по разным платформам и устройствам пользователя
DЭто помогает снизить риск ранних подглядываний в эксперимент, потому что итоговый результат усредняется по всем платформам
Ответ: Смешение тестовой и контрольной групп для одного пользователя размывает различия и ломает интерпретацию эффекта эксперимента.
Если один и тот же пользователь получает разные варианты в разных каналах, то сравнение групп перестаёт быть чистым. Контрольная группа может частично заражаться тестовой и наоборот, из-за чего эффект занижается или становится непредсказуемым. Обычно это решают единым источником флагов или согласованным ключом назначения варианта по единому идентификатору пользователя.
Подробный разбор → 15В тесте основная метрика растёт, но страховочная метрика по ошибкам и крэшам ухудшается. Какое действие наиболее корректно?
AОстановить или откатить эксперимент и сначала разобраться с деградацией страховочной метрики, прежде чем продолжать раскатку и интерпретировать рост основной
BИгнорировать страховочную метрику по ошибкам и крэшам, раз основная метрика растёт, и зафиксировать запуск как успешный без дополнительных проверок качества
CУвеличить долю трафика в тестовой группе, чтобы быстрее «перебить» рост ошибок улучшением основной метрики и закрыть эксперимент с положительным итогом
DСчитать метрики только в будние дни, чтобы убрать выходной шум, и таким образом сгладить ухудшение страховочной метрики до приемлемого уровня
Ответ: Страховочная метрика — это ограничение риска: при ухудшении запуск опасен, даже если основная метрика улучшается.
Смысл страховочной метрики — защищать качество продукта и стабильность. Рост основной метрики может быть краткосрочным и не оправдывает ухудшение по ошибкам или крэшам. Правильный процесс — остановить воздействие, локализовать проблему и повторить проверку после исправления. Игнорировать ухудшение, наращивать трафик или подгонять окно подсчёта — это способы спрятать риск, а не управлять им.
Подробный разбор → Другие темы: Продуктовая аналитика