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