Какую проверку разумно сделать до обсуждения эффекта по primary metric, чтобы быстрее поймать проблемы качества данных и SRM?
AПроверить только финальную метрику и игнорировать всё остальное
BПроверить баланс групп и базовые инварианты (размеры
control/treatment, платформы, страны) и убедиться, что нет SRMCУдалить пользователей с редкими событиями, чтобы метрика стала стабильнее
DСмешать
control и treatment в одну группу и пересчитать метрикуПравильный ответ. Санити-проверки и поиск
SRM помогают убедиться, что сравнение control/treatment корректно ещё до интерпретации эффекта.Разбор
Даже хороший эксперимент может быть испорчен ошибкой назначения, фильтрами или логированием. Проверка размеров групп и базового состава по сегментам помогает заметить SRM и перекосы. Если такие проблемы есть, обсуждать эффект по primary metric бессмысленно, пока не восстановлена валидность данных.
Проверь себя · 1/3разбор после ответа
Вы тестируете новую страницу товара; цель — увеличить покупки. Какая метрика наиболее логична как
primary metric для решения о запуске?Ещё вопросы по теме «A/B-тесты в продуктовой аналитике»
- Какая формулировка лучше всего соответствует проверяемой `hypothesis` для `A/B test`?
- Что в `A/B test` обычно означает разделение на `control` и `treatment`?
- Вы тестируете новую страницу товара; цель — увеличить покупки. Какая метрика наиболее логична как `primary metric` для решения о запуске?
- Вы увеличиваете частоту push-уведомлений, ожидая рост заказов. Какая метрика наиболее уместна как `guardrail metric`?
- Когда `A/B test` обычно предпочтительнее, чем сразу делать полный `rollout` изменения?
- Все вопросы по «A/B-тесты в продуктовой аналитике» →