Всем привет! Я Андрей Романов, тимлид команды аналитики Sales Tech в Авито, а также преподаватель и ментор по А/B-тестированию. 

В последние годы я регулярно работаю с A/B-тестами на малых выборках: когда в группе не тысячи пользователей, а 10–40 менеджеров, регионов или других экспериментальных единиц. На этом опыте я собрал практический гайд: что можно сделать до запуска, во время дизайна и после эксперимента, чтобы выжать максимум из ограниченных данных.

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

В материале дам 26 шагов, которые помогут выжать максимум чувствительности и валидности из ограниченной выборки. Хотя фокус — на A/B-тестах с малыми выборками, 90% подходов применимы и к стандартным экспериментам.

В этой статье:

• Контекст

• Перед дизайном эксперимента

• Дизайн метрик

• Дизайн эксперимента — чувствительность

• Дизайн эксперимента — валидность

• После запуска

• Итоги и дополнительные материалы

Контекст

A/B-тесты на малых выборках — повсюду. Они встречаются: во внутренних и B2B-продуктах, офлайн-экспериментах, кластерных тестах, где единицей рандомизации и анализа является регион или категория товаров на маркетплейсе, а также в узких сегментах. У таких тестов есть две основные проблемы: чувствительность — их сложно прокрасить, и валидность — в них легко допустить ошибки.

Некоторые тезисы в статье я буду иллюстрировать примерами из моего эксперимента. Я работаю в B2B-направлении Авито, где персональные менеджеры помогают крупным продавцам эффективнее использовать площадку: консультируют по продуктам, бюджету и продвижению.

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

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

Перед дизайном эксперимента

1. Изучите контекст — максимально хорошо поймите, что именно тестируете. Запросите демо, прочитайте документацию, поговорите с владельцем продукта и, если возможно, сами пройдите основной пользовательский сценарий.

В A/B-тестах на малых выборках это особенно важно. Здесь мы часто тестируем не кнопку в интерфейсе на миллионах пользователей, а изменение процесса, внутренний инструмент, B2B-механику или работу небольшого числа менеджеров, клиентов, регионов или категорий. Без контекста легко выбрать не ту метрику, не заметить сетевые эффекты, неправильно определить единицу рандомизации или включить в эксперимент участников, которые в принципе не могут отреагировать на изменение. 

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

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

3. Заранее решите, кого нужно исключить из выборки. Это можно сделать до того, как начнёте смотреть на данные. Иногда есть участники, которые в принципе не могут отреагировать на изменение, или слишком уникальные объекты, которые не похожи на остальных. Такие случаи лучше определить заранее, чтобы потом не подгонять выборку под желаемый результат.

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

4. Если проводите A/B на людях, помните о Хоторнском эффекте и внешних воздействиях. Метрика может измениться не из-за самой фичи, а из-за того, что участники знают об эксперименте, получают больше внимания, контроля или дополнительной мотивации.

✏️ В моём эксперименте руководители могли сильнее пушить сотрудников из тестовой группы, чтобы выполнить OKR или KPI. Люди начинают перформить лучше, но не потому, что инструмент помогает, а из-за дополнительного управленческого давления.

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

? Пара слов о том, что такое чувствительность. Когда я спрашиваю у аналитиков, что это такое, частый ответ: «Чувствительность — это MDE». Но это не совсем так.

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

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

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

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

Вот несколько способов:

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

? Укрупнить воздействие. В классической логике A/B-тестов нас часто учат тестировать маленькие изменения по одному: одну фичу, текст или настройку. Но на малых выборках это может не сработать: мощности просто не хватит. Поэтому иногда разумнее накопить несколько связанных изменений в один батч и тестировать пакет целиком.

? Усилить внедрение. Например, не просто выкатить инструмент и ждать, что менеджеры сами начнут им пользоваться, а добавить обучение, напоминания, контроль adoption rate и понятный сценарий применения. В таком случае мы тестируем не только наличие инструмента, но и более полноценное изменение процесса. Это может дать более явный и измеримый эффект.

У этих подходов есть общая цена: мы хуже отвечаем на вопрос о чистом эффекте отдельной маленькой фичи. 

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

6. Задумайтесь о проведении пилота на одной-двух единицах наблюдений. В A/B-тестах на малых выборках мы часто проверяем что-то нестандартное, поэтому высок риск ошибиться не в статистике, а в реализации: инструмент неудобен, участники не понимают сценария, данные логируются не так, как ожидалось, или метрика плохо отражает использование.

