Если вы хотите ускорить принятие решений в performance маркетинге, возможно, вы проводите A/B-тесты неправильным методом. Классический частотный тест работает с фиксированным размером выборки и фиксированным горизонтом: вы запускаете тест, ждёте 2–4 недели, не трогаете его, пока p-value не упадёт ниже порога. На этом этапе winning variant уже очевиден, но вы не можете принять решение. Байесовский подход меняет эту критическую точку: с помощью posterior probability вы можете оценивать решение в любой момент, проводить sequential testing и держать размер выборки динамичным. Закрытие Google Optimize не убило этот метод — наоборот, открыло возможность интегрировать его в собственный stack.

Временная ловушка частотного тестирования

Классическая логика A/B-теста работает так: тест должен продолжаться, пока p-value не упадёт ниже 0,05, потому что промежуточная проверка (intermediate peek) повышает риск ложноположительного результата. Теоретически это верно, но на практике порождает две проблемы. Во-первых: если вы хотите остановить тест рано, у вас нет статистических гарантий — риск неправильного решения возрастает. Во-вторых: даже если winning variant становится очевидным рано, вы должны ждать, пока будет набран фиксированный размер выборки — это обычно 14–21 день.

В основе этого подхода лежит фреймворк гипотез Неймана–Пирсона: вы принимаете или отклоняете нулевую гипотезу на основе единого порога (обычно α = 0,05). Проблема в том, что этот порог зависит от фиксированного расчёта размера выборки, поэтому во время теста вы не можете принимать динамические решения. Например, если вариант B показывает 18% конверсий, контроль — 12%, и это различие проявилось после 500 пользователей, частотный подход говорит: "Подожди, ты не достиг планового количества в 2000 пользователей".

В мобильных приложениях эта проблема ещё острее. Если daily active users равен 5000, для выявления 2% uplift нужна выборка из ~8000 пользователей — это 2 недели. Но если сигнал победителя появляется в день 3, вы 11 дней отправляете трафик на проигрывающий вариант. Это потерянная возможность заработка (opportunity cost).

Байесовский подход: постоянное обновление с posterior probability

Байесовская статистика задаёт другой вопрос: "Какова вероятность того, что этот вариант лучше контрольной группы?" Ответ — это не p-value, а posterior probability distribution. С каждой новой точкой данных (каждым новым пользователем) вы обновляете prior belief и пересчитываете posterior. Это позволяет вам говорить: "Вариант B с вероятностью 95% имеет более высокий коэффициент конверсии, чем контроль" — и это утверждение разрешает sequential testing.

Математически теорема Байеса работает так:

P(θ|данные) = P(данные|θ) × P(θ) / P(данные)

Здесь θ — коэффициент конверсии, P(θ) — prior (ваше начальное убеждение), P(данные|θ) — likelihood (вероятность наблюдаемых данных при θ), P(θ|данные) — posterior (ваше текущее убеждение). Например, если вы используете Beta(1,1) в качестве prior — то есть равномерное распределение, — каждая конверсия увеличивает параметр α на +1, каждый отскок увеличивает β на +1. 100 посетителей, 18 конверсий = Beta(19, 83). Вы сравниваете этот posterior с posterior контрольной группы, чтобы вычислить "вероятность B > A".

Статья Криса Стуччио 2015 года в VWO была одной из первых case studies, перенёсших эту логику в production: когда вы запускаете тот же тест байесовским методом, вы получаете результат на 40% быстрее в среднем, потому что риск ранней остановки контролируется. Внутренний фреймворк экспериментирования Google с 2018 года начал использовать байесовские posterior'ы в качестве промежуточного метрика (публичной документации нет, но это упоминается в книге Kohavi et al.).

Sequential testing и правило остановки

Самое большое преимущество байесовского подхода — вы можете проводить sequential testing. В частотном подходе вычисление p-value при промежуточной проверке раздувает Type I error (проблема множественных сравнений). В байесовском подходе posterior probability всегда является корректной метрикой, потому что это постоянно обновляемое состояние убеждения. Поэтому вы можете проверять "posterior probability of B > A" каждый день и останавливать тест, когда она превысит 95%.

Правило остановки работает так:

  1. Установите минимальный размер выборки (например, 200 пользователей на вариант — для фильтрации раннего шума)
  2. Каждый день обновляйте posterior'ы
  3. Когда P(вариант_B > контроль) > 0.95, остановите тест
  4. Если через 14 дней не достигли 95%, отметьте как "inconclusive"

Мы используем этот подход в процессах оптимизации коэффициента конверсии: установка prior в начале теста, автоматическое ежедневное обновление posterior, совместное определение порога stopping rule с инженерной командой. Например, при тестировании checkout flow электронной коммерции мы используем пороговое значение 98% вместо 95%, потому что стоимость ложноположительного результата высока — изменение страницы оплаты напрямую влияет на объём транзакций.

Динамический размер выборки и расчёт ожидаемых потерь

В частотном тестировании размер выборки рассчитывается заранее с помощью power analysis: вы указываете minimum detectable effect (MDE), statistical power (80%), уровень значимости (α = 0,05), и получаете число для ожидания. В байесовском подходе размер выборки динамичен, потому что posterior distribution может привести вас к раннему результату. Но это не означает "останавливайся, когда захочешь" — вступает в силу концепция ожидаемых потерь (expected loss).

