code-ai-installer 3.0.0 → 4.0.1-a

package/domains/product/.agents/skills/ab-test-design/SKILL.md

@@ -1,412 +1,428 @@
----
-name: ab-test-design
-description: Дизайн A/B-теста — primary metric, MDE, sample size, duration, guardrails, critical region
----
-# A/B Test Design
-
-> **Категория:** Experimentation  ·  **Slug:** `ab-test-design`
-
-## Когда использовать
-
-- Для валидации гипотезы с количественным сигналом.
-- При выкатке высокорискованных изменений (ценообразование, онбординг, ключевой поток).
-- Для сравнения альтернатив, когда доказательства неясны.
-- При измерении влияния функции для критериев успеха PRD.
-
-## Вход
-
-| Поле | Обязательно | Описание |
-|------|:-----------:|----------|
-| Hypothesis | ✅ | Через `$hypothesis-template` |
-| Primary metric | ✅ | Что измеряем |
-| Baseline metric value | ✅ | Текущее среднее + дисперсия |
-| Expected effect size | ✅ | MDE — минимальный обнаруживаемый эффект |
-| Traffic / eligible users | ✅ | Недельная подходящая выборка |
-| Infrastructure | ✅ | Флаги функций / платформа экспериментов |
-
-## Источники данных
-
-1. Исторические данные метрики — базовый уровень + дисперсия.
-2. `$hypothesis-template` — ожидаемое направление + величина.
-3. Пользовательская аналитика — подходящая аудитория.
-4. Отраслевые бенчмарки — типичные размеры эффектов.
-
-### Связь с другими скилами
-
-| Скил | Что берём | Когда вызывать |
-|------|-----------|----------------|
-| `hypothesis-template` | Что тестируем | Предусловие |
-| `saas-metrics` | Основные + контрольные метрики | Для выбора |
-| `aarrr-metrics` | Контекст воронки | Для понимания |
-| `assumption-mapping` | Высокорискованное допущение → A/B | Для топ-допущений |
-
-## Протокол
-
-### Шаг 0 — Подходит ли A/B?
-
-Чеклист:
-- Достаточно трафика (≥ 1000 пользователей / неделю на вариант)?
-- Метрика поддаётся инструментированию + обнаружима в рамках временного горизонта?
-- Изменение изолируемо (не запутано с другими выкатками)?
-- Допустимо ли A/B тестирование (не критическая безопасность / соответствие)?
-
-Если нет — альтернативы: поэтапная выкатка с когортным сравнением, до/после, качественное тестирование.
-
-### Шаг 1 — Основная метрика
-
-Единственная основная метрика. Не несколько («Влияние на activation И retention»).
-
-Типичные варианты:
-- **Activation:** 7-дневный коэффициент активации
-- **Retention:** активность неделя/неделю, отток
-- **Conversion:** signup → paid, trial → active
-- **Engagement:** действий за сессию, DAU/MAU
-
-Свойства:
-- **Обнаружима** в разумном размере выборки
-- **Согласована** с ожидаемым результатом гипотезы
-- **Чувствительна** — реагирует, когда происходит ожидаемое изменение
-- **Достоверна** — сложно поддаётся манипуляции
-
-### Шаг 2 — Минимальный обнаруживаемый эффект (MDE)
-
-MDE — наименьший прирост, который стоит обнаруживать. Компромисс:
-- Меньший MDE = нужна большая выборка = более долгий тест
-- Больший MDE = более быстрый тест, но можно пропустить небольшие улучшения
-
-Практические правила:
-- Метрики активации: MDE 3-5% (пп)
-- Метрики конверсии: MDE 5-10% (пп) относительный прирост
-- Метрики удержания: MDE 2-4% (пп)
-
-В B2B: меньшие выборки → MDE чаще 5-10% минимум.
-
-### Шаг 3 — Расчёт размера выборки
-
-Формула для тестов долей:
-```
-n на вариант = (Z_α/2 + Z_β)² × 2 × p(1-p) / MDE²
-```
-
-Где:
-- Z_α/2 = 1.96 (95% доверительный интервал)
-- Z_β = 0.84 (80% мощность)
-- p = базовый коэффициент
-- MDE = минимальный обнаруживаемый эффект
-
-Для непрерывных метрик — аналогичная формула с дисперсией.
-
-**Использовать калькулятор:** онлайн-инструменты (Evan Miller, калькулятор Optimizely) — не рассчитывать вручную.
-
-### Шаг 4 — Продолжительность
-
-Продолжительность = размер_выборки × варианты / еженедельные_подходящие_пользователи.
-
-Умножить:
-- На 1.5-2× для недельной цикличности (будни vs выходные)
-- Для B2B: минимум 2 недели (полный недельный цикл)
-- Максимум: 6-8 недель (сверх этого — контекст меняется, сезонность)
-
-### Шаг 5 — Рандомизация
-
-- **Единица:** уровень пользователя или аккаунта (B2B: обычно уровень аккаунта, чтобы избежать раздвоения в команде)
-- **Сид:** случайный, но детерминированный (один и тот же пользователь получает тот же вариант при повторном посещении)
-- **Распределение:** 50/50 по умолчанию, можно 80/20 (упор на контроль) для рискованных изменений
-
-### Шаг 6 — Контрольные метрики
-
-Метрики, которые не должны деградировать:
-- Коэффициент оттока
-- NPS / CSAT
-- Объём обращений в поддержку
-- Задержка p95 / коэффициент ошибок
-- Выручка / пользователь
-
-Установить пороги (например, «отток не может расти >1pp»).
-
-### Шаг 7 — План сегментного анализа
-
-Предзарегистрировать (не p-hacking после):
-- По размеру компании
-- По стажу (новые vs давние)
-- По роли
-- По географии (если актуально)
-
-Задокументировать в плане теста, а не после результатов.
-
-### Шаг 8 — Статистический метод
-
-- **Частотный** (наиболее распространённый): p-value < 0.05, мощность 80%
-- **Байесовский:** апостериорная вероятность улучшения > 95%
-
-Выбрать один. Задокументировать.
-
-### Шаг 9 — Критическая область / Правила остановки
-
-Когда остановить тест:
-- **Успех** — достигнута значимость, остановить
-- **Провал (бесполезность):** минимальный эффект после N% выборки, остановить
-- **Нарушение контрольной метрики:** даже если основная метрика выигрывает, остановить
-- **Лимит времени:** достигнута максимальная продолжительность
-
-**НИКОГДА не подглядывать раньше времени** и останавливать по p-value (увеличивает долю ложноположительных результатов) без последовательного дизайна тестирования.
-
-### Шаг 10 — Предзарегистрированный план анализа
-
-Задокументировать ДО запуска теста:
-- Основная метрика + MDE + размер выборки
-- Сегменты
-- Контрольные метрики
-- Критерии остановки
-- Правила интерпретации
-
-Позволяет избежать HARKing (Hypothesizing After Results Known — выдвижение гипотез после получения результатов).
-
-## Валидация (Quality Gate)
-
-- [ ] A/B подходит (трафик, изоляция, допустимость)
-- [ ] Основная метрика единственная + чётко определена
-- [ ] Обоснование MDE (бизнес + обнаружимость)
-- [ ] Рассчитан размер выборки
-- [ ] Продолжительность ≥ 2 недель, ≤ 8 недель
-- [ ] Единица рандомизации подходящая (пользователь / аккаунт)
-- [ ] Контрольные метрики с порогами
-- [ ] Сегментный анализ предзарегистрирован
-- [ ] Статистический метод выбран + обоснован
-- [ ] Правила остановки явны
-- [ ] Предзарегистрированный план анализа
-
-## Handoff
-
-Результат является входом для:
-- **Engineering** → флаг функции + инструментирование
-- **Data Analyst** → дашборд мониторинга
-- **PM** → критерии запуска
-- **Stakeholders** → еженедельные отчёты
-
-Формат: документ дизайна A/B теста (markdown). Через `$handoff`.
-
-## Anti-patterns
-
-| Ошибка | Почему плохо | Как правильно |
-|--------|-------------|---------------|
-| Несколько основных метрик | Раздувание p-value | Единственная основная |
-| Подглядывание + ранняя остановка | Ложноположительный результат | Последовательный или фиксированная продолжительность |
-| Нет обоснования MDE | Недостаточная мощность или слишком долгий тест | Обоснование через бизнес + обнаружимость |
-| Игнорировать контрольные метрики | Функция «выигрывает», ломая другое | Явные контрольные метрики с критериями отключения |
-| Нет предрегистрации | HARKing, p-hacking | Планировать до запуска |
-| Короткая продолжительность | Шум недельного цикла | Минимум 2 недели |
-| Уровень пользователя в B2B потоке | Один аккаунт, разные варианты | Рандомизация на уровне аккаунта |
-
-## Шаблон
-
-```markdown
-# A/B Test: [Название]
-
-## Гипотеза
-[через $hypothesis-template]
-
-## Основная метрика
-- Метрика: [например, 7-дневный коэффициент активации]
-- Базовый уровень: X% (последние 30 дней)
-- MDE: +5pp (обоснование: бизнес-потребность + поддержка выборки)
-
-## Выборка и продолжительность
-- Подходящих пользователей / неделю: Y
-- Выборка на вариант: Z
-- Рассчитанная продолжительность: N недель
-- Запланированная продолжительность: N недель (с учётом цикличности)
-
-## Варианты
-- Контроль: текущий поток
-- Тест: [изменение]
-- Распределение: 50/50
-- Рандомизация: уровень аккаунта, детерминированная
-
-## Контрольные метрики
-| Метрика | Текущий | Порог |
-| Коэффициент оттока | 2% | < 2.5% |
-| NPS | 45 | ≥ 43 |
-| Задержка p95 | 180ms | < 200ms |
-
-## Предзарегистрированный анализ
-- Сегменты: размер компании, роль пользователя
-- Статистический метод: частотный, α=0.05, мощность=0.8
-- Критерии выкатки: основная метрика +MDE значима, нет нарушений контрольных метрик
-
-## Правила остановки
-- Успех: достигнута значимость + контрольные метрики в норме → выкатить
-- Провал: эффект < MDE при 50%+ выборки → отклонить
-- Контрольная метрика: нарушена любая → остановить, расследовать
-- Максимальная продолжительность: 8 недель
-```
-
-## Worked Example — TeamFlow Onboarding A/B Test (Post-MVP Iteration)
-
-**Контекст:** AI Summarization MVP выкачен. 30 дней спустя, гипотеза H-003 (принятие) отслеживает 42% принятия — ниже цели 60%. Data Analyst проектирует A/B тест чеклиста онбординга vs контроль для итерации.
-
-```markdown
-# A/B Test Design: Onboarding Checklist for New AI Tier Managers
-
-**Experiment ID:** EXP-025
-**Статус:** Утверждён, запуск 8 июля 2026
-**Владелец:** Sam P. (Data) + Alex K. (PM) + Jordan M. (Design)
-**Гипотеза:** Итерация 1 гипотезы H-003
-
-## Гипотеза (переформулирована для теста)
-
-**Мы считаем**, что предоставление чеклиста онбординга («Выполните 3 шага, чтобы освоить AI-резюме»)
-**Для** менеджеров, только что активированных в AI-tier аккаунтах,
-**Приведёт к** более высокому 30-дневному еженедельному коэффициенту принятия
-**Мы узнаем, что это правда, когда** 30-дневный коэффициент принятия в тестовой группе будет на ≥5pp выше, чем в контрольной
-**Потому что:**
-  - Открытие удивило: 60% не принявших указали «не знал с чего начать» в опросе после запуска
-  - Чеклисты онбординга в существующих функциях TeamFlow показывают прирост активации +22% (внутренний бенчмарк)
-  - 7-дневное окно первой активации предсказывает долгосрочное удержание (когортный анализ Q1)
-
-## Основная метрика
-
-- **Метрика:** 30-дневный еженедельный коэффициент принятия (% только что активированных менеджеров, использовавших AI-резюме ≥1 раза в неделю в недели 2-4 после активации)
-- **Базовый уровень:** 42% (текущий, измерен за последние 30 дней выкатки AI тарифа)
-- **MDE:** +5pp (цель: 47% тест vs 42% контроль)
-- **Обоснование MDE:**
-  - Бизнес-порог: +5pp × ~200 новых менеджеров/месяц = 10 дополнительно удержанных менеджеров/месяц = $2.4K MRR
-  - Обнаружим с разумной выборкой (см. расчёт размера выборки)
-  - Ниже 5pp несущественно для решения на уровне PM
-
-## Расчёт размера выборки
-
-Используя формулу для теста долей:
-- Базовый уровень p1 = 0.42
-- Тест p2 = 0.47 (цель)
-- α = 0.05 (двусторонний)
-- Мощность = 0.80
-- Z_α/2 = 1.96, Z_β = 0.84
-
-n на вариант = 2 × (1.96 + 0.84)² × [0.42(0.58) + 0.47(0.53)] / (0.05)² 
-             ≈ 2 × 7.84 × 0.493 / 0.0025
-             ≈ 3092
-
-**Выборка на вариант: ~3100**
-**Итоговая выборка: 6200**
-
-## Продолжительность
-
-- Еженедельно активирующихся менеджеров в AI тарифе: ~200/неделю
-- Продолжительность: 6200 / 200 = **31 неделя**
-
-**Проблема:** 31 неделя — неразумно долго. Варианты:
-1. **Поднять MDE до 7pp** (цель 49%) — продолжительность сократится до ~16 недель
-2. **Увеличить распределение до 80/20** — больше веса на тест, но ускорения нет
-3. **Принять увеличенный горизонт** с еженедельным мониторингом для раннего сигнала
-
-**Решение:** Поднять MDE до 7pp (цель 49%). Обоснование с точки зрения бизнеса — 7pp × 200 менеджеров = 14 менеджеров/месяц сохранено, существенно.
-
-**Пересмотренная продолжительность: 16 недель.** Плюс буфер на цикличность: итого 18 недель.
-
-## Варианты
-
-- **Контроль (50%):** Текущий опыт — менеджер активирует тариф, видит стандартный онбординг TeamFlow, без чеклиста
-- **Тест (50%):** То же самое + закреплённый чеклист онбординга:
-  - Шаг 1: Включить AI для первой встречи 1:1 (кнопка)
-  - Шаг 2: Просмотреть сгенерированное резюме + утвердить
-  - Шаг 3: Проверить извлечённые пункты действий перед следующей встречей 1:1
-
-Чеклист остаётся в дашборде менеджера до завершения всех 3 шагов или ручного скрытия.
-
-## Рандомизация
-
-- **Единица:** Уровень аккаунта (не уровень пользователя — один аккаунт получает один вариант для всех менеджеров)
-  - Обоснование: B2B-последовательность — HR-администратор не должен видеть разный онбординг для разных команд
-- **Сид:** SHA256 от account_id — детерминированный, переназначаемый
-- **Распределение:** 50/50
-- **Допустимость:** Аккаунты, активирующие AI тариф с 8 июля (дата начала теста)
-
-## Контрольные метрики
-
-| Метрика | Базовый уровень | Порог | Мониторинг |
-|--------|:--------:|:---------:|:----------:|
-| Валовой коэффициент оттока (AI tier аккаунты) | 3% / 90 дней | ≤ 4% | Еженедельно |
-| NPS (в AI тарифе) | 50 | ≥ 47 | Двухнедельный опрос |
-| Тикеты поддержки «путаница при онбординге» | <2% от общего | <3% | Ежедневная проверка |
-| NPS менеджеров по AI функции | 52 | ≥ 48 | Ежемесячный опрос внутри продукта |
-
-**При нарушении любой контрольной метрики:** приостановить эксперимент, расследовать, потенциально завершить.
-
-## Сегментный анализ (предзарегистрированный)
-
-Ожидаемый дифференциальный прирост:
-- **Размер компании:** Ожидается наибольший прирост у SMB (менее опытные менеджеры) > mid-market > enterprise (уже имеют программы обучения)
-- **Опыт менеджера:** Ожидается наибольший прирост у новых менеджеров (<2 лет)
-- **Отрасль:** Технологические компании — первопроходцы — ожидается наибольший базовый уровень + умеренный прирост
-
-Анализ будет представлен **как** в целом, **так и** по сегментам. Никаких cherry-picking сегментов постфактум.
-
-## Статистический метод
-
-- **Частотный, Z-тест для долей** (стандарт для A/B по коэффициенту принятия)
-- α = 0.05 двусторонний
-- Мощность = 0.80
-- Без промежуточных просмотров до запланированной продолжительности (18 недель)
-- Сегментный анализ — коррекция множественных сравнений (Бонферрони): α / 3 сегмента = 0.017
-
-## Критическая область / Правила остановки
-
-### Успех (Выкатить на всех)
-- Основная метрика: прирост теста ≥ 7pp, значим при α=0.05
-- Нет нарушений контрольных метрик
-- Выполнено ≥ 16 недель
-
-### Провал (Остановить — убрать вариант)
-- Основная метрика: абсолютная разница < 3pp после достижения 50% выборки
-- ИЛИ нарушение контрольной метрики
-
-### Расширенное наблюдение (продолжить)
-- Основная метрика: наблюдается 3-7pp, незначимо → продолжить до запланированной продолжительности
-
-### Ранний положительный сигнал (без остановки)
-- Основная метрика: 8pp+ наблюдается при 25% выборки, значимо
-- Действие: НЕ останавливать раньше времени — продолжать, следить за неоднородностью
-
-## Предзарегистрированный план анализа
-
-Опубликован во внутренней wiki до начала эксперимента:
-
-1. Основная метрика: 30-дневный еженедельный коэффициент принятия, Z-тест, α=0.05
-2. Проверки контрольных метрик: еженедельные автоматические оповещения
-3. Сегментный анализ: по размеру компании, опыту менеджера, отрасли (коррекция Бонферрони)
-4. Правила интерпретации: зафиксированы выше
-5. Отчётность: еженедельный дашборд, формальный отчёт на неделях 8, 16, 18
-
-## План реализации
-
-### До запуска
-- [ ] Флаг функции настроен (уровень аккаунта, детерминированный)
-- [ ] Тестовый вариант собран + прошёл QA
-- [ ] Инструментирование: событие `onboarding_checklist_step_completed`, `onboarding_checklist_dismissed`
-- [ ] Аналитический дашборд работает (автообновление еженедельно)
-- [ ] Контрольный вариант верифицирован как неизменный относительно продакшна
-
-### Во время
-- **Еженедельный обзор** (понедельник 10:00): проверка накопления выборки, контрольных метрик, без промежуточного анализа
-- **Двухнедельный опрос:** 20 случайных менеджеров из каждого варианта — качественный сигнал
-- **Реагирование на инциденты:** при нарушении контрольной метрики — приостановить в течение 24 часов
-
-### После (при успехе)
-- Полная выкатка — удалить флаг функции
-- Чеклист становится частью стандартного онбординга
-- Задокументировать обоснование решения для будущих итераций
-
-### После (при провале)
-- Вариант убирается
-- Качественный анализ причин — интервью с менеджерами, которые завершили / не завершили чеклист
-- Проектирование следующего эксперимента (например, другой подход к онбордингу)
-
-## Открытые вопросы
-
-1. Показываем ли вариант существующим неактивированным менеджерам в AI-tier аккаунтах? (**Решение:** Нет, только новые активации с 8 июля — более чистый базовый уровень)
-2. Что насчёт менеджеров в аккаунтах, которые активируются В ХОДЕ эксперимента, но ВЕСЬ вариант различается? (**Решение:** Следовать назначению аккаунта — если аккаунт тестовый, все новые менеджеры видят чеклист)
-3. Бонферрони vs альтернативная коррекция множественных сравнений? (**Решение:** Бонферрони — консервативный, проще объяснить)
-```
-
-> **Урок дизайна A/B:** Расчёт размера выборки показал, что MDE пришлось **повысить**, без сокращений. **18 недель** — это реальное обязательство — не фиктивный «2-недельный» тест, который читает шум. **Рандомизация на уровне аккаунта** критична в B2B — уровень пользователя привёл бы к тому, что одна команда разделилась по вариантам = недействительно. **Предзарегистрированный план анализа** во внутренней wiki предотвращает HARKing (выдвижение гипотез после получения результатов). **Контрольные метрики с числовыми порогами** — без них происходят рационализации «отток немного вырос, но функция выиграла». Этот тест — честная наука — занимает месяцы, проверяет одно чисто.
+---
+name: ab-test-design
+description: Дизайн A/B-теста — primary metric, MDE, sample size, duration, guardrails, critical region
+type: triggered
+domain: product
+owners:
+  - data_analyst
+gates:
+  - DATA_ANALYST
+tech: []
+topic: []
+triggers:
+  - "ab-test-design"
+  - "A/B test"
+  - "сплит-тест"
+  - "experiment design"
+related: []
+budget_lines: 428
+schema_version: 1
+---
+# A/B Test Design
+
+> **Категория:** Experimentation  ·  **Slug:** `ab-test-design`
+
+## Когда использовать
+
+- Для валидации гипотезы с количественным сигналом.
+- При выкатке высокорискованных изменений (ценообразование, онбординг, ключевой поток).
+- Для сравнения альтернатив, когда доказательства неясны.
+- При измерении влияния функции для критериев успеха PRD.
+
+## Вход
+
+| Поле | Обязательно | Описание |
+|------|:-----------:|----------|
+| Hypothesis | ✅ | Через `$hypothesis-template` |
+| Primary metric | ✅ | Что измеряем |
+| Baseline metric value | ✅ | Текущее среднее + дисперсия |
+| Expected effect size | ✅ | MDE — минимальный обнаруживаемый эффект |
+| Traffic / eligible users | ✅ | Недельная подходящая выборка |
+| Infrastructure | ✅ | Флаги функций / платформа экспериментов |
+
+## Источники данных
+
+1. Исторические данные метрики — базовый уровень + дисперсия.
+2. `$hypothesis-template` — ожидаемое направление + величина.
+3. Пользовательская аналитика — подходящая аудитория.
+4. Отраслевые бенчмарки — типичные размеры эффектов.
+
+### Связь с другими скилами
+
+| Скил | Что берём | Когда вызывать |
+|------|-----------|----------------|
+| `hypothesis-template` | Что тестируем | Предусловие |
+| `saas-metrics` | Основные + контрольные метрики | Для выбора |
+| `aarrr-metrics` | Контекст воронки | Для понимания |
+| `assumption-mapping` | Высокорискованное допущение → A/B | Для топ-допущений |
+
+## Протокол
+
+### Шаг 0 — Подходит ли A/B?
+
+Чеклист:
+- Достаточно трафика (≥ 1000 пользователей / неделю на вариант)?
+- Метрика поддаётся инструментированию + обнаружима в рамках временного горизонта?
+- Изменение изолируемо (не запутано с другими выкатками)?
+- Допустимо ли A/B тестирование (не критическая безопасность / соответствие)?
+
+Если нет — альтернативы: поэтапная выкатка с когортным сравнением, до/после, качественное тестирование.
+
+### Шаг 1 — Основная метрика
+
+Единственная основная метрика. Не несколько («Влияние на activation И retention»).
+
+Типичные варианты:
+- **Activation:** 7-дневный коэффициент активации
+- **Retention:** активность неделя/неделю, отток
+- **Conversion:** signup → paid, trial → active
+- **Engagement:** действий за сессию, DAU/MAU
+
+Свойства:
+- **Обнаружима** в разумном размере выборки
+- **Согласована** с ожидаемым результатом гипотезы
+- **Чувствительна** — реагирует, когда происходит ожидаемое изменение
+- **Достоверна** — сложно поддаётся манипуляции
+
+### Шаг 2 — Минимальный обнаруживаемый эффект (MDE)
+
+MDE — наименьший прирост, который стоит обнаруживать. Компромисс:
+- Меньший MDE = нужна большая выборка = более долгий тест
+- Больший MDE = более быстрый тест, но можно пропустить небольшие улучшения
+
+Практические правила:
+- Метрики активации: MDE 3-5% (пп)
+- Метрики конверсии: MDE 5-10% (пп) относительный прирост
+- Метрики удержания: MDE 2-4% (пп)
+
+В B2B: меньшие выборки → MDE чаще 5-10% минимум.
+
+### Шаг 3 — Расчёт размера выборки
+
+Формула для тестов долей:
+```
+n на вариант = (Z_α/2 + Z_β)² × 2 × p(1-p) / MDE²
+```
+
+Где:
+- Z_α/2 = 1.96 (95% доверительный интервал)
+- Z_β = 0.84 (80% мощность)
+- p = базовый коэффициент
+- MDE = минимальный обнаруживаемый эффект
+
+Для непрерывных метрик — аналогичная формула с дисперсией.
+
+**Использовать калькулятор:** онлайн-инструменты (Evan Miller, калькулятор Optimizely) — не рассчитывать вручную.
+
+### Шаг 4 — Продолжительность
+
+Продолжительность = размер_выборки × варианты / еженедельные_подходящие_пользователи.
+
+Умножить:
+- На 1.5-2× для недельной цикличности (будни vs выходные)
+- Для B2B: минимум 2 недели (полный недельный цикл)
+- Максимум: 6-8 недель (сверх этого — контекст меняется, сезонность)
+
+### Шаг 5 — Рандомизация
+
+- **Единица:** уровень пользователя или аккаунта (B2B: обычно уровень аккаунта, чтобы избежать раздвоения в команде)
+- **Сид:** случайный, но детерминированный (один и тот же пользователь получает тот же вариант при повторном посещении)
+- **Распределение:** 50/50 по умолчанию, можно 80/20 (упор на контроль) для рискованных изменений
+
+### Шаг 6 — Контрольные метрики
+
+Метрики, которые не должны деградировать:
+- Коэффициент оттока
+- NPS / CSAT
+- Объём обращений в поддержку
+- Задержка p95 / коэффициент ошибок
+- Выручка / пользователь
+
+Установить пороги (например, «отток не может расти >1pp»).
+
+### Шаг 7 — План сегментного анализа
+
+Предзарегистрировать (не p-hacking после):
+- По размеру компании
+- По стажу (новые vs давние)
+- По роли
+- По географии (если актуально)
+
+Задокументировать в плане теста, а не после результатов.
+
+### Шаг 8 — Статистический метод
+
+- **Частотный** (наиболее распространённый): p-value < 0.05, мощность 80%
+- **Байесовский:** апостериорная вероятность улучшения > 95%
+
+Выбрать один. Задокументировать.
+
+### Шаг 9 — Критическая область / Правила остановки
+
+Когда остановить тест:
+- **Успех** — достигнута значимость, остановить
+- **Провал (бесполезность):** минимальный эффект после N% выборки, остановить
+- **Нарушение контрольной метрики:** даже если основная метрика выигрывает, остановить
+- **Лимит времени:** достигнута максимальная продолжительность
+
+**НИКОГДА не подглядывать раньше времени** и останавливать по p-value (увеличивает долю ложноположительных результатов) без последовательного дизайна тестирования.
+
+### Шаг 10 — Предзарегистрированный план анализа
+
+Задокументировать ДО запуска теста:
+- Основная метрика + MDE + размер выборки
+- Сегменты
+- Контрольные метрики
+- Критерии остановки
+- Правила интерпретации
+
+Позволяет избежать HARKing (Hypothesizing After Results Known — выдвижение гипотез после получения результатов).
+
+## Валидация (Quality Gate)
+
+- [ ] A/B подходит (трафик, изоляция, допустимость)
+- [ ] Основная метрика единственная + чётко определена
+- [ ] Обоснование MDE (бизнес + обнаружимость)
+- [ ] Рассчитан размер выборки
+- [ ] Продолжительность ≥ 2 недель, ≤ 8 недель
+- [ ] Единица рандомизации подходящая (пользователь / аккаунт)
+- [ ] Контрольные метрики с порогами
+- [ ] Сегментный анализ предзарегистрирован
+- [ ] Статистический метод выбран + обоснован
+- [ ] Правила остановки явны
+- [ ] Предзарегистрированный план анализа
+
+## Handoff
+
+Результат является входом для:
+- **Engineering** → флаг функции + инструментирование
+- **Data Analyst** → дашборд мониторинга
+- **PM** → критерии запуска
+- **Stakeholders** → еженедельные отчёты
+
+Формат: документ дизайна A/B теста (markdown). Через `$handoff`.
+
+## Anti-patterns
+
+| Ошибка | Почему плохо | Как правильно |
+|--------|-------------|---------------|
+| Несколько основных метрик | Раздувание p-value | Единственная основная |
+| Подглядывание + ранняя остановка | Ложноположительный результат | Последовательный или фиксированная продолжительность |
+| Нет обоснования MDE | Недостаточная мощность или слишком долгий тест | Обоснование через бизнес + обнаружимость |
+| Игнорировать контрольные метрики | Функция «выигрывает», ломая другое | Явные контрольные метрики с критериями отключения |
+| Нет предрегистрации | HARKing, p-hacking | Планировать до запуска |
+| Короткая продолжительность | Шум недельного цикла | Минимум 2 недели |
+| Уровень пользователя в B2B потоке | Один аккаунт, разные варианты | Рандомизация на уровне аккаунта |
+
+## Шаблон
+
+```markdown
+# A/B Test: [Название]
+
+## Гипотеза
+[через $hypothesis-template]
+
+## Основная метрика
+- Метрика: [например, 7-дневный коэффициент активации]
+- Базовый уровень: X% (последние 30 дней)
+- MDE: +5pp (обоснование: бизнес-потребность + поддержка выборки)
+
+## Выборка и продолжительность
+- Подходящих пользователей / неделю: Y
+- Выборка на вариант: Z
+- Рассчитанная продолжительность: N недель
+- Запланированная продолжительность: N недель (с учётом цикличности)
+
+## Варианты
+- Контроль: текущий поток
+- Тест: [изменение]
+- Распределение: 50/50
+- Рандомизация: уровень аккаунта, детерминированная
+
+## Контрольные метрики
+| Метрика | Текущий | Порог |
+| Коэффициент оттока | 2% | < 2.5% |
+| NPS | 45 | ≥ 43 |
+| Задержка p95 | 180ms | < 200ms |
+
+## Предзарегистрированный анализ
+- Сегменты: размер компании, роль пользователя
+- Статистический метод: частотный, α=0.05, мощность=0.8
+- Критерии выкатки: основная метрика +MDE значима, нет нарушений контрольных метрик
+
+## Правила остановки
+- Успех: достигнута значимость + контрольные метрики в норме → выкатить
+- Провал: эффект < MDE при 50%+ выборки → отклонить
+- Контрольная метрика: нарушена любая → остановить, расследовать
+- Максимальная продолжительность: 8 недель
+```
+
+## Worked Example — TeamFlow Onboarding A/B Test (Post-MVP Iteration)
+
+**Контекст:** AI Summarization MVP выкачен. 30 дней спустя, гипотеза H-003 (принятие) отслеживает 42% принятия — ниже цели 60%. Data Analyst проектирует A/B тест чеклиста онбординга vs контроль для итерации.
+
+```markdown
+# A/B Test Design: Onboarding Checklist for New AI Tier Managers
+
+**Experiment ID:** EXP-025
+**Статус:** Утверждён, запуск 8 июля 2026
+**Владелец:** Sam P. (Data) + Alex K. (PM) + Jordan M. (Design)
+**Гипотеза:** Итерация 1 гипотезы H-003
+
+## Гипотеза (переформулирована для теста)
+
+**Мы считаем**, что предоставление чеклиста онбординга («Выполните 3 шага, чтобы освоить AI-резюме»)
+**Для** менеджеров, только что активированных в AI-tier аккаунтах,
+**Приведёт к** более высокому 30-дневному еженедельному коэффициенту принятия
+**Мы узнаем, что это правда, когда** 30-дневный коэффициент принятия в тестовой группе будет на ≥5pp выше, чем в контрольной
+**Потому что:**
+  - Открытие удивило: 60% не принявших указали «не знал с чего начать» в опросе после запуска
+  - Чеклисты онбординга в существующих функциях TeamFlow показывают прирост активации +22% (внутренний бенчмарк)
+  - 7-дневное окно первой активации предсказывает долгосрочное удержание (когортный анализ Q1)
+
+## Основная метрика
+
+- **Метрика:** 30-дневный еженедельный коэффициент принятия (% только что активированных менеджеров, использовавших AI-резюме ≥1 раза в неделю в недели 2-4 после активации)
+- **Базовый уровень:** 42% (текущий, измерен за последние 30 дней выкатки AI тарифа)
+- **MDE:** +5pp (цель: 47% тест vs 42% контроль)
+- **Обоснование MDE:**
+  - Бизнес-порог: +5pp × ~200 новых менеджеров/месяц = 10 дополнительно удержанных менеджеров/месяц = $2.4K MRR
+  - Обнаружим с разумной выборкой (см. расчёт размера выборки)
+  - Ниже 5pp несущественно для решения на уровне PM
+
+## Расчёт размера выборки
+
+Используя формулу для теста долей:
+- Базовый уровень p1 = 0.42
+- Тест p2 = 0.47 (цель)
+- α = 0.05 (двусторонний)
+- Мощность = 0.80
+- Z_α/2 = 1.96, Z_β = 0.84
+
+n на вариант = 2 × (1.96 + 0.84)² × [0.42(0.58) + 0.47(0.53)] / (0.05)² 
+             ≈ 2 × 7.84 × 0.493 / 0.0025
+             ≈ 3092
+
+**Выборка на вариант: ~3100**
+**Итоговая выборка: 6200**
+
+## Продолжительность
+
+- Еженедельно активирующихся менеджеров в AI тарифе: ~200/неделю
+- Продолжительность: 6200 / 200 = **31 неделя**
+
+**Проблема:** 31 неделя — неразумно долго. Варианты:
+1. **Поднять MDE до 7pp** (цель 49%) — продолжительность сократится до ~16 недель
+2. **Увеличить распределение до 80/20** — больше веса на тест, но ускорения нет
+3. **Принять увеличенный горизонт** с еженедельным мониторингом для раннего сигнала
+
+**Решение:** Поднять MDE до 7pp (цель 49%). Обоснование с точки зрения бизнеса — 7pp × 200 менеджеров = 14 менеджеров/месяц сохранено, существенно.
+
+**Пересмотренная продолжительность: 16 недель.** Плюс буфер на цикличность: итого 18 недель.
+
+## Варианты
+
+- **Контроль (50%):** Текущий опыт — менеджер активирует тариф, видит стандартный онбординг TeamFlow, без чеклиста
+- **Тест (50%):** То же самое + закреплённый чеклист онбординга:
+  - Шаг 1: Включить AI для первой встречи 1:1 (кнопка)
+  - Шаг 2: Просмотреть сгенерированное резюме + утвердить
+  - Шаг 3: Проверить извлечённые пункты действий перед следующей встречей 1:1
+
+Чеклист остаётся в дашборде менеджера до завершения всех 3 шагов или ручного скрытия.
+
+## Рандомизация
+
+- **Единица:** Уровень аккаунта (не уровень пользователя — один аккаунт получает один вариант для всех менеджеров)
+  - Обоснование: B2B-последовательность — HR-администратор не должен видеть разный онбординг для разных команд
+- **Сид:** SHA256 от account_id — детерминированный, переназначаемый
+- **Распределение:** 50/50
+- **Допустимость:** Аккаунты, активирующие AI тариф с 8 июля (дата начала теста)
+
+## Контрольные метрики
+
+| Метрика | Базовый уровень | Порог | Мониторинг |
+|--------|:--------:|:---------:|:----------:|
+| Валовой коэффициент оттока (AI tier аккаунты) | 3% / 90 дней | ≤ 4% | Еженедельно |
+| NPS (в AI тарифе) | 50 | ≥ 47 | Двухнедельный опрос |
+| Тикеты поддержки «путаница при онбординге» | <2% от общего | <3% | Ежедневная проверка |
+| NPS менеджеров по AI функции | 52 | ≥ 48 | Ежемесячный опрос внутри продукта |
+
+**При нарушении любой контрольной метрики:** приостановить эксперимент, расследовать, потенциально завершить.
+
+## Сегментный анализ (предзарегистрированный)
+
+Ожидаемый дифференциальный прирост:
+- **Размер компании:** Ожидается наибольший прирост у SMB (менее опытные менеджеры) > mid-market > enterprise (уже имеют программы обучения)
+- **Опыт менеджера:** Ожидается наибольший прирост у новых менеджеров (<2 лет)
+- **Отрасль:** Технологические компании — первопроходцы — ожидается наибольший базовый уровень + умеренный прирост
+
+Анализ будет представлен **как** в целом, **так и** по сегментам. Никаких cherry-picking сегментов постфактум.
+
+## Статистический метод
+
+- **Частотный, Z-тест для долей** (стандарт для A/B по коэффициенту принятия)
+- α = 0.05 двусторонний
+- Мощность = 0.80
+- Без промежуточных просмотров до запланированной продолжительности (18 недель)
+- Сегментный анализ — коррекция множественных сравнений (Бонферрони): α / 3 сегмента = 0.017
+
+## Критическая область / Правила остановки
+
+### Успех (Выкатить на всех)
+- Основная метрика: прирост теста ≥ 7pp, значим при α=0.05
+- Нет нарушений контрольных метрик
+- Выполнено ≥ 16 недель
+
+### Провал (Остановить — убрать вариант)
+- Основная метрика: абсолютная разница < 3pp после достижения 50% выборки
+- ИЛИ нарушение контрольной метрики
+
+### Расширенное наблюдение (продолжить)
+- Основная метрика: наблюдается 3-7pp, незначимо → продолжить до запланированной продолжительности
+
+### Ранний положительный сигнал (без остановки)
+- Основная метрика: 8pp+ наблюдается при 25% выборки, значимо
+- Действие: НЕ останавливать раньше времени — продолжать, следить за неоднородностью
+
+## Предзарегистрированный план анализа
+
+Опубликован во внутренней wiki до начала эксперимента:
+
+1. Основная метрика: 30-дневный еженедельный коэффициент принятия, Z-тест, α=0.05
+2. Проверки контрольных метрик: еженедельные автоматические оповещения
+3. Сегментный анализ: по размеру компании, опыту менеджера, отрасли (коррекция Бонферрони)
+4. Правила интерпретации: зафиксированы выше
+5. Отчётность: еженедельный дашборд, формальный отчёт на неделях 8, 16, 18
+
+## План реализации
+
+### До запуска
+- [ ] Флаг функции настроен (уровень аккаунта, детерминированный)
+- [ ] Тестовый вариант собран + прошёл QA
+- [ ] Инструментирование: событие `onboarding_checklist_step_completed`, `onboarding_checklist_dismissed`
+- [ ] Аналитический дашборд работает (автообновление еженедельно)
+- [ ] Контрольный вариант верифицирован как неизменный относительно продакшна
+
+### Во время
+- **Еженедельный обзор** (понедельник 10:00): проверка накопления выборки, контрольных метрик, без промежуточного анализа
+- **Двухнедельный опрос:** 20 случайных менеджеров из каждого варианта — качественный сигнал
+- **Реагирование на инциденты:** при нарушении контрольной метрики — приостановить в течение 24 часов
+
+### После (при успехе)
+- Полная выкатка — удалить флаг функции
+- Чеклист становится частью стандартного онбординга
+- Задокументировать обоснование решения для будущих итераций
+
+### После (при провале)
+- Вариант убирается
+- Качественный анализ причин — интервью с менеджерами, которые завершили / не завершили чеклист
+- Проектирование следующего эксперимента (например, другой подход к онбордингу)
+
+## Открытые вопросы
+
+1. Показываем ли вариант существующим неактивированным менеджерам в AI-tier аккаунтах? (**Решение:** Нет, только новые активации с 8 июля — более чистый базовый уровень)
+2. Что насчёт менеджеров в аккаунтах, которые активируются В ХОДЕ эксперимента, но ВЕСЬ вариант различается? (**Решение:** Следовать назначению аккаунта — если аккаунт тестовый, все новые менеджеры видят чеклист)
+3. Бонферрони vs альтернативная коррекция множественных сравнений? (**Решение:** Бонферрони — консервативный, проще объяснить)
+```
+
+> **Урок дизайна A/B:** Расчёт размера выборки показал, что MDE пришлось **повысить**, без сокращений. **18 недель** — это реальное обязательство — не фиктивный «2-недельный» тест, который читает шум. **Рандомизация на уровне аккаунта** критична в B2B — уровень пользователя привёл бы к тому, что одна команда разделилась по вариантам = недействительно. **Предзарегистрированный план анализа** во внутренней wiki предотвращает HARKing (выдвижение гипотез после получения результатов). **Контрольные метрики с числовыми порогами** — без них происходят рационализации «отток немного вырос, но функция выиграла». Этот тест — честная наука — занимает месяцы, проверяет одно чисто.