A/B-тест без самообмана: ошибки, которые превращают шум в «победу»

Почему A/B-тест вообще может обмануть

Статистический тест отвечает на узкий вопрос: насколько необычной была бы наблюдаемая разница, если бы на самом деле её не было. Уровень значимости — это заранее принятая доля ложных тревог. При пороге 0,05 по определению примерно каждый двадцатый тест без реального эффекта всё равно покажет «значимость».

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

Короткий словарь терминов

Половина споров о результатах A/B-тестов возникает из-за того, что участники по-разному понимают одни и те же слова. Прежде чем разбирать ошибки, договоримся о терминах — они понадобятся во всех следующих разделах.

• Нулевая гипотеза — предположение, что изменение ни на что не влияет. Тест проверяет, достаточно ли данных, чтобы от него отказаться.
• p-value — вероятность увидеть такую же или более сильную разницу при условии, что нулевая гипотеза верна. Это не вероятность того, что вариант B лучше.
• Уровень значимости (α) — порог для p-value, выбранный до запуска; заранее принятая доля ложных тревог.
• Мощность — вероятность обнаружить эффект заданного размера, если он действительно есть.
• MDE, минимальный детектируемый эффект, — самое маленькое изменение метрики, которое тест должен уверенно замечать и которое имеет смысл для бизнеса.
• Доверительный интервал — диапазон значений эффекта, совместимых с данными; его ширина показывает точность оценки.
• Единица рандомизации — то, что случайно распределяется по группам: пользователь, сессия, заказ, магазин, город.
• SRM — расхождение фактического соотношения групп с запланированным, признак технической поломки.
• CUPED — способ уменьшить разброс метрики, используя данные того же пользователя до начала теста.

План теста: что решить до запуска

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

1. 01Гипотеза: что меняем, у кого, на какую метрику это должно повлиять и почему мы так думаем.
2. 02Главная метрика и точная формула её расчёта: числитель, знаменатель, окно наблюдения.
3. 03Защитные метрики, ухудшение которых остановит раскатку даже при росте главной.
4. 04Единица рандомизации и единица анализа.
5. 05Минимальный эффект, уровень значимости, мощность и рассчитанный по ним объём выборки.
6. 06Длительность целыми неделями и правило остановки: фиксированный срок или последовательный метод.
7. 07Правила очистки данных: кого исключаем (сотрудников, ботов, тестовые аккаунты) и как обращаемся с выбросами.
8. 08Критерий решения: что сделаем при росте, падении и нейтральном результате.

Иллюстративный пример плана

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

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

Ошибка 1. Подглядывание и ранняя остановка

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

Решения два. Первое — заранее рассчитать размер выборки и длительность и принять решение только в конце. Второе — использовать последовательные методы, которые изначально рассчитаны на многократный просмотр: групповые последовательные планы с поправленными границами или «всегда корректные» p-value. Смешивать подходы нельзя: классический тест с ежедневной остановкой по p — это уже не классический тест.

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

Почему частый просмотр так сильно искажает вывод

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

Ошибка 2. Маленькая выборка и низкая мощность

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

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

Ошибка 3. Много метрик и много срезов

Если проверить двадцать метрик по отдельности, одна из них вполне может оказаться «значимой» случайно. То же самое с сегментами: новые и старые пользователи, платформы, города, каналы. Чем больше разрезов, тем выше шанс найти «вариант B работает для владельцев Android в выходные» — и тем меньше этот вывод стоит.

• Одна главная метрика фиксируется до запуска; решение принимается по ней.
• Вторичные метрики описывают картину, но не объявляют победителя.
• Защитные метрики (скорость загрузки, отказы, жалобы, отмены) проверяют, что улучшение не куплено ухудшением в другом месте.
• При нескольких равноправных гипотезах применяют поправки на множественные сравнения: Бонферрони, Холма или Бенджамини — Хохберга.
• Находка в сегменте — это гипотеза для следующего теста, а не результат текущего.

Что делать, если бизнесу действительно важны две метрики, например конверсия и средний чек? Есть два честных пути. Первый — объединить их в одну заранее определённую метрику, скажем выручку на пользователя, и принимать решение по ней. Второй — объявить обе главными и применить поправку на множественность, понимая, что для этого понадобится больше данных. Нечестный путь — дождаться результатов и выбрать ту, что выглядит лучше.

Ошибка 4. Неверная единица рандомизации

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

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

Проверка соотношения групп

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

Пример: тест, где группы мешают друг другу

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

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

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

• Метрика — доля (конверсия, удержание, клик): подходит z-тест для разности долей или критерий хи-квадрат, потому что поведение бинарное и распределение хорошо изучено.
• Метрика — среднее с тяжёлым хвостом (выручка на пользователя, время в продукте): t-тест работает на больших выборках, но чувствителен к выбросам; правило их обработки, например обрезку по верхнему перцентилю, фиксируют заранее, а для проверки устойчивости используют бутстреп.
• Метрика — отношение (средний чек, клики на сессию) при рандомизации по пользователям: дисперсию считают дельта-методом или бутстрепом по пользователям, потому что заказы одного человека зависимы.
• Нужна возможность остановиться досрочно: последовательный метод с заранее заданными границами, потому что классический тест не рассчитан на многократный просмотр.
• Вариантов больше двух: поправка на множественные сравнения или предварительный общий тест, потому что каждое попарное сравнение — отдельная попытка.
• Эффект ожидается маленьким, а у пользователей есть история до теста: CUPED, потому что учёт исходного поведения снижает шум без изменения смысла метрики.

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

Как не принять совпадение за причину

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

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

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

Парадокс Симпсона и сдвиг состава

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

Пример: как читать отчёт, который «почти выиграл»

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

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

Чек-лист: перед запуском и перед выводом

1. 01Гипотеза записана: что меняем, на какую метрику должно повлиять и почему.
2. 02Выбрана одна главная метрика и список защитных.
3. 03Посчитаны минимальный эффект, мощность, объём выборки и длительность целыми неделями.
4. 04Единица рандомизации совпадает с единицей анализа; для метрик-отношений выбран корректный метод дисперсии.
5. 05Пайплайн проверен A/A-тестом или хотя бы сверкой событий в обоих вариантах.
6. 06Тест не останавливается раньше плана — либо заранее выбран последовательный метод.
7. 07Соотношение групп проверено на расхождение с планом.
8. 08В выводе указан доверительный интервал, а не только p-value.
9. 09Сегментные находки оформлены как гипотезы для следующих тестов.
10. 10Результат записан в журнал экспериментов, включая нейтральный и отрицательный.

Как поймать каждую ошибку по симптомам

• Эффект был большим в первые дни и постепенно уменьшается — вероятны подглядывание на ранних данных или эффект новизны; проверьте график накопленного эффекта и не принимайте решение до планового срока.
• «Победа» на маленьком тесте не повторяется после раскатки — низкая мощность и завышенная оценка; пересчитайте мощность и запустите повторный тест.
• Значимой оказалась одна метрика из многих или один сегмент — множественные сравнения; проверьте, была ли она главной в плане, и примените поправку.
• Доверительный интервал подозрительно узкий для такого трафика — неверная единица анализа; сравните единицу рандомизации и единицу расчёта.
• Группы разного размера при плане 50 на 50 — SRM; проверьте распределение, фильтрацию ботов и логирование событий.
• Результат «слишком хорош» — ищите ошибку в данных и трекинге раньше, чем объяснение в продукте.

Итог

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