MDE и размер выборки: как понять, хватит ли данных для A/B-теста

Коротко

MDE, или minimum detectable effect, — минимальный эффект, который тест спроектирован заметить при заданных базовой метрике, мощности и уровне значимости. Чем меньше MDE, тем больше нужна выборка. Это не прогноз фактического uplift и не обещание, что вариант даст именно такой рост.

• Сначала оцени базовую конверсию и полезный для бизнеса эффект.
• Зафиксируй alpha и power до запуска, а не после просмотра данных.
• Проверь, сколько пользователей реально будет экспонировано в каждой группе.
• Учитывай сезонный цикл и задержку целевого события при расчёте длительности.

MDE начинается с решения, а не с калькулятора

Если checkout приносит 100 заказов в день, рост на 0,1 п.п. может быть статистически обнаружим только на очень большой аудитории и не окупить стоимость изменений. Если ошибка в оплате стоит бизнесу тысячи заказов, даже небольшой эффект может быть важен. Поэтому MDE лучше связывать с решением: какой результат меняет план действий.

От чего зависит размер выборки

На размер выборки влияют базовый уровень метрики, MDE, alpha, power и тип метрики. Для конверсии важна исходная доля: обнаружить рост с 10% до 11% и с 1% до 2% — не одна и та же статистическая задача, даже если абсолютная разница равна одному процентному пункту.

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

Как перевести выборку в длительность

Если нужно 12 тысяч пользователей на группу, а в эксперимент ежедневно попадает 1 000 новых пользователей, минимальная длительность — около 24 дней при распределении 50/50. Но это только оценка потока. Добавь время на завершение целевого действия, полный недельный цикл и возможные провалы трафика.

Не сокращай тест до нескольких часов, если покупка или возврат происходят в течение нескольких дней. Иначе в ранний результат попадут пользователи с быстрым поведением, а поздние конверсии останутся за пределами окна.

• Нужная выборка на группу ÷ ежедневный приток в эксперимент ÷ доля трафика на тест.
• Добавь хотя бы один полный недельный цикл, если поведение меняется по дням недели.
• Для отложенных событий задай окно конверсии и дождись его закрытия для последней когорты.
• Не увеличивай долю трафика только потому, что первые дни выглядят нейтрально.

Что делать, если трафика не хватает

Маленькая аудитория не делает эксперимент невозможным, но ограничивает вывод. Можно тестировать более крупные изменения, выбрать более частую прокси-метрику с guardrail, продлить сбор данных или использовать качественное исследование для ранней проверки идеи. Нельзя честно решить проблему, просто назвав широкий интервал “почти значимым”.

Если фактический поток сильно меньше плана, зафиксируй это как ограничение. Тест мог не показать эффекта потому, что его не было, а мог не иметь мощности заметить реальный небольшой эффект.

Alpha и power: две разные ошибки

При планировании эксперимента мы управляем как минимум двумя рисками. Alpha — вероятность объявить эффект, которого нет, если нулевая гипотеза верна. Power — вероятность заметить эффект выбранного размера, если он действительно существует. В рабочих планах часто используют alpha 0,05 и power 0,8, но эти числа не заменяют обсуждение стоимости ошибки.

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

Базовая метрика должна быть честной

Расчёт выборки чувствителен к baseline. Если взять среднее за весь год, а тест запускается только на мобильном трафике в выходные, план будет неточным. Проверь несколько последних стабильных периодов, сезонность, сегмент эксперимента и изменения в трекинге. Базовая конверсия — это не удобная цифра из первого отчёта, а предположение, которое должно соответствовать будущему тесту.

Для редких событий можно рассмотреть более частую прокси-метрику, но только с понятной связью с конечным результатом и guardrail. Нельзя увеличивать power, подменяя покупку кликом, если клик не говорит о качестве клиента. Прокси помогает быстрее учиться, но не должна маскировать отсутствие бизнес-эффекта.

• Сегмент baseline совпадает с аудиторией эксперимента.
• Период baseline включает полный недельный или сезонный цикл.
• Знаменатель не менялся из-за релиза или изменения фильтра.
• Окно конверсии совпадает с будущим окном чтения.

Пример перевода MDE в план

Представим checkout с базовой конверсией 6%. Команда считает, что изменение стоит внедрять только при росте хотя бы на 0,5 процентного пункта: с 6,0% до 6,5%. При трафике 2 000 пользователей в день и распределении 50/50 в тест попадает около 1 000 пользователей ежедневно, то есть за две недели — примерно 7 000 на группу до учёта задержки и неполных наблюдений.

Такой расчёт ещё не является готовым размером выборки: нужны alpha, power, тип теста и калькулятор. Но он сразу показывает, реалистичен ли план. Если точный расчёт потребует 30 000 пользователей на группу, остановка через три дня не даст ответа. Команда может выбрать более крупное изменение, увеличить трафик, продлить тест или отказаться от вопроса.

Что делать после запуска

План — это не повод игнорировать данные до финальной даты. До завершения можно проверять техническое состояние, SRM, полноту событий и критические guardrails. Нельзя использовать промежуточный p-value как разрешение остановить обычный тест, если такое правило не было заложено заранее. Диагностика качества и чтение победителя — разные действия.