Пилот можно провести на участниках, которых вы заранее не планируете включать в основной A/B. Но такой пилот не должен оценивать эффект. Его задача — проверить механику, собрать обратную связь, исправить ошибки и усилить воздействие до запуска основного эксперимента.

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

Дизайн метрик

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

В A/B-тестах на малых выборках есть редкая возможность посмотреть на каждую единицу наблюдения отдельно. Постройте графики по дням для каждого менеджера, клиента, региона или категории и проверьте, нет ли объектов, которые живут в совершенно другом режиме. На большой выборке такие случаи часто растворяются в среднем, а здесь один странный объект может раздуть дисперсию, сломать балансировку или заметно изменить оценку эффекта.

8. Когда убедились, что метрики-кандидаты выглядят разумно и адекватно, рассчитайте коэффициент вариации. Удобно начать именно с коэффициента вариации: он показывает, насколько велик разброс метрики относительно её среднего — это именно то, что содержится в формуле от MDE.

Далее постройте распределения по каждой метрике-кандидату. Важно выбрать не просто «красивую» метрику, а ту, которая одновременно связана с механизмом воздействия и имеет приемлемый уровень шума. Если распределение сильно скошено, имеет длинный хвост и большой коэффициент вариации, MDE может оказаться настолько большим, что эксперимент почти ничего не сможет показать.

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

А вот количество звонков менеджера за неделю естественным образом ограничено сверху и снизу. 

Сверху — рабочим временем: невозможно совершить тысячи важных звонков длительностью от минуты. 

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

9. Заранее решите, как работать с выбросами. В малых выборках один экстремальный объект может сильно раздуть дисперсию и сделать прокрас недостижимым. Но просто удалить выбросы — тоже не бесплатное решение: если эффект отличается на обычных и экстремальных объектах, оценка может сместиться.

Здесь возникает классический trade-off между разбросом и смещением. Удаляя экстремальные значения, можно сузить доверительный интервал, но при этом исказить оценку эффекта. Поэтому важно смотреть не только на то, насколько сократился ДИ, но и на то, какую долю суммарной метрики мы выбросили из анализа.

Выбросы нельзя удалять механически. Сначала нужно понять их природу: это баг, ошибка в данных, разовое аномальное событие или честный оверперформер — например, крупный клиент или сильный менеджер. В первых случаях исключение может быть оправдано. Во втором — вы уже не чистите данные, а меняете метрику: оцениваете эффект не на всей исходной выборке, а на выборке без экстремальных объектов.

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

✏️ Например, у меня в одном из тестов был менеджер-оверперформер. Это один уникальный объект, удалив которого я получил снижение MDE практически на 14%, но потерял всего 4% от суммарной доли метрики.

10. Оптимизируйте дизайн самой метрики. Например, сумма звонков за неделю — не лучшая метрика. В процессе A/B-теста какой-то менеджер может заболеть или уйти в отпуск, и тогда у одного сотрудника будет метрика как сумма за три дня, а у другого — за пять. Это лишний шум. 

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

Далее можно перейти и к ratio: количество звонков, делённое на количество рабочих дней. И ещё немного повысить чувствительность.

11. Исследуйте методы сокращения дисперсии. В каждом случае они влияют по-разному. На моём опыте CUPED даёт 80–90% результата. Но это не аксиома: я видел случаи A/B-тестов на малых выборках, когда парная стратификация и парный тест давали ещё +20% к снижению MDE, который давал CUPED. А также встречал ситуации, когда постстратификация давала такой же эффект. 

?Если используете стратификацию, можно попробовать применять CUPED отдельно внутри каждой страты. Обычно это снижает дисперсию. Но только если внутри страт достаточно наблюдений: на слишком маленьких стратах оценка коэффициента может стать шумной и ухудшить результат.

12. Используйте прокси-метрики, но заранее задайте правило принятия решения. В случае малых выборок бизнесовая метрика часто находится слишком далеко от точки воздействия: она важна для решения, но слишком шумная, чтобы по ней одной надёжно увидеть эффект. Поэтому полезно смотреть на прокси-метрики — более ранние показатели, которые ближе к механизму воздействия.

Но прокси-метрик не должно быть слишком много. Если вы принимаете решение по нескольким метрикам одновременно, нужно заранее определить правило принятия решения и контролировать множественную проверку. Одна-две, максимум три, заранее выбранные метрики — обычно разумный предел. Если метрики сильно скоррелированы, цена множественной проверки ниже, но не исчезает полностью.

