🧪 A/B-тесты

Короткий ответ Помимо проверки соотношения размеров групп (SRM), нужно проверить баланс ковариат — характеристик пользователей, которые не должны зависеть от группы (платформа, страна, устройство, историческая активность до теста), чтобы убедиться, что группы сопоставимы не только по численности, но и по составу. Как это работает подробнее Как это работает: для каждой ковариаты сравнивают распределение между группами (например, долю iOS/Android или среднюю активность за месяц до теста); при корректной рандомизации различия должны быть статистически не значимы и малы по величине на большой выборке. Ожидаемый результат: p-value для разницы в pre_activity_30d должен быть заметно больше 0.05 (нет значимой разницы) — иначе это сигнал, что рандомизация могла быть нарушена. Пример кода Что использовать на практике На практике: такую проверку, известную как pre-test / A/A-like баланс-чек, часто автоматизируют как часть стандартного отчёта по тесту: таблица 'ковариата — значение в A — значение в B — p-value' для набор

Читать полностьюab-testing

Короткий ответ Размер выборки на группу рассчитывается по формуле для сравнения двух долей на основе базовой конверсии, желаемого MDE, уровня значимости alpha и мощности теста; обычно это делают через калькулятор или библиотеку, а не вручную по формуле каждый раз. Как это работает подробнее формула для сравнения двух пропорций использует дисперсию биномиального распределения при базовой конверсии p1, ожидаемой конверсии p2=p1+MDE, и квантили нормального распределения для alpha и мощности; итоговый размер выборки растёт при уменьшении MDE и росте требуемой мощности. Пример кода Что использовать на практике перед запуском теста считают n через готовую функцию (например, statsmodels.stats.power в Python) и сверяют с доступным трафиком за разумный срок — если трафика не хватает, пересматривают MDE или длительность, а не 'запускаем и посмотрим'. Ожидаемый результат: n ≈ 15700 пользователей на группу. Проверка: при увеличении MDE (например, до 1 п.п.) n должно заметно уменьшиться — это sanity check корректности нап

Читать полностьюalpha

Короткий ответ Сезонность (дни недели, праздники, распродажи) может менять базовый уровень и вариативность метрики независимо от теста, поэтому план теста должен покрывать репрезентативный период, а интерпретация результатов, собранных вокруг аномального периода (например, праздников), должна учитывать, что эффект может быть нетипичным для обычных недель. Как это работает подробнее Как это работает: во время праздников поведение пользователей (импульсивные покупки, иной состав аудитории, другой трафик из рекламы) может отличаться настолько, что эффект изменения, измеренный в этот период, не переносится на обычные недели — risk of внешней невалидности результата. Пример: тест шёл 7 дней, включая Новый год, конверсия в B выросла на 1.5 п.п. При разбивке по дням видно, что весь эффект сосредоточен в 2 праздничных днях, а в оставшиеся 5 дней разница близка к нулю. Вывод для отчёта: «наблюдаемый эффект может быть специфичен для праздничного периода, требуется повторная проверка на обычных неделях». Что использоват

Читать полностьюab-testing

Короткий ответ Долгосрочный holdout — это группа пользователей, систематически исключаемая из всех или большинства новых раскаток в течение длительного периода (например, квартала), что позволяет оценить суммарный эффект множества отдельных изменений, который часто отличается от суммы их индивидуальных эффектов, измеренных в отдельных короткопериодных тестах; подход ценный, но дорогой и методологически небезупречный, единственного правильного способа его реализации нет. Как это работает подробнее Как это работает: отдельные A/B-тесты часто измеряют краткосрочный эффект одной фичи изолированно, в то время как долгосрочный holdout накапливает совместное воздействие многих изменений, включая их взаимодействие друг с другом и постепенные эффекты привыкания/усталости пользователей, которые невозможно увидеть в двухнедельном тесте. Пример: 5% пользователей находятся в постоянно ротируемом holdout (не получают раскатки последних 90 дней), ежеквартально сравнивается North Star метрика holdout vs остальной базы с учёт

Читать полностьюab-testing

Короткий ответ Единой универсальной системы метрик нет: North Star метрика должна отражать долгосрочную ценность для пользователя и бизнеса одновременно (а не просто вовлечённость саму по себе), дополняться набором guardrail-метрик, защищающих от известных рисков локальной оптимизации (злоупотребление, усталость, качество контента), и периодически пересматриваться, так как любая фиксированная метрика со временем начинает 'играться' командами (закон Гудхарта). Как это работает подробнее Как это работает: North Star обычно выбирают как метрику, которая исторически коррелирует и с удовлетворённостью пользователя, и с бизнес-результатом (например, число успешно решённых задач пользователя в неделю, а не просто время в приложении, которое можно нарастить навязчивостью); guardrails подбираются под известные способы 'читерства' метрики — например, рост engagement за счёт спама уведомлениями. Пример структуры: North Star = «число успешных завершений ключевого сценария на активного пользователя в неделю». Guardrails:

