MDE на маркетплейсе: почему дефолтная формула размера выборки врёт
Команда маркетплейса планирует A/B-тест нового checkout-флоу. Аналитик считает размер выборки: ожидаемый размер эффекта +2% к конверсии, базовая конверсия 12%, нужно 35 000 пользователей на группу. Запускают на 4 недели. Результат: +0.7%, p = 0.18. «Эффект не значим», откатывают.
Через полгода команда решает попробовать тот же checkout по-другому. Кто-то делает re-eval старого теста на расширенной выборке — оказывается, эффект был +1.8%, просто размер выборки был в три раза меньше нужного. Тест дал «незначим» не потому что эффекта не было, а потому что мощность теста была недостаточной для его обнаружения. Шесть месяцев работы команды потеряны на неправильный вывод.
Эта статья — про то, почему стандартные формулы размера выборки систематически недооценивают реальную потребность на маркетплейсе. Три механизма работают вместе: распределения метрик не нормальные, эффекты treatment неоднородны по сегментам, и двусторонний рынок нарушает базовые предположения A/B. Каждый из них режет реальную мощность теста, и команда которая считает выборку по «учебной формуле» строит тесты которые формально валидны, но систематически не находят настоящих эффектов.
Угроза 1: тяжёлый хвост убивает мощность
Стандартная формула размера выборки выглядит так: N = 16·σ²/Δ². Это формула для нормально распределённой метрики при 80% мощности и 5% уровне значимости. Аналитик берёт дисперсию из исторических данных, подставляет в формулу, получает N.
Проблема в неявном предположении про нормальность. На маркетплейсе ключевые метрики — revenue per user, GMV per session, order value — почти никогда не нормальные. Они имеют тяжёлый правый хвост: 80% пользователей дают маленькие или нулевые значения, 5% пользователей дают значения в десятки и сотни раз больше среднего. Это распределение log-normal или Pareto, не нормальное.
Численно: представьте revenue per user со средним 1500 рублей и стандартным отклонением 8000 рублей. По формуле для нормального распределения для обнаружения эффекта 3% нужно N = 16 × 8000² / (0.03 × 1500)² ≈ 51 000 пользователей. В реальности при log-normal распределении тот же эффект требует в 2-3 раза больше выборки — потому что выбросы доминируют в выборочной дисперсии, и t-test на таких данных имеет реальную мощность 30-50% от расчётной.
Эффект ещё сильнее когда метрика дискретная и редкая. Конверсия в покупку 2-3% — это не среднее по нормальному распределению, это редкое событие. Стандартная формула работает для биномиальной метрики, но если в продукте есть heavy users которые делают много покупок — фактическая дисперсия снова взлетает выше формульной.
Решение — три инструмента, каждый по обстоятельствам:
Winsorization — обрезка top 0.5-1% значений в выборке. Это убирает влияние whale users на дисперсию без значимого смещения оценки эффекта. Размер выборки падает в 1.5-2 раза. Применять когда heavy tail обусловлен небольшим количеством экстремальных значений.
Log-преобразование — анализ log(revenue + 1) вместо revenue. Это превращает log-normal распределение в близкое к нормальному, и стандартная формула снова работает. Применять для непрерывных метрик с длинным хвостом. Интерпретация результата — относительная (в процентах), а не абсолютная.
Ratio-метрики и delta-method — вместо revenue per user считать revenue per session или GMV per visit. Это часто снижает дисперсию в 3-5 раз. Минус — для расчёта sample size нужен delta-method, не стандартная формула.
В курсе A/B-статистики на этом сайте — модули 03 (распределения) и 05 (снижение дисперсии) разбирают эти техники детально.
Угроза 2: неоднородные эффекты по сегментам
Вторая проблема возникает когда эффект теста не одинаков для всех пользователей. На маркетплейсе это норма, а не исключение. Эффект checkout-улучшения отличается:
- На новых пользователях против повторных
- На мобильных против десктопа
- В категории электроники против одежды
- В Москве против регионов
- На low-ticket против high-ticket покупок
Когда тест показывает агрегированный эффект близкий к нулю — часто это не отсутствие эффекта, а маскировка. Новые пользователи показывают +5%, повторные −3%, общее скомпенсировалось до +0.5%. Команда видит «не значимо», откатывает фичу, которая на самом деле сильно работает для одного сегмента.
Численно: представьте тест на 60 000 пользователей, ожидаемый эффект +2%. Стандартная мощность 80%. Реально 40% пользователей — новые с эффектом +5%, 60% — повторные с эффектом 0%. Агрегированный эффект 2%, но дисперсия в группе выше из-за разницы по сегментам. Мощность падает до 50-60%. Чаще тест даёт «не значимо», команда не видит что для новых пользователей фича сильно работает.
Решение — pre-specified subgroup analysis с заранее определёнными сегментами. Не «давайте посмотрим срезы после теста» — это p-hacking и multiple testing problem. А до запуска теста зафиксировать: какие 3-5 сегментов важны для бизнеса, какой ожидаемый эффект в каждом, какой MDE по каждому. Sample size считается так чтобы обеспечить мощность в каждом сегменте отдельно, не в aggregate.
Это значит итоговая выборка больше — обычно в 1.5-3 раза. Но это честная цена за информативный результат. Альтернатива — формальная мощность 80% которая на практике ничего не находит.
Иногда правильный вывод теста — «фича работает только для сегмента X, для остальных эффекта нет, рассмотреть таргетированную раскатку». Это полезный результат, не провал. Агрегатно-ориентированный подход прячет такие выводы.
В модуле 04 курса A/B-статистики разобрана карта выбора статтеста для случая с pre-specified сегментами.
Угроза 3: двусторонний рынок ломает SUTVA
Третья проблема — структурная. A/B-тест предполагает что treatment одного пользователя не влияет на outcome других. Это допущение называется SUTVA, и оно — фундамент причинного вывода в A/B.
На маркетплейсе SUTVA нарушается системно. Несколько типов нарушений:
Двусторонний рынок. Покупатели и продавцы взаимодействуют через общую платформу. Если тестируется изменение для покупателей (новое ранжирование, новый промо), это меняет поведение продавцов: они видят разные паттерны спроса, по-разному обновляют товары, цены, ассортимент. Тестовая группа покупателей формирует контекст, в котором действуют продавцы — а они в свою очередь влияют на контрольную группу покупателей.
Общий инвентарь. Товаров ограниченное количество. Если тестовая группа активнее их покупает — контрольной группе доступно меньше. Это особенно заметно в категориях с лимитированным предложением (флэш-продажи, аукционы, бронирования).
Социальные эффекты. Покупатели общаются через отзывы, рейтинги, реферралы. Treatment одного пользователя влияет на сигналы, которые видят другие пользователи в контрольной группе.
Численно: представьте тест нового алгоритма рекомендаций. Тестовая группа лучше находит товары, активнее покупает. В одной категории остаются только не-рекомендованные товары — контрольная группа покупает меньше. Агрегированный эффект измеренный как +3% revenue в тестовой и −1.5% в контрольной — общая разница 4.5%, но истинный эффект алгоритма (если бы его раскатили на всех) ниже — потому что в полной раскатке инвентарь снова станет общим, и покупательская активность нормализуется.
Это не теоретическая проблема. В литературе по marketplace experimentation (eBay, Airbnb, Uber) этот эффект документирован: классический user-level A/B даёт смещённую оценку на 20-50% для marketplace-метрик.
Решение — альтернативные дизайны:
Geo-эксперименты. Рандомизация на уровне города/региона, не пользователя. Внутри города весь инвентарь и аудитория получают treatment целиком, так что SUTVA выполняется. Минус — мощность ниже, потому что N геоединиц мало (20-50 городов).
Switchback designs. Время разделено на интервалы (по часу, по дню), и каждый интервал случайно назначается в treatment или control. Это работает для тестов где интервалы достаточно изолированы (ride-hailing, food delivery).
Кластеризация по времени. Тест на одной аудитории, но в разные периоды: неделя А — treatment, неделя B — control, далее чередование. Минус — смешивание с дневной/недельной сезонностью.
Все три подхода требуют отдельной формулы sample size и заметно бόльшего объёма данных. Это та цена которую маркетплейс платит за корректную причинную оценку.
В курсе A/B-статистики модуль 06 (кластерные эксперименты) разбирает design effect и формулы sample size для cluster-randomized тестов.
Что общего у этих трёх
Три угрозы выглядят разными — тяжёлые хвосты, неоднородность эффектов, нарушение SUTVA. Но у них один тип проблемы: стандартные формулы размера выборки были разработаны для гомогенных веб-сервисов с нормальными метриками и независимыми пользователями. Это допущения которые не выполняются на маркетплейсе.
Каждый аналитик который считает sample size по дефолтной формуле для маркетплейс-метрики систематически недооценивает реальную потребность в выборке. Не на 10-20%, а в 2-5 раз. Тесты которые запускаются с такой выборкой имеют реальную мощность 30-50% от заявленной — что значит половина настоящих эффектов будет помечена как «не значимо», и команда сделает неправильные выводы.
Это перекликается с темами предыдущих статей в этом разделе. В AI-evals общая accuracy скрывала гетерогенность. В retention vs revenue агрегированный прирост revenue скрывал отложенную потерю retention. Здесь aggregate эффект на гетерогенной маркетплейс-аудитории скрывает важные сегментные различия и размывается нарушением SUTVA. Один паттерн в трёх вариациях: средние числа на гетерогенных рынках обманывают, и стандартные инструменты A/B созданы для гомогенных сред.
Главное правило MDE на маркетплейсе: никогда не доверять дефолтной формуле sample size. Реальная мощность теста зависит от формы распределения метрики, гетерогенности эффектов, и нарушения SUTVA — каждый из этих факторов требует отдельной коррекции расчёта.
Чеклист для команды
Семь правил которые закрывают большую часть проблем расчёта sample size на маркетплейсе:
- Не использовать дефолтную формулу N = 16·σ²/Δ² для метрик с тяжёлым хвостом (revenue, GMV, order value). До расчёта посмотреть распределение метрики и применить winsorization, log-преобразование или ratio-форму.
- Снижение дисперсии (CUPED, стратификация) включать в планирование, не как «опцию». Реальная экономия выборки 30-50% для типичных маркетплейс-метрик.
- Pre-specified сегменты до запуска теста. Зафиксировать 3-5 ключевых сегментов (новые/повторные, мобильные/десктоп, категории), посчитать sample size с гарантией мощности в каждом сегменте отдельно.
- Для marketplace-чувствительных тестов (ранжирование, рекомендации, ценообразование, инвентарь) — рассмотреть geo или switchback designs. User-level A/B даст смещённую оценку.
- Расчёт sample size с учётом design effect для cluster-randomized тестов. Эффективный N равен числу кластеров (городов, дней), не числу пользователей.
- Не интерпретировать «не значимо» как «эффекта нет». В 40-60% случаев на маркетплейсе настоящая причина — недостаточная мощность теста. Post-mortem обязателен на каждый «не значимо» результат — re-eval на большей выборке через 3-6 месяцев часто показывает истинный эффект.
- Стандарт планирования: design document с (а) формой распределения метрики и техниками снижения дисперсии, (б) pre-specified сегментами и MDE по каждому, (в) выбором между user-level и cluster-randomized дизайном с обоснованием. Если хоть один из трёх пунктов отсутствует — тест выполняется по дефолтным допущениям, и его выводы под вопросом.
Это базовая гигиена, не академическая точность. Команда которая строит sample size осознанно — обнаруживает в год вдвое больше реальных эффектов. Команда которая использует дефолтную формулу — теряет половину работающих фич на «не значимо» от недостаточной мощности.