Trustworthy experimentation для B2C: как перестать угадывать в A-B‑тестах

В продуктовой аналитике легко дойти до состояния, когда экспериментов много, а уверенности в решениях мало.

Типовые симптомы:

• тест идет «пока не станет понятно»;

• MDE забывают зафиксировать (или берут «как обычно»);

• p-value проверяют каждый день и закрывают эксперимент на первом же p < 0.05;

• ARPU и другие денежные метрики шумят так, что любой вывод спорный;

• после релиза эффект не подтверждается, в следствие чего доверие к экспериментам падает.

Чтобы доверять своим тестам, не попадаться в эти простые ловушки, нужно не так и много: заранее фиксировать минимально значимый эффект, понимать требования к размеру выборки и выбирать метрики так, чтобы они отвечали именно на ваш продуктовый вопрос.

Я собрал небольшой практический каркас для B2C‑экспериментов: расчёты мощности и размера выборки, дизайн метрик (включая ratio и линеаризацию) и high‑level дизайн эксперимента (MDE - sample size - duration).

Репозиторий: https://github.com/Niuhych/trustworthy-experiments-core/tree/main ^[1]

Что внутри репозитория

• src/tecore/power.py ^[2] — power analysis и sample size (пропорции и средние).

• src/tecore/metrics.py ^[3] — ratio‑метрики и линеаризация, вспомогательные функции для метрик.

• src/tecore/design.py ^[4] — high‑level дизайн эксперимента (MDE - sample size - duration).

Ноутбуки с примерами:

• notebooks/01_power_analysis_arpu_cr.ipynb

• notebooks/02_metric_design_b2c.ipynb

• notebooks/03_experiment_design_tradeoffs.ipynb

Анализ мощности теста: сколько пользователей нужно на самом деле

Кейс: конверсия (CR)

Пусть:

• baseline CR = 5%;

• хотим увидеть разницу в +1% (с 5% до 6%);

• alpha = 0.05 (two‑sided);

• target power = 0.80;

• равные группы.

Для разницы двух пропорций при равных группах нормальная аппроксимация даёт оценку:

Где:

• - размер выборки на группу;

• - базовая конверсия в контроле;

• - ожидаемая конверсия в тесте;

• - средняя конверсия между контролем и тестом;

• - критическое значение стандартного нормального распределения для уровня значимости alpha (для two-sided теста);

• - квантиль стандартного нормального распределения, соответствующий целевой мощности теста (power = 1 − beta);

• - абсолютный MDE (например, = +1%).

В коде:

from tecore.power import sample_size_proportions

p_baseline = 0.05
mde = 0.01  # +1 percentage point

res = sample_size_proportions(
    p_baseline=p_baseline,
    mde=mde,
    alpha=0.05,
    power=0.80,
    tail="two-sided",
)

print("n per group:", res.n_per_group)
print("total n:", res.n_total)

Для этих чисел получается порядка 8 159 пользователей на группу.

Дальше полезно смотреть не только оценку размера выборки, но и взглянуть на кривую мощности эксперимента: как мощность (power) растет при увеличении выборки.

Практический вывод: если вы не набираете нужный размер выборки, вы не «ускоряете» эксперимент, то есть повышаете вероятность получить отрицательный результат даже там, где эффект действительно есть.

Кейс: ARPU (средняя метрика)

Для разницы средних (равные группы, общий std) используется:

Где:

• - стандартное отклонение метрики в популяции (в единицах ARPU);

• - MDE, абсолютная разница средних (например, +0.30 ARPU);

• - как и с конверсией (критическое значение и квантиль для целевой мощности).

В коде:

from tecore.power import sample_size_means

std = 5.0
mde = 0.30  # +0.30 ARPU units

res = sample_size_means(
    std=std,
    mde=mde,
    alpha=0.05,
    power=0.80,
    tail="two-sided",
)

print("n per group:", res.n_per_group)
print("total n:", res.n_total)

Смысл здесь простой: при большом разбросе метрики даже умеренный MDE в единицах ARPU быстро превращается в тысячи пользователей на группу.

Метрики в B2C: почему ARPU часто отвечает на другой вопрос

ARPU выглядит естественной метрикой про деньги, но она часто смешивает два механизма:

• пользователи стали чаще пользоваться продуктом;

• каждая сессия стала приносить больше денег.

Если гипотеза именно про деньги на сессию, то метрика ARPU может быть зашумленной: активность пользователей неоднородна, распределения тяжелые, а вклад редких пользователей с большими значениями увеличивает дисперсию.

В таких случаях полезно смотреть ratio‑метрику выручка на сессию. На уровне групп она определяется так:

Где:

• — выручка i‑го пользователя за период;

• — количество сессий i‑го пользователя за период.

Важно: ratio‑метрика часто ближе к продуктовой гипотезе, чем ARPU, которая в реальности часто становится гибридом деньги × активность.

Линеаризация ratio‑метрик: как сделать user‑level тестирование удобным

Тестировать ratio бывает напрямую неудобно, если вы привыкли к user‑level фрейму. Один из практичных приемов - линеаризация.

Сначала оцениваем базовое значение ratio в контроле:

Дальше для каждого пользователя строим линеаризованную величину:

После этого сравниваем среднее z между группами обычным t‑test по пользователям.

Интерпретация:

• если эффект в основном в деньгах на сессию, линеаризация усиливает этот сигнал;

• если эффект в основном в количестве сессий, его лучше отдельно смотреть по y.

Trade‑offs: MDE, размер выборки и длительность эксперимента

Один из самых полезных разговоров с продуктом начинается с вопроса:

• какой эффект мы хотим видеть;

• сколько пользователей у нас реально будет в тесте;

• сколько дней мы готовы ждать.

Если у вас есть оценка дневного трафика, длительность эксперимента можно быстро прикинуть:

Идея простая: вы либо выбираете MDE и смотрите, сколько дней нужно, либо выбираете срок и получаете какой эффект вообще детектируем при вашем трафике.

Что дальше

Если коротко, мой подход такой:

• фиксируем MDE до запуска;

• обязательно делаем анализ мощности теста (ничего не принимаем на веру или не выбираем на глаз);

• выбираем метрику так, чтобы она соответствовала продуктовой гипотезе;

• где нужно используем ratio и линеаризацию, чтобы стабилизировать сигнал;

• заранее обсуждаем trade‑offs между MDE, длительностью и трафиком.

Если интересно, могу следующим постом разобрать:

• как аккуратно выбирать MDE (через бизнес‑эффект, экономику и ожидаемую вариативность);

• как не убить эксперимент «подглядыванием» (и когда имеет смысл sequential‑подход).