Сообщить об ошибкеКороткий ответ
Нужно сформулировать проверяемую гипотезу, выбрать одну основную метрику и guardrail-метрики, определить единицу рандомизации и уровень разбиения, заранее рассчитать размер выборки и длительность теста, и зафиксировать правило принятия решения до запуска.
Как это работает подробнее
гипотеза должна быть конкретной («изменение X увеличит метрику Y минимум на Z%»), а не расплывчатой («сделаем лучше»). Единица рандомизации (пользователь, сессия, устройство) выбирается так, чтобы избежать «утечек» эффекта между группами (например, один и тот же пользователь не должен видеть обе версии).
Пример кода
Схема эксперимента
Гипотеза: новая форма оформления заказа увеличит конверсию в покупку минимум на 1 п.п.
Единица рандомизации: user_id
Основная метрика: conversion_rate = purchases / unique_visitors
Guardrail: average_order_value, refund_rate
Альфа = 0.05, мощность = 0.8, MDE = 1 п.п.Что использовать на практике
- На практике. основная метрика должна быть одна и выбрана заранее, иначе возрастает риск p-hacking при проверке десятков метрик «постфактум». Guardrail-метрики (выручка, отмены, жалобы) нужны, чтобы убедиться, что улучшение основной метрики не произошло за счёт ухудшения чего-то важного. Длительность теста стоит выбирать с учётом недельной цикличности поведения пользователей (минимум один-два полных цикла), а не произвольно. Также полезно заранее согласовать критерии остановки теста не только по основной метрике, но и по guardrail-метрикам — например, автоматически приостанавливать тест при резком ухудшении возвратов или жалоб.
- Пример. Sanity check: перед запуском проверить, что распределение пользователей по группам действительно близко к 50/50 (SRM-проверка), а метрики групп до изменения (A/A-период) статистически не различаются.
Подводные камни
- Частые ошибки. запускать тест без предварительного расчёта размера выборки и просто «смотреть, когда наберётся достаточно данных»; менять основную метрику после начала теста, если первая не показывает ожидаемого результата; не учитывать, что часть пользователей может попасть в обе группы из-за багов в сплитовании (нужна проверка на SRM); останавливать тест досрочно при первом «значимом» результате без учёта накопленной ошибки от множественных проверок. Ещё одна ошибка — запускать тест на слишком узком сегменте аудитории (например, только на одной платформе), а затем обобщать результат на всю базу пользователей без проверки устойчивости эффекта в других сегментах.