Читать полностьюab-testing

Короткий ответ Для сравнения двух конверсий (биномиальные доли) обычно используют z-тест для разности пропорций или эквивалентный chi-square тест (для таблицы 2x2 они дают математически согласованные результаты); t-тест для независимых выборок уместен для непрерывных метрик (например, среднего чека), а не для бинарных конверсий, хотя на больших выборках численно даёт близкий результат к z-тесту. Как это работает подробнее Как это работает: z-тест и chi-square тест для таблицы 2x2 проверяют одну и ту же нулевую гипотезу о равенстве долей и при двустороннем сравнении дают эквивалентные p-value, так как chi-square статистика является квадратом z-статистики; t-тест основан на предположении о приблизительно нормальном распределении метрики внутри группы, что лучше подходит для непрерывных величин с ограниченной асимметрией. Пример в Python: Для среднего чека с длинным хвостом вместо t-теста можно применить bootstrap-доверительный интервал разницы медиан или средних с 10 000 ресэмплов — это устойчивее к выбросам, ч

Читать полностьюab-testing

Короткий ответ При проверке множества метрик без поправки вероятность получить хотя бы одну ложноположительную значимость существенно выше заявленного alpha для одной метрики — это проблема множественных сравнений. Для контроля общей ошибки применяют поправки, например Bonferroni или Holm, или заранее ограничивают число ключевых метрик. Как это работает подробнее при независимых метриках и alpha=0.05 вероятность хотя бы одного ложного срабатывания среди m метрик растёт примерно как 1-(1-alpha)^m; при m=10 это уже около 40%, а не 5%. Пример кода Что использовать на практике поправка Bonferroni делит alpha на число сравнений (alpha/m для каждой метрики) — простая, но консервативная; поправка Holm менее консервативна и последовательно применяет пороги к отсортированным p-value. Альтернатива — заранее выделить 1-2 основные метрики, а остальные считать вторичными/guardrail без строгого вывода о значимости. Ожидаемый результат: после поправки Holm часть из изначально 'значимых' p-value (0.01, 0.02, 0.03, 0.04) могу

Читать полностьюbonferroni

Короткий ответ Sequential-методы (например, на основе mSPRT или alpha-spending) действительно позволяют легитимно проверять результат многократно и останавливаться раньше без инфляции ошибки I типа, но требуют заранее встроенной в методологию готовности к этому (а не применения постфактум к данным, собранным для fixed-horizon теста), обычно требуют больше данных для того же MDE при досрочной остановке, и сложнее в коммуникации с нетехническими стейкхолдерами; единственно верного решения о переходе нет — это зависит от культуры принятия решений в компании и зрелости инфраструктуры. Как это работает подробнее Как это работает: always-valid p-value строится так, что вероятность ложного срабатывания остаётся под контролем alpha в любой момент времени проверки, а не только в заранее фиксированной точке, за счёт более консервативного порога значимости на каждом шаге, который компенсирует многократность проверок математически, а не эвристически. Пример (концептуально, mSPRT-подобный подход): вместо порога p<0.05 на

Читать полностьюab-testing

Короткий ответ Пересечение по отдельности построенных доверительных интервалов групп A и B — не то же самое, что незначимость разницы между ними; правильный вывод о значимости разницы нужно делать по доверительному интервалу или p-value именно для разницы (B - A), а не по перекрытию интервалов отдельных групп. Как это работает подробнее интервал для разницы групп обычно уже, чем можно было бы наивно предположить по перекрытию двух отдельных интервалов, потому что он строится с учётом дисперсии именно разности, а не каждой группы по отдельности. Пример: CR_A = 10.0% ± 0.5 п.п. (ДИ [9.5; 10.5]), CR_B = 11.0% ± 0.6 п.п. (ДИ [10.4; 11.6]) — интервалы слегка пересекаются в точке 10.4-10.5. Но при этом ДИ для разницы (B-A) может быть, например, [+0.2; +1.8] п.п., не пересекающий ноль — то есть разница статистически значима, хотя интервалы отдельных групп визуально перекрываются. Что использовать на практике для вывода о значимости нужен либо явный p-value теста сравнения групп, либо ДИ, построенный непосредственно

Читать полностьюdoveritelnyy-interval