После достижения выборки дождись окна конверсии для последней когорты. Зафиксируй фактический размер групп, период, MDE, primary, guardrails и ограничения. Если поток оказался ниже ожидания, не переписывай план задним числом. Признай, что тест мог быть недостаточно мощным, и реши, есть ли смысл продолжать.

Калькулятор не знает бизнес-контекст

Калькулятор размера выборки считает задачу по введённым параметрам, но не проверяет, правильно ли ты выбрал baseline, MDE и единицу анализа. Если в поле конверсия указать число сессий, а в реальности рандомизация идёт по пользователю, итоговый план будет выглядеть точным, но не соответствовать дизайну.

Перед расчётом ответь: кто рандомизируется, какое событие является успехом, сколько раз пользователь может попасть в знаменатель и когда окно конверсии закрывается. Для ratio-метрик, выручки и длительности сессии нужны отдельные предположения о распределении и дисперсии. Не подставляй бинарную формулу автоматически.

• Единица рандомизации совпадает с единицей анализа или зависимость учтена.
• Один пользователь не создаёт несколько независимых наблюдений.
• Baseline взят на сопоставимой аудитории и периоде.
• MDE соответствует решению, а не желанию получить удобную выборку.
• Задержка события включена в план длительности.

Длительность защищает от ложной уверенности

Даже если выборка набрана быстро, тест может быть слишком коротким. В первые дни пользователи реагируют на новизну, команды меняют коммуникацию, а часть событий ещё не успевает созреть. Минимальный срок должен включать полный недельный цикл, а для продуктов с редкой покупкой — окно, за которое завершается целевое действие.

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

Не меняй MDE, долю трафика и метрику по ходу

Когда первые дни выглядят нейтрально, возникает соблазн снизить MDE, добавить трафик или заменить primary на более чувствительный показатель. Каждое такое изменение меняет вопрос эксперимента. Иногда адаптация оправдана, но она должна быть частью заранее описанного дизайна, а не реакцией на неудобное число.

Если нужно изменить план, зафиксируй дату, причину и новый вопрос. Например, команда может остановить тест как недостаточно мощный и запустить новый с крупным MDE. Это лучше, чем продолжать один и тот же тест с несколькими версиями расчёта, пока результат не станет удобным.

Как оформить план перед запуском

Один экран или короткий документ должен позволять проверить план до разработки. Укажи гипотезу, сегмент, способ рандомизации, baseline, primary, guardrails, alpha, power, MDE, плановую выборку на группу, долю трафика, минимальный срок и окно конверсии. Если параметр неизвестен, пометь его как риск, а не оставляй пустым.

После запуска добавь фактические значения рядом с плановыми. Так будет видно, где разошлись ожидания и реальность: трафик ниже, baseline изменился, событие задержалось или группа потеряла exposure. Это полезнее, чем хранить только финальный скриншот с p-value.

Мини-кейс: план не совпал с реальным трафиком

Команда рассчитала 20 000 пользователей на группу, исходя из 3 000 новых пользователей в день. После запуска в эксперимент попало только 1 200: часть аудитории исключила рекламная кампания, а доля трафика на test оказалась ниже. Через две недели выборка ещё не достигла плана, но команда уже хочет закрыть тест как нейтральный.

Сначала нужно разделить две вещи. Фактический результат может быть действительно нейтральным, а может быть слишком неопределённым из-за недобора. Посмотри доверительный интервал и сравни его с MDE. Если диапазон всё ещё включает полезный эффект, у теста нет основания доказывать отсутствие результата. Дальше решают стоимость продолжения, сезонность и актуальность гипотезы.

В post-read запиши план и факт рядом: ожидаемый поток, фактический поток, выборка на группу, дни теста, долю трафика и закрытое окно конверсии. Это помогает понять, был ли недобор случайным отклонением или системным ограничением продукта.

Если тест закрывается раньше плана, назови это ограничением мощности, а не результатом “эффекта нет”.

Проверь чувствительность плана

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

Такой расчёт заранее показывает, когда тест перестанет отвечать на исходный вопрос.

Для важных экспериментов сохрани эти сценарии рядом с калькулятором, чтобы команда видела не только одну красивую цифру.

План становится проверяемым документом, а не устной договорённостью.

Согласуй цену ожидания

Размер выборки — это ещё и план стоимости. Долгий тест может задержать rollout, удерживать две версии интерфейса и занимать время команды. Короткий тест оставляет неопределённость. Перед запуском обсуди не только “сколько пользователей нужно”, но и сколько стоит каждый дополнительный день, какая ошибка дороже и в какой момент продолжение перестаёт менять решение.

Так разговор о MDE становится практическим. Для обратимого UX-изменения можно принять более широкий диапазон и staged rollout. Для цены, кредита или массовой коммуникации разумно требовать более строгой уверенности. Аналитик не выбирает риск один: он переводит статистические параметры в понятный контракт с владельцем продукта.

Если эти ограничения не записать до запуска, команда начнёт обсуждать их только после появления неудобного результата.

В таком документе видно, что именно нужно пересчитать при изменении трафика, а какие правила остаются неизменными.

Это и есть честный план эксперимента.

Он помогает не путать недобор данных с отсутствием эффекта.