A/B-тесты в продуктовой аналитике: вопросы для собеседования (часть 2)
Как выбрать метрику для эксперимента, интерпретировать результаты и принять решение о раскатке — продуктовый взгляд на A/B-тесты. На собеседовании дают кейс: «тест показал рост кликов, но падение retention — что делать?» Здесь важна не статистика, а продуктовое мышление и умение балансировать метрики.
Вопросы 6–10 из 20
6Вы тестируете новую страницу товара; цель — увеличить покупки. Какая метрика наиболее логична как `primary metric` для решения о запуске?
AСреднее время на странице товара
BКонверсия в покупку (`purchase_conversion`) среди пользователей, увидевших страницу
CКоличество скроллов на странице
DКоличество просмотренных изображений товара
Ответ: `primary metric` должна напрямую отражать цель эксперимента, а не промежуточные действия.
Если продуктовая цель — покупки, то решающая метрика должна измерять именно покупку или шаг, максимально близкий к ней. Время на странице и скроллы могут быть полезными диагностическими показателями, но они легко растут из-за фрикции. Поэтому их уместнее держать как дополнительные, а `purchase_conversion` — как `primary metric`.
7Что в `A/B test` обычно означает разделение на `control` и `treatment`?
A`control` — прошлый месяц, `treatment` — текущий месяц
B`control` — пользователи из одного города, `treatment` — из другого
C`control` — базовый опыт без изменения, `treatment` — вариант с изменением, распределение происходит случайно
D`treatment` всегда получает больше трафика, чтобы быстрее набрать статистику
Ответ: `control/treatment` — это два варианта опыта, которые сравнивают при случайном распределении пользователей.
В `control` пользователи видят текущую версию продукта, а в `treatment` — экспериментальное изменение. Ключевой принцип — рандомизация, чтобы группы были сопоставимы по составу. Сравнение разных месяцев или городов без рандомизации легко смешивает эффект фичи с внешними факторами, например `seasonality`.
8Какая формулировка лучше всего соответствует проверяемой `hypothesis` для `A/B test`?
AЕсли добавить подсказку с итоговой стоимостью доставки на чекауте, то `primary metric` `purchase_conversion` вырастет, а `guardrail metric` `refund_rate` не ухудшится
BСделаем чекаут удобнее, чтобы пользователям больше нравилось
CНужно увеличить выручку, поэтому сделаем новый дизайн
DНовый дизайн чекаута точно улучшит все метрики
Ответ: Хорошая `hypothesis` связывает изменение с ожидаемым эффектом и явно называет `primary metric` и `guardrail metric`.
Проверяемая `hypothesis` должна содержать: что меняем, для кого, какой ожидаем эффект и как именно его измеряем. Вариант с `purchase_conversion` и `refund_rate` задаёт и критерий успеха, и ограничение риска. Остальные варианты слишком расплывчаты: они не фиксируют метрику, не задают проверяемый ожидаемый результат и легко приводят к спорной интерпретации итогов.
9Вы смотрите результаты `A/B test` каждый день и останавливаете эксперимент, как только `primary metric` стала «значимо лучше». Какой риск вы повышаете в первую очередь?
AРиск `SRM`, потому что частый просмотр меняет сплит
BРиск `seasonality`, потому что статистика зависит от дня недели
CРиск ложноположительного вывода из-за `peeking` (подглядывания) и остановки на случайном пике
DРиск, что `control` увидит `treatment`
Ответ: `peeking` часто приводит к остановке на шуме и повышает шанс принять случайность за эффект.
Если многократно смотреть на метрику и принимать решение по первому удачному моменту, вероятность ошибочно «найти победителя» растёт. Это не обязательно связано с `SRM` или `seasonality`, а именно с процедурой принятия решения. Чтобы снизить риск, заранее фиксируют правило остановки или используют корректный последовательный подход к остановке.
10Какую проверку разумно сделать до обсуждения эффекта по `primary metric`, чтобы быстрее поймать проблемы качества данных и `SRM`?
AПроверить только финальную метрику и игнорировать всё остальное
BПроверить баланс групп и базовые инварианты (размеры `control/treatment`, платформы, страны) и убедиться, что нет `SRM`
CУдалить пользователей с редкими событиями, чтобы метрика стала стабильнее
DСмешать `control` и `treatment` в одну группу и пересчитать метрику
Ответ: Санити-проверки и поиск `SRM` помогают убедиться, что сравнение `control/treatment` корректно ещё до интерпретации эффекта.
Даже хороший эксперимент может быть испорчен ошибкой назначения, фильтрами или логированием. Проверка размеров групп и базового состава по сегментам помогает заметить `SRM` и перекосы. Если такие проблемы есть, обсуждать эффект по `primary metric` бессмысленно, пока не восстановлена валидность данных.
Хотите тренировать интерактивно?
В приложении — таймер, прогресс, стрики и 1700+ вопросов по всем темам.
Тренировать в TelegramДругие темы: Продуктовая аналитика