✏️ В нашем случае метриками были:

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

• количество звонков от 60 секунд;

• количество сделанных офферов;

• количество принятых офферов.

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

Дизайн эксперимента — чувствительность

13. Используйте две группы со сплитом 50 на 50. В малых выборках не стоит без необходимости дробить эксперимент на много групп. Если вместо классического A/B сделать A/B/C или A/B/C/D, наблюдения размазываются по нескольким вариантам, в каждой группе становится меньше объектов, стандартная ошибка растёт, а MDE увеличивается.

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

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

14. Присмотритесь к односторонней гипотезе и повысьте альфу. Иногда говорят, что односторонняя гипотеза — это неправильно. Это не так. Есть свои плюсы и минусы как у высокой, так и у низкой альфы, и то же самое с односторонней и двусторонней гипотезами. 

A/B на малых выборках — один из аргументов к тому, чтобы переходить от двусторонней гипотезы к односторонней и повышать вашу альфу. Ведь так мы снижаем MDE и повышаем чувствительность. 

Посмотрим на зависимость минимального детектируемого эффекта от уровня значимости при мощности 80%:

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

✏️ Мы оптимизируем время работы менеджера. И нужно было бы придумать что-то невероятное, чтобы показать, что это на самом деле тестируемое решение должно приводить к снижению продуктивности. 

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

15. Увеличьте длительность эксперимента, но не ждите, что MDE будет снижаться автоматически. Здесь важно различать два сетапа: тесты, где со временем приходят новые независимые участники, и тесты, где состав участников фиксирован, а мы просто дольше наблюдаем за теми же объектами.

В большинстве продуктовых A/B-тестов выборка набирается постепенно: каждый день в эксперимент приходят новые пользователи, и с ростом числа наблюдений стандартная ошибка обычно снижается. Но в A/B на малых выборках часто бывает иначе: список участников фиксирован заранее. Например, у нас есть конкретный набор менеджеров или крупных B2B-клиентов, и новые наблюдения появляются не за счёт новых пользователей, а за счёт более длинного периода наблюдения за теми же самыми объектами.

В таком дизайне увеличение длительности действительно может помочь, но MDE не обязательно будет снижаться монотонно. С какого-то момента дополнительное время может не уменьшать, а увеличивать шум. Например, часть менеджеров начнёт сильно оверперформить, кто-то уйдёт в отпуск или уволится, у кого-то изменится режим работы. В итоге дисперсия метрики вырастет, и MDE может стать хуже, хотя эксперимент стал длиннее.

С B2B-пользователями похожая история. Изначально клиенты могут быть относительно однородными, но через несколько месяцев кто-то уйдёт с площадки, а кто-то, наоборот, начнёт приносить миллионы. Формально выборка та же, но поведение уже другое. Поэтому длительность эксперимента нужно не просто увеличивать, а отдельно проверять на исторических данных: где дополнительное время помогает, а где начинает раздувать дисперсию.

16. Используйте одинаковое окно атрибуции. Если выборка набирается постепенно, важно считать метрику за одинаковый период после попадания пользователя в эксперимент. Не должно получиться так: тест идёт 30 дней, один пользователь попал на третий день, другой — на двадцатый, и для первого вы посчитали метрику за 27 дней, а для второго — за 10.

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

17. Рассмотрите нестандартные дизайны, например, switchback. Он полезен, когда экспериментальных единиц мало, но каждую можно наблюдать много раз во времени: менеджер-дни, регион-дни, склад-недели или категория-часы. Одна и та же единица в разные периоды попадает и в контроль, и в тест, поэтому мы частично убираем шум от постоянных различий между объектами.

Switchback — не синоним геотеста. Геотест отвечает на вопрос «где рандомизируем», а switchback — «как чередуем варианты во времени». Можно делать switchback без геотеста, а можно геотест без switchback.

✏️ Например, в случае с менеджерами можно тестировать алгоритм, который задаёт порядок обработки клиентов: одному и тому же менеджеру сегодня показывать алгоритм А, завтра — алгоритм Б.

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

18. Если свитчбэк не подходит, попробуйте двухэтапный дизайн. В классическом A/B на 28 дней мы сразу делим участников 50/50 на тест и контроль, ждём до конца эксперимента и считаем результат.

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

Таким образом мы получаем в 1.5 раза больше наблюдений. По формуле MDE, в полтора раза больше наблюдений приведёт к сокращению ширины доверительного интервала на 18%.

