10 ошибок в A/B-тестах
Почему ошибки в A/B-тестах — любимая тема собеседований
Правильно провести A/B-тест сложнее, чем кажется. Настроить сплит и посчитать p-value — это 10% работы. Остальные 90% — не допустить ошибок в дизайне, проведении и интерпретации. Именно поэтому на собеседованиях аналитиков так часто спрашивают: «Какие ошибки бывают в A/B-тестах?» или «Что может пойти не так с экспериментом?».
Ниже — 10 типичных ошибок. Для каждой: суть проблемы, почему она опасна, как исправить, и что стоит сказать на собеседовании.
1. Подглядывание в результаты (peeking)
Что это. Вы запускаете тест, и через два дня заглядываете в дашборд. Видите p = 0.03 — значимо! Останавливаете тест, докладываете об успехе. Проблема в том, что вы зафиксировали результат не в тот момент, который планировали.
Почему опасно. Статистический тест рассчитан на одну проверку при заранее определённом размере выборки. Если вы проверяете результат каждый день, вероятность ложного срабатывания растёт. При ежедневной проверке двухнедельного теста реальный alpha может вырасти с 5% до 20-30%. Вы будете раскатывать фичи, которые на самом деле ничего не дают.
Как исправить. Зафиксируйте размер выборки или длительность до запуска и не смотрите на значимость до достижения целевого объёма. Если нужно останавливать тест досрочно — используйте sequential testing (метод Вальда, always valid p-values, group sequential design). Эти методы корректируют порог значимости с учётом множественных промежуточных проверок.
На собеседовании. Покажите, что понимаете, почему многократная проверка раздувает alpha. Упомяните sequential testing как решение. Хороший пример: «Я бы зафиксировал sample size до старта и не принимал решение до набора нужного объёма. Если бизнес требует раннюю остановку — перешёл бы на sequential design».
2. Недостаточная мощность теста
Что это. Тест запускается с выборкой, которая слишком мала для обнаружения реального эффекта. По итогам результат незначим, и команда решает: «Фича не работает».
Почему опасно. Тест с мощностью 30% пропустит реальный эффект в 7 случаях из 10. Вы систематически отбрасываете рабочие идеи. Это ошибка второго рода (false negative), и она невидима — вы никогда не узнаете, сколько хороших фич убили.
Как исправить. Считайте размер выборки до запуска. Определите MDE (минимальный детектируемый эффект), задайте alpha = 0.05 и мощность >= 0.80. Если трафика не хватает — увеличивайте длительность, снижайте дисперсию через CUPED или стратификацию, или признайте, что эффект такого размера вы не можете надёжно измерить.
На собеседовании. Типичный вопрос: «Тест не показал значимый результат. Что это значит?» Правильный ответ — не «фича не работает», а «нужно проверить мощность». Если мощность была низкой, результат неинформативен. Незначимость не доказывает отсутствие эффекта.
3. Отсутствие заранее зафиксированной гипотезы
Что это. Тест запускается без чёткой гипотезы и основной метрики. После сбора данных аналитик перебирает метрики, сегменты и нарезки — и находит «значимый результат» в подгруппе «мужчины 25–34 из Казани на iOS».
Почему опасно. Это post-hoc mining — поиск паттернов после эксперимента. Чем больше нарезок вы попробуете, тем выше вероятность найти что-то «значимое» по чистой случайности. Это та же проблема множественных сравнений, только замаскированная под аналитику.
Как исправить. До запуска зафиксируйте: основную метрику (primary metric), гипотезу (направление и ожидаемый размер эффекта), критерии успеха. Запишите это в документ эксперимента. Анализ по подгруппам допустим, но его результаты — гипотезы для следующих тестов, а не основания для решений.
На собеседовании. Термин для запоминания — pre-registration. Объясните, что без фиксированной гипотезы нельзя контролировать ошибку первого рода. Если интервьюер описывает ситуацию, где «нашли эффект в подгруппе», спросите: была ли эта нарезка запланирована до теста?
4. Неправильная единица рандомизации
Что это. Рандомизация проводится на одном уровне, а метрика считается на другом. Классический пример: вы рандомизируете по сессиям, а считаете конверсию по пользователям. Один пользователь может попасть и в контроль, и в тест.
Почему опасно. Если пользователь видит оба варианта, вы размываете эффект (dilution). Если метрика агрегируется не на уровне рандомизации, стандартные ошибки занижены, и вы получаете ложную значимость. В обоих случаях результат невалиден.
Как исправить. Единица рандомизации и единица анализа должны совпадать. Обычно это пользователь (user-level randomization). Если рандомизируете по cookie — убедитесь, что один пользователь не имеет несколько cookie. Если по устройству — что у пользователя нет нескольких устройств (или что это допустимо для вашей метрики).
На собеседовании. Вопрос может звучать как: «Мы рандомизируем по сессиям. Какие проблемы?» Ответ: один пользователь видит оба варианта, эффект размывается. Если рандомизировали по пользователям, а считаем по событиям — нужно кластеризовать стандартные ошибки по пользователям.
5. Эффекты новизны и привыкания (novelty/primacy effect)
Что это. Novelty effect — пользователи активнее взаимодействуют с новым вариантом просто потому, что он новый. Primacy effect — обратная ситуация: пользователи привыкли к старому интерфейсу, и новый вариант показывает заниженные результаты, пока они не адаптируются.
Почему опасно. Оба эффекта искажают оценку долгосрочного влияния изменения. Вы можете раскатить фичу, чей «эффект» исчезнет через неделю (novelty). Или отвергнуть фичу, которая бы дала результат после адаптации (primacy).
Как исправить. Разделите анализ по когортам: отдельно смотрите на новых пользователей (которые не видели старый вариант) и на старых. Сравните эффект в первую неделю теста и в последнюю. Если эффект затухает со временем — скорее всего, novelty. Если растёт — primacy. Для надёжной оценки запускайте тест достаточно долго (минимум 2-3 недели).
На собеседовании. Покажите, что знаете оба эффекта и не путаете их. Хороший ход — предложить анализ по времени с момента попадания в тест: «Я бы построил график метрики по дням от начала экспозиции и посмотрел, стабилен ли эффект».
6. Множественные сравнения без поправки
Что это. Вы проверяете 15 метрик в одном тесте, находите две с p < 0.05, и объявляете успех. Поправку на множественность не делаете.
Почему опасно. При 15 метриках и alpha = 0.05 вероятность хотя бы одного ложного срабатывания — 54%. Две «значимые» метрики из пятнадцати — вполне ожидаемый результат при полном отсутствии реального эффекта. Вы принимаете решение на шуме.
Как исправить. Разделите метрики на основную (decision metric) и дополнительные. По основной — принимайте решение. По дополнительным — применяйте поправку на множественное сравнение: Бонферрони, Холм или Benjamini-Hochberg (FDR). Чем больше метрик, тем важнее коррекция.
На собеседовании. Знание трёх методов поправки — Бонферрони, Холм, BH — сильный плюс. Объясните разницу между FWER и FDR. Типичный вопрос: «Из 20 метрик одна значима. Что делаете?» Ответ: проверяю, была ли эта метрика основной. Если нет — применяю поправку. Скорее всего, после поправки значимость пропадёт.
7. Игнорирование сетевых эффектов (network effects)
Что это. В продуктах с социальным взаимодействием (маркетплейсы, соцсети, мессенджеры) пользователи тестовой и контрольной группы влияют друг на друга. Пример: вы тестируете новую механику приглашений. Пользователь из тестовой группы приглашает друга, который попал в контроль — и контрольная группа тоже «заражается» эффектом.
Почему опасно. При наличии интерференции (interference) между группами стандартное допущение A/B-теста — SUTVA (Stable Unit Treatment Value Assumption) — нарушено. Эффект в тесте занижен, потому что контроль тоже «получает» часть воздействия. Или наоборот — тест каннибализирует контроль.
Как исправить. Используйте cluster-based randomization: рандомизируйте не отдельных пользователей, а кластеры (города, компании, группы друзей). Внутри кластера все пользователи в одной группе — интерференция между группами минимальна. Альтернатива — switchback design (временные переключения) или ego-network randomization.
На собеседовании. Этот вопрос отличает мидла от синьора. Если вас спрашивают «как тестировать фичу в двустороннем маркетплейсе?», ответ про обычный A/B-тест недостаточен. Упомяните SUTVA, объясните, почему оно нарушается, и предложите кластерную рандомизацию.
8. Ошибка выжившего (survivorship bias)
Что это. В анализ попадают только пользователи, которые «дожили» до определённого момента. Пример: вы тестируете новый онбординг, но анализируете только тех, кто дошёл до третьего экрана. Те, кто ушёл раньше, выпали из анализа.
Почему опасно. Если тестовый вариант отпугивает пользователей на раннем этапе, до третьего экрана доходят только самые мотивированные. Их метрики будут выше, чем в контроле — но не потому, что фича хорошая, а потому, что вы сравниваете разные популяции. Это систематическое смещение отбора (selection bias).
Как исправить. Анализируйте по intention-to-treat (ITT): включайте всех, кто был рандомизирован в группу, независимо от того, видели ли они фичу. Если пользователь попал в тест, но ушёл до экспозиции — он всё равно в тестовой группе. ITT даёт консервативную, но несмещённую оценку. Если нужна оценка эффекта «на обработанных» — используйте CACE/LATE, но это сложнее.
На собеседовании. Термин «intention-to-treat» — ключевой. Объясните разницу между ITT и per-protocol анализом. Типичный вопрос: «Можно ли анализировать только тех, кто реально видел изменение?» Ответ: можно, но это per-protocol, и он подвержен selection bias. Основное решение принимайте по ITT.
9. Неправильный выбор метрики (vanity metrics)
Что это. Вы оцениваете тест по метрике, которая легко растёт, но не отражает ценность для бизнеса. Примеры: количество кликов (вместо конверсии в покупку), просмотры страницы (вместо retention), время на сайте (которое может расти из-за запутанного UI, а не из-за вовлечённости).
Почему опасно. Вы оптимизируете не то, что нужно. Фича, которая увеличивает клики на 15%, но не влияет на выручку или retention, не создаёт ценности. Хуже того — она может ухудшить реально важные метрики, которые вы не отслеживаете.
Как исправить. Выберите North Star метрику — ту, что связана с долгосрочной ценностью (revenue, retention, LTV). Она должна быть основной. Добавьте guardrail-метрики — те, которые не должны ухудшиться (например, crash rate, latency). Proxy-метрики (клики, просмотры) допустимы, только если вы заранее валидировали их связь с бизнес-результатом.
На собеседовании. Если вам предлагают оценить тест по «количеству кликов на кнопку», задайте вопрос: а как эти клики связаны с конечной конверсией? Покажите, что вы различаете proxy-метрики и outcome-метрики. Упомяните guardrail-метрики — это показывает зрелость мышления.
10. Слишком долгий тест (history threat)
Что это. Тест запускается и работает три месяца. За это время меняется сезон, проходит маркетинговая акция, конкурент запускает аналогичную фичу, обновляется приложение. Результат теста отражает не только вашу фичу, но и все внешние изменения.
Почему опасно. Долгий тест накапливает confounders — внешние факторы, которые по-разному влияют на группы. Если в середине теста изменился микс трафика (например, началась рекламная кампания с другой аудиторией), новые пользователи распределяются в группы, но их характеристики отличаются от тех, кто пришёл в начале. Рандомизация работает в момент назначения, но не защищает от изменения популяции.
Как исправить. Определите длительность до запуска на основе расчёта выборки. Включите полный бизнес-цикл (обычно 1-2 недели, чтобы покрыть день недели). Если тест неизбежно длинный — проверяйте стабильность эффекта по временным окнам: если эффект есть только в первую неделю и пропадает — это подозрительно. Следите за SRM (Sample Ratio Mismatch) — нет ли перекоса в размерах групп.
На собеседовании. Вопрос может звучать: «Тест идёт 3 месяца. Какие риски?» Перечислите: изменение популяции, сезонность, взаимодействие с другими экспериментами, history threat. Предложите проверку: сравнить эффект по неделям — если стабилен, результату можно доверять.
Как структурировать ответ на собеседовании
Когда вас просят назвать ошибки в A/B-тестах, не перечисляйте все десять списком. Выберите 3-4 самые релевантные для контекста вопроса и раскройте каждую по структуре: проблема, последствие, решение. Это покажет глубину, а не ширину.
Самые частые на собеседованиях — подглядывание (1), недостаточная мощность (2), множественные сравнения (6) и survivorship bias (8). Если вы идёте на позицию уровня senior — добавьте сетевые эффекты (7) и выбор единицы рандомизации (4).
Каждую ошибку связывайте с конкретным последствием для бизнеса: «раскатим неработающую фичу», «упустим рабочую идею», «примем решение на шуме». Интервьюер хочет видеть, что вы понимаете не только статистику, но и цену ошибки.
Потренируйтесь решать задачи по A/B-тестам и статистике в Карьернике — тренажёре для подготовки к собеседованиям аналитиков.
FAQ
Какие самые частые ошибки в A/B-тестах?
Подглядывание в результаты (peeking), недостаточная мощность теста, множественные сравнения без поправки и ошибка выжившего (survivorship bias). Эти четыре ошибки встречаются чаще всего и приводят к ложным выводам о работоспособности фичей.
Что такое подглядывание в A/B-тесте и чем оно опасно?
Подглядывание (peeking) — проверка p-value до достижения запланированного размера выборки. При ежедневной проверке двухнедельного теста реальная вероятность ложного срабатывания вырастает с 5% до 20-30%. Решение — зафиксировать размер выборки до запуска или использовать sequential testing.
Почему незначимый результат A/B-теста не означает отсутствие эффекта?
Тест с мощностью 30% пропустит реальный эффект в 7 случаях из 10. Незначимый результат может означать как отсутствие эффекта, так и недостаточный размер выборки. Нужно проверить мощность теста — если она была низкой, результат неинформативен.
Как избежать проблемы множественных сравнений в A/B-тесте?
Зафиксируйте одну основную метрику до запуска теста — для неё поправка не нужна. Для вторичных метрик применяйте поправку Бонферрони, Холма или Benjamini-Hochberg (FDR). Чем меньше метрик проверяете, тем меньше потери мощности.