Для каждой задачи: (a) выберите метод ускорения (или объясните, почему ускорение невозможно), (b) оцените ожидаемый выигрыш, (c) назовите главный риск.
Ситуация: A/B-тест на 80K пользователей. Метрика: revenue per user (heavy tail). Pre-period 2 недели. Корреляция pre-post ρ = 0.7. Текущий MDE = +8%. Команда хочет MDE = +5%.
Метод: CUPED + winsorization.
Выигрыш: ρ = 0.7 → variance reduction = 49%. MDE ∝ σ/√n → MDE снижается на ~29% (√0.51 ≈ 0.71). Текущий MDE 8% × 0.71 ≈ 5.7%. Близко к цели. Добавить winsorization на P99 → ещё 10–20% снижения дисперсии. Итоговый MDE ≈ 4.5–5%.
Риск: winsorization может скрыть эффект, если treatment создаёт whale users. Показать результат с winsorization и без.
Ситуация: Тест нового онбординга. Только новые пользователи (зарегистрировались после start). Метрика: число сессий за 7 дней. Нет pre-period данных.
Метод: стратификация по доступным pre-treatment характеристикам: registration source (organic / paid), device (iOS / Android / web), region.
Выигрыш: 10–20% снижения дисперсии (зависит от гетерогенности между стратами).
Почему не CUPED: у новых пользователей нет pre-period метрик. CUPED неприменим.
Риск: если число страт > 20 при N < 10K — некоторые страты будут пустыми или с 1–2 пользователями.
Ситуация: A/B-тест. Pre-period есть, но корреляция ρ = 0.1 (метрика нестабильна — число просмотренных товаров сильно варьируется неделя к неделе).
Метод: CUPED даёт variance reduction = 0.1² = 1%. Это эквивалентно увеличению выборки на 1% — незначимо.
Рекомендация: не применять CUPED. Усложнение analysis pipeline не оправдано. Лучше: (1) увеличить pre-period (2–4 недели → ρ может вырасти). (2) Использовать другую ковариату с более высокой корреляцией (revenue вместо просмотров). (3) Стратификация.
Риск: нет — CUPED при низкой корреляции не вредит, но и не помогает.
Ситуация: Тест нового pricing. Метрика: ARPPU. Pre-period ARPPU за 2 недели. Корреляция ρ = 0.6. Аналитик хочет применить CUPED.
Проблема: ARPPU — conditional-метрика (считается только среди покупателей). Treatment может изменить конверсию → состав «покупателей» изменится → новые покупатели не имели pre-period покупок → для них ковариата = 0.
Следствие: CUPED работает только для «старых» покупателей. Для новых — ковариата неинформативна. Общий выигрыш значительно ниже ожидаемого по ρ = 0.6.
Рекомендация: (1) Использовать ITT-метрику (revenue per user, включая нули) + CUPED — здесь ковариата валидна. (2) ARPPU — вспомогательная метрика, не primary.
Риск: если применить CUPED к ARPPU «в лоб» — bias: ковариата коррелирует с composition change.
Ситуация: Эксперимент стартовал 1 марта. Аналитик берёт pre-period с 15 по 28 февраля. Но: рандомизация произошла 25 февраля (пользователи были «помечены» заранее). С 25 по 28 февраля некоторые пользователи тест-группы уже видели preview новой фичи.
Проблема: data leakage. Pre-period (15–28 фев) пересекается с treatment exposure (25–28 фев). Ковариата Xpre содержит информацию о treatment → вычитание Xpre вносит bias.
Следствие: CUPED занижает эффект (вычитает часть treatment effect вместе с baseline).
Рекомендация: обрезать pre-period до 15–24 февраля (строго до начала ramp-up). Правило: Xpre ← данные до min(assignment_date, exposure_date).
Риск: если не обрезать — bias в оценке ATE. Направление: занижение (ATE ↓).
Ситуация: Revenue per user. Результаты:
Какой порог выбрать?
Проблема: каждый порог даёт разный результат. Выбирать порог после просмотра результатов — p-hacking.
Правило: порог фиксируется в analysis plan до эксперимента. Стандарт: P99 (компромисс между стабильностью и сохранением эффекта).
Интерпретация: эффект концентрируется в хвосте (Δ падает от 12% до 2% при aggressive trimming). Это значит: treatment создаёт high-value пользователей. Winsorization скрывает реальный эффект.
Рекомендация: (1) Primary — P99 (зафиксирован заранее). (2) Sensitivity: показать все варианты. (3) Если бизнес-ценность в хвосте — обсудить с product owner.
Ситуация: аналитик стратифицирует анализ по «числу сессий во время теста» (high activity / low activity). Аргумент: «так мы видим эффект отдельно для активных и неактивных пользователей».
Проблема: число сессий во время теста — post-treatment переменная. Treatment может влиять на активность → состав «активных» зависит от treatment → это conditioning on post-treatment variable (Модуль 01).
Следствие: оценка эффекта в каждой страте смещена. Selection bias внутри страт.
Рекомендация: стратифицировать по pre-treatment активности (число сессий за 2 недели до теста). Тогда страты не зависят от treatment.
Ситуация: A/B-тест, 100K пользователей. 60% — returning users (имеют pre-period). 40% — новые (нет pre-period). Корреляция pre-post для returning = 0.65. Как применить CUPED?
Метод: два подхода.
Подход A: применить CUPED только к returning users. Для новых — стандартный t-test. Объединить оценки (inverse-variance weighting).
Подход B: для новых использовать стратификацию (device, source) вместо CUPED. Combining: CUPED для returning + стратификация для new → общая variance reduction.
Выигрыш: returning (60%): variance reduction 42% (0.65²). Новые (40%): стратификация 10%. Общий ≈ 60% × 42% + 40% × 10% = 29%.
Риск: если когорты сильно различаются по behavior — считать ATE отдельно и проверять гетерогенность.
Ситуация: Revenue per user. Heavy tail. Pre-period ρ = 0.6. Аналитик хочет применить winsorization + CUPED. Вопрос: в каком порядке?
Правильный порядок: (1) Winsorization → (2) CUPED.
Почему: CUPED оценивает θ = Cov(Y, Xpre) / Var(Xpre). Если Y и Xpre содержат экстремальные выбросы — оценка θ нестабильна. Winsorization до CUPED стабилизирует θ.
Альтернатива: winsorization обоих: Y и Xpre, на том же пороге (P99). Затем CUPED на winsorized данных.
Риск: если winsorization порог разный для Y и Xpre — искажение корреляции.
Ситуация: тест на 50K пользователей. На день 7 (из запланированных 21) p = 0.02. Менеджер требует остановить тест и запустить фичу.
Проблема: ранняя остановка при фиксированном α = 0.05 даёт inflated false positive rate. Если проверять p-value каждый день в течение 21 дня — реальный α ≈ 0.15–0.20 (не 0.05).
Что делать: (1) Если заранее запланирован sequential testing (O'Brien-Fleming, always-valid p-values) — можно остановить, если p < adjusted threshold. (2) Если это post-hoc «подсмотрели» — нельзя, FPR инфлирован.
Рекомендация: (1) Зафиксировать sequential design до запуска. (2) Объяснить менеджеру: «p = 0.02 на день 7 при 21-дневном горизонте — реальный p ≈ 0.08–0.10». (3) CUPED может помочь: снижая дисперсию, позволяет достичь значимости быстрее без early stopping.
Ситуация: аналитик добавляет 10 ковариат в регрессию для variance reduction: pre-period revenue, sessions, device, OS, region, age, signup source, email_verified, app_version, language.
Проблема: (1) Diminishing returns: первые 2–3 ковариаты дают 80% выигрыша. Остальные 7 — шум. (2) Переобучение: при 10 ковариатах θ-коэффициенты нестабильны. (3) Если ковариаты выбраны после просмотра данных — p-hacking.
Рекомендация: (1) 1–3 ковариаты: pre-period метрика + device + крупнейший сегмент. (2) Зафиксировать в analysis plan. (3) Cross-validation: оценить θ на train split, применить на test split (или использовать held-out pre-experiment data).
Риск: при 10 ковариатах и N = 10K — R² overfit, и variance reduction на train > на test. Реальный выигрыш ниже.
Ситуация: число дневных активных пользователей (DAU) растёт на 3% в неделю (organic growth). Pre-period DAU = 500K, за время теста = 530K. Корреляция week-to-week = 0.8.
Проблема: метрика нестационарна (тренд +3%/неделю). CUPED вычитает pre-period уровень, но тренд продолжается и в post-period. Если тренд одинаков в тесте и контроле — CUPED работает (тренд вычитается одинаково из обеих групп). Если тренд асимметричен — bias.
Рекомендация: (1) Проверить: тренд одинаков в обеих группах? (AA-test или pre-period по группам). (2) Использовать de-trended ковариату: Xpre − linear_trend. (3) Если тренд сильный и асимметричный — CUPED ненадёжен; стратификация предпочтительнее.
Риск: если тренд в одной группе сильнее (например, treatment привлекает больше новых пользователей) — CUPED вносит bias.
Ситуация: E-commerce. Revenue per user. Heavy tail. Pre-period 2 недели, ρ = 0.55. Два сегмента: mobile (70%) и desktop (30%), desktop тратит в 3× больше. Цель: снизить MDE с 10% до 5%.
Стратегия:
Совокупно: 1 − (1 − 0.25)(1 − 0.15)(1 − 0.30) ≈ 55% снижения дисперсии.
MDE: 10% × √(1 − 0.55) ≈ 10% × 0.67 = 6.7%.
Не достигает 5%, но существенно ближе. Для 5% нужно ещё увеличить выборку в ~1.8×.
Риск: если winsorization скрывает эффект в хвосте — sensitivity analysis с P99.5 и без winsorization.