При этом понятно, что наблюдения за 14 дней более шумные, чем наблюдения за 28, но моя практика показывает, что всё-таки этот эффект намного меньше, чем прирост в 18% чувствительности, который мы получаем, когда увеличиваем выборку в полтора раза. 

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

19. Присмотритесь к идеям синтетического контроля внутри A/B-теста. Я имею в виду не замену A/B-теста синтетическим контролем, а использование похожей идеи внутри эксперимента: сравнивать тест не просто со средним контролем, а со взвешенной комбинацией контрольных единиц, которая в предпериоде максимально похожа на тестовую группу.

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

Но это уже продвинутый подход, который легко переобучить. Веса нужно подбирать только на предпериоде и фиксировать до анализа экспериментального периода. А сам дизайн обязательно валидировать на исторических A/A-тестах: смотреть реальную ошибку первого рода и ширину доверительного интервала.

Дизайн эксперимента — валидность

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

20. Помните об особенностях статистики при малых n. В A/B-тестах мы часто используем техники, которые хорошо работают благодаря асимптотике: тесты для относительных эффектов, линеаризацию ratio-метрик, дельта-метод и другие приближения. Их обоснование становится надёжнее на больших выборках. А при малых n такие методы могут давать некорректные доверительные интервалы и p-value — особенно если распределение скошено, есть выбросы или метрика устроена сложнее обычного среднего.

Отдельно следите за степенями свободы. Они появляются не только в t-распределении, но и в оценке дисперсии, стандартного отклонения и ковариации при вычислении CUPED. На больших выборках разница почти исчезает, а на малых может быть заметной.

Полезно помнить, что NumPy по умолчанию считает стандартное отклонение с ddof = 0, а pandas — с ddof = 1. При n = 10 стандартное отклонение с ddof = 1 примерно на 5,5% больше, чем с ddof = 0. Поэтому в малых выборках стоит явно проверять, какие дефолты использует ваш код.

При больших n разница между ddof = 0 и ddof = 1 почти исчезает. Но при n = 10 стандартное отклонение с ddof = 1 примерно на 5,5% больше, чем с ddof = 0

21. Оцените риск возникновения специфических сетевых эффектов. В A/B-тесте мы обычно хотим, чтобы результат одной экспериментальной единицы зависел от её собственной группы (тест/контроль), но не от того, в какую группу попали другие. В малых выборках это предположение часто нарушается.

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

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

22. Балансируйте группы. В случае A/B-тестов на малых выборках это обязательно. Стоит заранее обсудить со стейкхолдерами список параметров для балансировки. Важно подчеркнуть, что речь не только о метриках теста — то есть не только о том, к чему мы потом будем применять наш любимый t-тест.

✏️ Например, в кейсе с менеджерами мы дополнительно балансировали выборки по грейду менеджеров и их команде, хотя, разумеется, t-тест к этим признакам не применяли.

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

Второй способ — проще и надёжнее. Например, можно делать так: по каждой метрике и каждому признаку применить t-тест и KS-тест (для метрик), а для категориальных признаков — сhi² или точный тест Фишера. Затем для каждого сплита просто посчитать сумму p-value.

Нужен будет сплит, который даёт наибольшую сумму p-value: чем она больше, тем менее различимы группы между собой. Вот реальный пример влияния, которое оказывает балансировка:

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

Справа — случайный сплит без дополнительной балансировки. Мы просто зафиксировали random seed = 0 и получили перекосы между группами на уровне 10–20%. На выборке в 14 наблюдений на группу это нормальный, но неприятный сценарий: рандомизация формально корректна, но группы всё равно заметно отличаются на старте.

Кроме того, балансировка групп может снижать ошибку первого рода. В том же примере я случайно делил пользователей на тест и контроль — и получил наблюдаемую ошибку первого рода 23% при α = 0.2.

Затем я провёл балансировку по целевой метрике: генерировал множество сплитов и отбирал те, в которых сумма p-value по t-тесту и KS-тесту превышала 1.6. В этом случае ошибка первого рода снизилась до 22%. Улучшение — минимальное. Всё потому, что я использовал CUPED, который частично решает проблему несбалансированности по метрике. 

Потом я сбалансировал группы сразу по четырём метрикам: отбирал сплиты, где сумма p-value (по восьми тестам — t и KS) превышала 6.8. В результате ошибка первого рода снизилась до 15%. 

Это уже заметное улучшение: мы реже ошибаемся, чем ожидаем, и даже можем аккуратно корректировать α, повышая чувствительность.

