A/B-тесты в продуктовой аналитике: вопросы для собеседования (часть 4)
Как выбрать метрику для эксперимента, интерпретировать результаты и принять решение о раскатке — продуктовый взгляд на A/B-тесты. На собеседовании дают кейс: «тест показал рост кликов, но падение retention — что делать?» Здесь важна не статистика, а продуктовое мышление и умение балансировать метрики.
Вопросы 16–20 из 20
16Почему `A/B test` обычно запускают параллельно на `control` и `treatment`, а не сравнивают `treatment` с прошлым месяцем?
AПараллельный запуск делает `rollout` не нужен
BПрошлый месяц всегда меньше по трафику
CПараллельный запуск устраняет `SRM` автоматически
DСравнение с прошлым месяцем смешивает эффект изменения с `seasonality` и внешними факторами, а `control` помогает их контролировать
Ответ: Параллельные `control/treatment` лучше изолируют эффект и снижают влияние `seasonality`.
При сравнении с прошлым месяцем меняются рекламные кампании, праздники, конкуренты и другие условия. Это делает вывод «фича улучшила метрику» сомнительным, потому что нет сопоставимого `control`. В `A/B test` группы идут одновременно, поэтому внешние факторы действуют на обе стороны примерно одинаково, и разница ближе к эффекту изменения.
17Команда хочет иметь возможность останавливать эксперимент раньше, если эффект явно плохой или явно хороший. Что лучше всего сделать, чтобы снизить риск `peeking`?
AЗаранее определить правила ранней остановки и использовать согласованный критерий (например, последовательный подход), а не принимать решение по «глазу»
BОстанавливать, когда менеджер считает, что данных достаточно
CВсегда смотреть метрики каждый час и останавливать на пике
DЗапускать тест только в выходные, чтобы быстрее увидеть эффект
Ответ: Если нужна ранняя остановка, правила должны быть заранее определены, иначе `peeking` делает выводы ненадёжными.
Ранняя остановка возможна, но она должна быть частью заранее согласованного процесса. Иначе вы многократно проверяете гипотезу и рискуете остановиться на случайном колебании. Правильная практика — зафиксировать, при каких условиях эксперимент останавливается по `primary metric` и `guardrail metric`, и придерживаться этих условий.
18Эксперимент попал на распродажу, которая сильно меняет поведение. Какое утверждение наиболее корректно про `seasonality` в этом случае?
A`seasonality` не важна, если тест идёт достаточно долго
B`seasonality` опасна: результат может отражать влияние распродажи; важно иметь параллельный `control` в те же даты и аккуратно интерпретировать переносимость эффекта
C`seasonality` означает только ошибку `SRM`
DЛучше полностью убрать `control`, чтобы не мешал распродаже
Ответ: `seasonality` и внешние события могут менять базовый уровень метрик, поэтому важны параллельный `control` и осторожная интерпретация.
Даже при корректном `A/B test` распродажа может менять состав трафика и мотивацию пользователей, поэтому эффект фичи может проявляться иначе, чем в обычные дни. Параллельный `control` помогает сравнивать варианты в одинаковых условиях. Но при сильной `seasonality` важно проверить, как эффект выглядит по дням и сегментам, и оценить, переносится ли он на обычный период перед `rollout`.
19Вы подозреваете `SRM`: в `treatment` меньше пользователей, чем ожидалось, и перекошены платформы. Что из перечисленного наиболее уместно проверить в первую очередь?
AПерерисовать графики метрики, чтобы тренд выглядел ровнее
BСразу запускать полный `rollout`, чтобы собрать больше данных
CПроверить логику назначения `control/treatment`, фильтры включения, дедупликацию идентификаторов и корректность логирования варианта
DЗаменить `primary metric`, потому что текущая метрика «ломает» распределение
Ответ: `SRM` чаще всего вызван проблемой назначения или сбора данных, поэтому начинать нужно с пайплайна `control/treatment`.
При `SRM` разница между группами может появиться не из-за фичи, а из-за багов: часть пользователей не попадает в эксперимент, вариант не логируется или меняется между сессиями. Поэтому первое действие — проверить assignment-логику, критерии включения и идентификаторы, по которым дедуплицируются пользователи. Только после устранения причины `SRM` можно доверять результатам `A/B test`.
20`A/B test` дал рост `primary metric`, но слегка ухудшились две `guardrail metrics` (например, ошибки и отписки). Какой подход к решению наиболее зрелый?
AИгнорировать `guardrail metric`, потому что они второстепенные
BВсегда откатывать, независимо от масштаба эффекта и контекста
CСчитать `guardrail metrics` ограничениями: оценить серьёзность ухудшения, провести расследование причин и принимать решение о `rollout` только если риск приемлем или устранён
DСрочно увеличить долю `treatment`, чтобы быстрее «доказать», что `guardrail metrics` не важны
Ответ: `guardrail metrics` нужны как ограничения риска: их ухудшение требует оценки и действий, а не автоматического игнорирования.
В продукте часто бывают компромиссы: рост результата может сопровождаться побочными эффектами. Зрелый подход — заранее определить, какие `guardrail metrics` критичны и какие изменения неприемлемы, а также понимать причины деградации. Часто решение — доработка, ограниченный `rollout` на безопасный сегмент или запуск с усиленным мониторингом.
Хотите тренировать интерактивно?
В приложении — таймер, прогресс, стрики и 1700+ вопросов по всем темам.
Тренировать в TelegramДругие темы: Продуктовая аналитика