A/B тесты на
маркетплейсе:
когда всё идёт не так

Когда вы тестируете кнопку на лендинге или цвет CTA — пользователи в контрольной и тестовой группах не влияют друг на друга. Видел синюю кнопку, не видел — независимые события. Классический A/B тест работает идеально.

Маркетплейс — другой зверь. Это двусторонний рынок: покупатели и продавцы существуют вместе, их поведение переплетено. Когда вы что-то меняете для одной группы пользователей, это рябью расходится на всех остальных — включая тех, кого вы не трогали.

Ключевое свойство двустороннего рынка — сетевые эффекты. Больше покупателей → продавцам выгоднее размещаться → больше предложений → покупателям лучше → ещё больше покупателей. Цикл замкнут.

Этот цикл делает A/B тест на маркетплейсе потенциально некорректным. Проверим через конкретный пример.

SUTVA — Stable Unit Treatment Value Assumption. Это фундаментальное допущение классической экспериментальной статистики. Звучит страшно, но смысл простой:

Переводя на русский: пользователь A не должен влиять на пользователя B только потому, что они оба участвуют в эксперименте. Если это условие нарушено — оценка эффекта смещена, p-value неверен, вывод может быть ложным в обе стороны.

Почему нарушение SUTVA так опасно

Когда SUTVA нарушено, оценка treatment effect смещается. Причём направление смещения непредсказуемо:

1. Сетевые эффекты через инвентарь

Самый распространённый тип. Продавцы не разделены между группами теста — один продавец может показываться как тестовым, так и контрольным пользователям. Его поведение (цены, ставки, запасы) меняется в ответ на агрегированный спрос.

2. Каннибализация (marketplace cannibalization)

Маркетплейс — рынок с ограниченным инвентарём. Хороший товар по хорошей цене существует в одном экземпляре. Если тестовый пользователь купил его первым — контрольному пользователю он уже недоступен.

3. Эффекты ценообразования и аукциона

На маркетплейсах с аукционным ценообразованием (рекламные позиции, buy box) воздействие на часть пользователей меняет аукционный баланс для всех. Продавцы оптимизируют ставки на основе общей статистики, не зная о тесте.

Все три механизма роднит одно: точка связи между группами — продавец или инвентарь. Именно поэтому рандомизация по пользователям-покупателям не изолирует группы в достаточной мере.

Хорошая новость: проблема известна, и у неё есть несколько рабочих решений. Выбор зависит от типа помехи, масштаба теста и возможностей инфраструктуры.

Диагностика: есть ли у вас проблема?

Не каждый тест на маркетплейсе нарушает SUTVA. Прежде чем усложнять дизайн, проверьте: есть ли реальный механизм spillover в вашем конкретном случае?

Как выбрать метод рандомизации

Расчёт мощности при кластерной рандомизации

Когда единица рандомизации — кластер (регион, продавец), стандартная формула размера выборки не работает. Нужно учесть intraclass correlation coefficient (ICC) — насколько сильно юниты внутри кластера похожи друг на друга.

-- ICC и Design Effect для кластерной рандомизации
-- Пример: кластеры = регионы, юниты = пользователи
WITH cluster_stats AS (
  SELECT
    city                         AS cluster_id,
    COUNT(*)                       AS n_users,
    AVG(conversion)               AS cluster_mean,
    VAR_POP(conversion)           AS within_var
  FROM user_experiment_data
  GROUP BY city
),
grand AS (
  SELECT
    AVG(cluster_mean)             AS grand_mean,
    VAR_POP(cluster_mean)         AS between_var,  -- дисперсия между кластерами
    AVG(within_var)               AS avg_within_var,
    AVG(n_users)                   AS avg_cluster_size
  FROM cluster_stats
)
SELECT
  grand_mean,
  between_var,
  avg_within_var,
  -- ICC = между_дисперсия / (между_дисперсия + внутри_дисперсия)
  ROUND(between_var / (between_var + avg_within_var), 4)
    AS icc,
  -- Design Effect = 1 + (m - 1) * ICC, где m = средний размер кластера
  ROUND(1 + (avg_cluster_size - 1)
    * (between_var / (between_var + avg_within_var)), 2)
    AS design_effect
FROM grand;

SQL: обнаружение spillover через метрики продавцов

Полезная диагностика — проверить, изменилось ли поведение продавцов в период теста. Если продавцы в «тестовых регионах» ведут себя иначе, чем в «контрольных» — spillover присутствует.

-- Сравниваем поведение продавцов в тестовых и контрольных регионах
-- Если продавец работает в обоих — он «заражает» контроль
WITH seller_exposure AS (
  SELECT
    p.seller_id,
    COUNT(DISTINCT CASE WHEN u.city IN ('Москва', 'Санкт-Петербург')
          THEN o.order_id END)  AS orders_treatment,
    COUNT(DISTINCT CASE WHEN u.city NOT IN ('Москва', 'Санкт-Петербург')
          THEN o.order_id END)  AS orders_control
  FROM orders o
  JOIN order_items oi ON o.order_id = oi.order_id
  JOIN products p     ON oi.product_id = p.product_id
  JOIN users u        ON o.user_id = u.user_id
  WHERE o.order_date BETWEEN '2024-06-01' AND '2024-06-30'
  GROUP BY p.seller_id
)
SELECT
  CASE
    WHEN orders_treatment > 0 AND orders_control > 0
      THEN 'contaminated'   -- продавец в обоих группах
    WHEN orders_treatment > 0
      THEN 'treatment_only'
    ELSE 'control_only'
  END AS seller_type,
  COUNT(*) AS n_sellers,
  ROUND(100.0 * COUNT(*) / SUM(COUNT(*)) OVER (), 1) AS pct
FROM seller_exposure
GROUP BY 1
ORDER BY n_sellers DESC;

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

Как отвечать: структура мысли