Распределение p-value по целевой метрике в зависимости от способа балансировки. Данные из реального кейса

Узнать о балансировке всё самое важное вы можете из моего доклада: «Почему случайное разделение на тест и контроль ломает ваши АБ-тесты?»

23. Валидируйте весь ваш дизайн эксперимента на синтетических А/А и A/B-тестах. Я настоятельно рекомендую не ограничиваться одним историческим срезом и одной оценкой ошибки первого рода и MDE, а смотреть шире. Полезнее отвечать на вопрос: что было бы, если мы запустили A/B-тест 31 день назад, 32, 33 и так далее.

В обычных A/B-тестах ошибка первого рода и MDE часто ведут себя достаточно стабильно. Но на малых выборках оценки могут сильно меняться в зависимости от среза. 

Если взять данные за 40 дней назад или за 140, результаты могут заметно отличаться: где-то есть выбросы, где-то их нет; где-то наблюдений больше, где-то — меньше. Для каждого дня стоит запустить 10–100 тысяч A/A-тестов и посчитать MDE и реальную ошибку первого рода. За счёт того, что у вас маленькие выборки, симуляции будут проходить достаточно быстро. А ещё вы можете распараллелить расчёты по CPU-ядрам.

Так вы получите графики распределений фактиче

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

После запуска

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

Проблема не в том, что вы смотрите на данные. Дело в неучтённом правиле остановки: если регулярно смотреть на p-value и завершать тест при первом значимом результате, ошибка первого рода растёт.

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

P-value по дням сильно зависимы между собой: мы не проводим каждый день новый независимый тест, а постепенно уточняем оценку на той же выборке.

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

А вот дату финального анализа и правило принятия решения нужно зафиксировать заранее.

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

В A/B-тестах на малых выборках часто другой сетап. Состав экспериментальных единиц фиксирован заранее: есть конкретный набор менеджеров, клиентов, регионов или категорий. Мы не каждый день получаем много новых независимых пользователей, а просто дольше наблюдаем за теми же объектами. Поэтому стандартные последовательные методы требуют отдельной адаптации и валидации.

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

Есть существенная разница между выводами «эффект примерно 6 ± 5,9%» и «эффект примерно 6 ± 3%». Поэтому часто разумнее заранее зафиксировать окно эксперимента и дождаться полного объёма данных.

26. Дополните статистический результат постанализом. A/B-тесты на малых выборках часто позволяют посмотреть на каждую экспериментальную единицу отдельно: менеджера, клиента, регион или категорию. Это помогает понять, не держится ли результат на одном необычном объекте.

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

 ✏️ Я проводил интервью с менеджерами и спрашивал, помог ли инструмент в реальной работе и если да — за счёт чего. В пограничных случаях, когда значение p-value было рядом с уровнем α, это помогало не «докрасить» результат, а понять, согласуется ли статистическая картина с реальным пользовательским опытом.

Итоги и дополнительные материалы

В A/B-тестах на малых выборках почти каждое решение — это trade-off. 

• Можно сузить выборку до сегмента, где эффект должен быть сильнее → но тогда вывод относится только к этому сегменту. 

• Тестировать не одну маленькую фичу, а пакет изменений → но тогда сложнее разложить вклад по частям. 

• Взять более раннюю прокси-метрику → но её нужно честно связать с бизнесовым результатом. 

• Повысить альфу или использовать одностороннюю гипотезу → но тогда нужно явно принять цену ошибки первого рода. 

• Балансировать группы, использовать CUPED, switchback, двухэтапный дизайн или идеи синтетического контроля → но каждый такой шаг требует проверки на исторических A/A-симуляциях.

Хороший A/B-тест отвечает не только на вопрос «значимо или нет». Он показывает, насколько правдоподобен эффект, насколько устойчив дизайн, где результат чувствителен к одному объекту или одному срезу данных, какие риски остаются и какое решение можно принять с учётом этой неопределённости.

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

? По ссылке вы найдёте ноутбук со слайдами про все 26 шагов и несколько десятков избранных дополнительных материалов по самым сложным из них. 

А ещё подписывайтесь на телеграм-канал «Коммуналка аналитиков». В нём аналитики Авито делятся мыслями, рассказывают о приближающихся мероприятиях и общаются с подписчиками в комментариях. Например, недавно:

? Делились волшебными фразами, которые повышают доверие заказчиков
? Подсказывали, как (НЕ) попасть на работу мечты
? Обсуждали, как фокусироваться на задачах, когда всё вокруг отвлекает