Expected loss — это ожидаемая стоимость неправильного решения. Допустим, posterior показывает, что вариант B выигрывает с вероятностью 92%. Но есть 8% вероятность, что A лучше, и если вы выберете B, вы потеряете uplift. Expected loss превращает этот сценарий в числовое значение:

E[Loss_B] = ∫ max(0, θ_A - θ_B) × P(θ_A, θ_B | данные) dθ

На практике это выглядит так: "Если я выберу B и ошибусь, ожидаемые потери составят 0.3 пункта в коэффициенте конверсии". Это значение можно перевести в денежные единицы — например, 10 000 sessions в день, потеря 0,3% = 30 потерянных конверсий, помножить на средний объём заказа и получить дневные потери.

Калькулятор Bayesian A/B Testing от Evan Miller'а автоматизирует этот расчёт: вы вводите количество конверсий и размер выборки для контроля и варианта, он возвращает posterior, expected loss и вероятность лучшего варианта. Этого инструмента недостаточно для production deployment, но он идеален для понимания концепции. В production мы используем posterior sampling через Python pymc или R rstan и вычисляем expected loss методом Монте-Карло.

Перспектива минимизации сожаления (regret)

Из литературы по multi-armed bandit приходит концепция regret. В A/B-тесте regret — это общие потери от того, что вы не выбрали оптимальный вариант. Байесовское sequential testing пытается минимизировать это, потому что когда winning signal появляется рано, вы быстро принимаете решение. В частотном подходе regret растёт линейно в течение теста (потому что вы продолжаете отправлять трафик на проигрывающий вариант), в байесовском — сублинейно благодаря ранней остановке.

Расчёт regret критичен при тестировании landing page электронной коммерции. Например, если у вас есть 48-часовое окно теста в преддверии Black Friday. Частотное планирование требует 2000 размер выборки, и если дневной трафик составляет 3000, вы можете не завершить тест. С байесовским подходом, если через 12 часов вы получите 97% posterior, вы можете принять решение, открыть winning variant для 100% трафика в оставшиеся 36 часов и свести regret к нулю.

Практическая реализация: Python pipeline для байесовского A/B-теста

Перейдём от теории к практике. Вот простой pipeline, который извлекает данные теста из BigQuery, рассчитывает posterior и проверяет правило остановки:

import numpy as np
from scipy.stats import beta

def calculate_posterior(conversions, trials, prior_alpha=1, prior_beta=1):
    """Рассчитай posterior используя сопряженный prior Beta-Binomial"""
    return beta(prior_alpha + conversions, prior_beta + trials - conversions)

def prob_b_beats_a(posterior_a, posterior_b, samples=100000):
    """Рассчитай P(B > A) используя Monte Carlo"""
    samples_a = posterior_a.rvs(samples)
    samples_b = posterior_b.rvs(samples)
    return (samples_b > samples_a).mean()

def expected_loss(posterior_a, posterior_b, samples=100000):
    """Рассчитай ожидаемые потери, если выберешь B"""
    samples_a = posterior_a.rvs(samples)
    samples_b = posterior_b.rvs(samples)
    loss = np.maximum(0, samples_a - samples_b)
    return loss.mean()

# Пример данных: контроль 1000 сессий / 120 конверсий, вариант 1000 / 145
posterior_control = calculate_posterior(120, 1000)
posterior_variant = calculate_posterior(145, 1000)

prob_win = prob_b_beats_a(posterior_control, posterior_variant)
loss_variant = expected_loss(posterior_control, posterior_variant)

print(f"P(Вариант > Контроль): {prob_win:.3f}")
print(f"Ожидаемые потери, если выбрать вариант: {loss_variant:.4f}")

# Правило остановки
if prob_win > 0.95 and loss_variant < 0.01:
    print("РАЗВЕРНУТЬ ВАРИАНТ")
elif prob_win < 0.05:
    print("РАЗВЕРНУТЬ КОНТРОЛЬ")
else:
    print("ПРОДОЛЖИТЬ ТЕСТ")

Вы можете встроить этот код в dbt модель, запускать его по дневному расписанию. Если в BigQuery есть таблица test_id, variant, session_count, conversion_count, вы можете рассчитать posterior как Python UDF и записать результат в новую таблицу. Привяжите к Looker или Metabase dashboard — product team увидит posterior график в реальном времени.

Компромиссы и когда оставаться при частотном подходе

Байесовский подход не универсален. Есть три сценария:

1. Тесты, требующие нормативного соответствия: В испытаниях лекарств, финансовом секторе, моделировании страховых премий частотный p-value стал стандартом, признанным регуляторами вроде FDA/EMA. Если вы используете байесовский posterior, потребуется дополнительная документация.

2. Очень низкий базовый уровень: Например, коэффициент конверсии 0,5% на шаге воронки. Выбор байесовского prior становится критичным. С неинформативным prior (Beta(1,1)) сложно отделить сигнал от шума; если использовать информативный prior, возникает риск субъективного смещения. В таких случаях частотный подход кажется "безопаснее".

3. Единовременные масштабные кампании: Например, годовой тест landing page Black Friday. Если вы проведёте раннюю остановку в байесовском подходе и окажетесь неправы, вы не сможете откат