Для каждой задачи определите, какая именно ошибка допущена, как её диагностировать по данным и логам эксперимента и как скорректировать дизайн или анализ.
Команда запускает A/B-тест новой воронки checkout. Рандомизация — по user_id, 50/50.
Аналитик выбирает метрику «доля сессий с покупкой» и считает t-test на уровне сессий. N получается 8 млн сессий, p = 0.02.
В логах видно, что есть небольшая группа power users, у которых по 50–100 сессий за период, и они чаще попали в тест.
Что сломано: ошибка единицы анализа и fan-out. Эксперимент рандомизируется по пользователям, а анализ ведётся по сессиям. Power users с десятками сессий получают непропорционально большой вес.
Как проверить: построить распределение числа сессий на пользователя по группам, посмотреть долю total сессий, приходящихся на топ-1% пользователей; сравнить результаты t-test на уровне сессий и на уровне пользователей (одна строка на user_id).
Как исправить: агрегировать данные до user-level (метрика: «есть покупка / нет покупки у пользователя за период») и пересчитать эффект. При необходимости дополнительно ограничить вклад экстремальных пользователей (winsorization или отсечение по числу сессий).
Аналитик хочет оценить влияние новой рекомендательной ленты на средний чек (AOV).
Он считает для каждого пользователя AOVi = GMVi / Ordersi, затем берёт среднее по пользователям и сравнивает группы простым t-test по этим значениям.
В примере из выборки есть пользователь A с 1 заказом на 50 ₽ и пользователь B со 100 заказами, суммарно на 50 000 ₽ — оба дают одинаковый вес в среднем AOV.
Что сломано: используется mean of ratios вместо ratio of means, heavy users недооценены. Оценка AOV смещена относительно того, что обычно понимается как «средний чек заказа».
Как проверить: посчитать AOV как глобальное отношение суммарного GMV к суммарному числу заказов в каждой группе и сравнить с mean of ratios. Если результаты сильно различаются, значит mean of ratios искажает картину.
Как исправить: использовать ratio of means: считать AOVgroup = ΣGMV / ΣOrders и применять к нему delta-method или bootstrap по пользователям для оценки дисперсии и доверительных интервалов.
В эксперименте по новой онбординг-воронке основная метрика — конверсия в первую покупку (CR). По итогам 21 дня CR даёт p = 0.12.
Продакт просит «посмотреть, что ещё изменилось». Аналитик проверяет ещё 19 метрик: активацию, retention, глубину, engagement, и находит «time to first action» с p = 0.04.
В презентации в итоге фигурирует только эта одна «успешная» метрика, без упоминания остальных 19.
Что сломано: множественное тестирование без коррекции и выбор метрики после просмотра данных (p-hacking). При 20 метриках и α = 0.05 ожидается ~1 ложноположительный результат даже при нулевом эффекте.
Как проверить: посчитать количество проверенных метрик и распределение их p-value; оценить вероятность хотя бы одного ложноположительного: 1 − (1 − 0.05)20. Проверить, была ли заранее задокументирована primary metric и список вторичных.
Как исправить: явно зафиксировать primary metric до запуска и принимать решение только по ней. Для вторичных метрик применять коррекцию (Bonferroni, Holm, BH). Анализ «19 дополнительных метрик» считать exploratory и использовать только для генерации гипотез для будущих тестов.
Эксперимент запланирован на 28 дней. С первого дня PM просит ежедневный отчёт по CR и p-value.
На 10-й день аналитик докладывает: «p = 0.04, кажется, победили». PM решает завершить эксперимент и выкатывать фичу, не дожидаясь оставшихся 18 дней.
Постфактум, если бы эксперимент довели до 28 дней, оказалось бы, что итоговое p = 0.18 и эффект нестабилен.
Что сломано: multiple testing по времени (peeking) и ранняя остановка без заранее спроектированного sequential-дизайна. p = 0.04 на 10-й день нельзя интерпретировать как «значимо на 5%».
Как проверить: посчитать количество фактических «просмотров» p-value (по дням или по батчам данных); смоделировать (или оценить теоретически) рост эффективного α при таком числе промежуточных проверок.
Как исправить: либо придерживаться фиксированного горизонта (решение только в конце), либо заранее спроектировать sequential-test (O'Brien–Fleming, always-valid p-values) с формальными правилами остановки и использовать соответствующие границы для p-value.
Запущен эксперимент с ожидаемым сплитом 50/50, целевая аудитория — 1 млн пользователей.
По факту в выгрузке: 503 000 пользователей в тесте и 497 000 в контроле. χ²-тест на соответствие 50/50 даёт p = 0.001.
Аналитик говорит: «Разница всего 0.3 п.п., давайте не будем придираться» и продолжает анализ CR и AOV.
Что сломано: игнорирование Sample Ratio Mismatch. Значимое отклонение от запланированного сплита указывает на систематическую проблему в рандомизации или отборе данных.
Как проверить: формально провести χ²-тест для всех активных экспериментов; сегментировать пользователей по ключевым признакам (страна, платформа, источник трафика) и проверить, нет ли дисбаланса сплита внутри сегментов.
Как исправить: остановить интерпретацию эффекта, исследовать причины SRM (кеши, редиректы, баги в bucketing, фильтрация ботов только в одной группе). После исправления — перезапустить эксперимент. Не использовать текущие результаты для принятия решений.
Социальная сеть тестирует новый формат кнопки «Поделиться». Рандомизация по пользователям: 50% получают новую кнопку, 50% остаются со старой.
Пользователи из теста начинают делиться контентом чаще, этот контент попадает в ленты их друзей, включая тех, кто остался в контроле.
По итогам эксперимента аналитик видит +3% к просмотрам ленты у тестовых пользователей и +1.5% у контрольных, и делает вывод, что «эффект небольшой».
Что сломано: сильный spillover между treatment и control через социальный граф, нарушение SUTVA. Контрольная группа частично экспонирована эффекту treatment.
Как проверить: проанализировать зависимость метрик контрольных пользователей от доли их друзей в тесте; посмотреть, не растут ли просмотры в контроле сильнее именно у тех, у кого много «тестовых» друзей.
Как исправить: перейти к кластерной рандомизации по кластерам графа (сообщества, школы, компании) или использовать специализированные network-экспериментальные дизайны; интерпретировать текущий +3% как нижнюю оценку эффекта при полном rollout.
Тестируется новый алгоритм таргетинга рекламы. В тестовой группе количество показов на пользователя выросло на 30%, а общее число кликов увеличилось на 10%.
CTR упал с 2.1% до 1.8%. PM делает вывод: «реклама стала менее эффективной, отключаем алгоритм».
Аналитик сомневается: абсолютное число кликов и выручка от рекламы на пользователя всё же выросли.
Что сломано: поломанный знаменатель. Treatment изменяет количество показов (denominator), и CTR уже не отражает «чистый» отклик пользователей.
Как проверить: сравнить между группами не только CTR, но и клики на пользователя, выручку на пользователя и распределение impressions per user; проверить, нет ли сильного смещения в сторону «дешёвых» показов.
Как исправить: фокусировать выводы на per-user метриках (клики/выручка на пользователя), использовать ITT-подход (все рандомизированные пользователи, даже с нулевой экспозицией). CTR оставить как диагностическую метрику, но не как основную для решения.
Проводится эксперимент с новым онбордингом. Через 7 дней измеряется Retention D7 для тех, кто прошёл активацию (совершил целевое действие в день 0).
В тесте: D7 среди активированных = 42%, в контроле = 38%. Но при этом доля пользователей, которые вообще дошли до активации, в тесте на 5 п.п. ниже, чем в контроле.
В отчёте показывают только D7 по активированным и заявляют, что retention улучшился.
Что сломано: выживший (survivor) bias и условная метрика. Сравниваются только те, кто прошёл через воронку, хотя сама вероятность пройти в тесте ниже.
Как проверить: посмотреть конверсию в активацию по группам; посчитать ITT-метрику «доля всех рандомизированных пользователей, вернувшихся на D7», а не только среди активированных.
Как исправить: использовать ITT-подход по всему когорту; анализировать две вещи: (1) влияние на активацию, (2) влияние на retention среди активированных, и интерпретировать их совместно, а не по отдельности.
После эксперимента по новой ленте аналитик решает «поглубже покопаться» и делит пользователей на сегменты по активности во время теста: high-activity (≥ 20 сессий) и low-activity (< 20 сессий).
В high-activity сегменте находит +10% CR и p = 0.01, в low-activity сегменте — ничего значимого. В отчёте делается акцент именно на high-activity.
Что сломано: сегментация по post-treatment признаку, который сам может зависеть от treatment. Активность во время эксперимента — уже результат фичи.
Как проверить: сравнить распределение активности между группами; проверить, нет ли сильного роста доли high-activity пользователей именно в тесте (что и является эффектом treatment).
Как исправить: использовать предэкспериментальные признаки для сегментации (активность за прошлый месяц, LTV, канал трафика). Post-treatment сегменты можно использовать только для генерации гипотез и визуализаций, но не для формальных выводов.
Проводится geo-эксперимент по 12 городам (6 тест, 6 контроль). Метрика — RPM (revenue per 1000 impressions).
Аналитик выгружает данные на уровне пользователей, считает RPMi = Revenuei / Impressionsi и запускает обычный t-test по 600 тыс. пользователей.
В анализе никак не учитывается ни ratio-природа метрики, ни факт, что рандомизация была по городам.
Что сломано: двойная ошибка. (1) RPM — ratio-метрика, для неё нужен ratio of means + специальный анализ (delta-method, bootstrap). (2) Рандомизация по городам → единица анализа должна быть кластером, а не пользователем.
Как проверить: посчитать RPM как ΣRevenue / ΣImpressions на уровне городов; сравнить результаты user-level и city-level анализа; оценить, насколько сильно различаются p-value.
Как исправить: агрегировать данные до уровня города: для каждого города посчитать ΣRevenue и ΣImpressions, взять ratio и затем провести тест по 12 наблюдениям (t-test или permutation test). Либо использовать регрессию с cluster-robust SE по городам и delta-method для ratio.
Новая версия UI ленты запускается на 50% пользователей. В первую неделю среднее время в приложении у тестовой группы на 15% выше, чем у контроля, p < 0.01.
К концу четвёртой недели uplift снижается до +2%, а на пятой неделе почти исчезает. Аналитик всё равно в отчёте показывает график за первую неделю и делает акцент на +15%.
Что сломано: игнорирование novelty / learning effect. Пользователи активно исследуют новый интерфейс, но долгосрочное поведение оказывается гораздо ближе к контролю.
Как проверить: построить динамику эффекта по неделям; сравнить краткосрочный uplift с устойчивым уровнем на 3–4 неделе; проверить, не изменяется ли распределение по когортам (новые vs старые пользователи).
Как исправить: фокусироваться на стабилизированном периоде (последние недели эксперимента) или использовать долгоживущие holdout-группы; в отчётах явно разделять краткосрочный novelty-эффект и долгосрочный steady-state.
A/B-сплит реализован на сервере: при первом заходе пользователя ему назначается variant, и дальше он должен получать соответствующую версию страницы.
Однако перед фронтендом стоит CDN, который кеширует HTML по URL без учёта куки с variant. Часть пользователей, формально попавших в контроль, видит кешированную версию теста.
В статистике видно SRM: тест = 52%, контроль = 48%; при этом по логам CDNs понятно, что кеш пробивается неоднородно по странам и девайсам.
Что сломано: кеширование обходит механизм рандомизации, пользователи видят не тот вариант, который им назначен. Это приводит и к SRM, и к нарушению чистоты контроля.
Как проверить: сравнить variant по логам бэкенда и фактически отданную версию (по шаблонам, версиям CSS/JS); посмотреть распределение variant vs фактической разметки по странам/устройствам/POP-узлам.
Как исправить: настроить CDN так, чтобы в ключ кеша входили кука/заголовок с variant; либо отключить кеширование для экспериментальных URL; после исправления — перезапустить эксперимент, не используя текущие данные для выводов.
Проводится эксперимент с 4 вариантами интерфейса: A (контроль), B, C, D. Цель — найти лучший из трёх новых вариантов.
Аналитик считает все 6 попарных сравнений (A-B, A-C, A-D, B-C, B-D, C-D) и находит одно значимое: B выигрывает у C с p = 0.04.
В презентации делается вывод: «вариант B статистически лучше варианта C, поэтому его и выкатим».
Что сломано: множественные сравнения без коррекции. При 6 сравнениях вероятность хотя бы одного ложноположительного результата при α = 0.05 существенно выше 5%.
Как проверить: зафиксировать, какие именно сравнения планировались (только vs контроль или все попарные); оценить ожидаемое число ложноположительных: 6 × 0.05 = 0.3; проверить устойчивость результата при коррекциях.
Как исправить: если интересуют только сравнения с контролем — использовать методы типа Dunnett или Holm. Если все попарные — применять Bonferroni/Holm/BH-исправления и/или многофакторные модели (ANOVA с post-hoc тестами), а не делать выводы по одиночному p = 0.04 без коррекции.
Новая акция увеличила конверсию в покупку на 20%. При этом ARPPU (average revenue per paying user) в тестовой группе снизился на 8% относительно контроля.
Аналитик делает вывод: «акция ухудшает монетизацию на покупателя, не будем её запускать».
Однако видно, что в тесте появилось много новых «лёгких» покупателей с небольшими чеками, которых в контроле почти не было.
Что сломано: неправильная интерпретация conditional-метрики. ARPPU считается только по платящим пользователям, а treatment изменяет саму популяцию платящих (композиционный эффект).
Как проверить: сравнить распределение чеков и число платящих пользователей в группах; посчитать ITT-метрику «общая выручка на пользователя» и посмотреть, как она изменилась.
Как исправить: для принятия решений использовать ITT-метрики (выручка на пользователя, GMV на пользователя), а ARPPU трактовать как вспомогательную; при желании можно применить двухэтапный анализ: сначала эффект на конверсию в покупку, затем — на средний чек при фиксированной группе покупателей (например, по когорте уже плативших до эксперимента).