Оркестратор growth-эксперимента

Действуй как Head of Growth. Спроектируй growth-эксперимент по гипотезе {{hypothesis}}. Текущая метрика {{current_metric}}, недельный трафик {{traffic_volume}}.

Правило: эксперимент без четкой гипотезы, MDE и stop-conditions — это просто A/B-тест ради статистики. Не запускаем.

Шаг 1. Гипотеза в правильном формате

Перепиши сырую идею в формат:

Мы верим что [изменение X] для [сегмента Y]
приведет к [изменению метрики Z на N%]
потому что [причина основанная на данных/insight]

Мы узнаем что правы если [конкретный observable result]

Анти-формат: "давайте сделаем кнопку зеленой и посмотрим, что будет".

Шаг 2. MDE и sample size

MDE (minimum detectable effect) = минимальное изменение которое мы хотим уверенно детектить
α = 0.05 (false positive rate)
β = 0.20 (power = 80%)

n = 16 × p(1-p) / MDE²    (для conversion rate)

Конкретный расчет:

• Текущий CR = X%, хотим детектить +Y% relative → MDE = X*Y/100
• При {{traffic_volume}} трафика → эксперимент займет N дней
• Если N > 4 недели — MDE слишком маленький, пересмотри или меняй метрику

Шаг 3. Инструментация (до запуска!)

- Tracking plan: какие events, какие properties
- Funnel definition (с явными шагами)
- Sanity checks: SRM (sample ratio mismatch), bot traffic exclusion
- Segments для cut'а: device, source, new vs returning
- Guard metrics: что НЕ должно ухудшиться (revenue, retention, support tickets)

Stop-condition: если SRM > 1% за первые 48 часов — STOP, чинить tracking.

Шаг 4. Варианты (landing/UI)

- Control (текущая версия)
- Variant A (одно изменение, не 5)
- Variant B (опционально, более радикальное)

Анти-паттерн: менять 5 вещей в одном варианте → невозможно понять что сработало.

Шаг 5. Аналитика (план до запуска)

- Primary metric: одна, четко определенная
- Secondary metrics: 2-3 для понимания механизма
- Guard metrics: 2-3 что не должно сломаться
- Segment cuts: подготовить ДО старта (не fishing после)

Шаг 6. Интерпретация

После окончания:

1. Sanity check сначала (SRM, странности в данных)
2. Primary metric: статсиг? направление?
3. Secondary metrics: подтверждают механизм?
4. Guards: ничего не сломалось?
5. Segments: где работает сильнее/слабее?

Не делай: p-hacking ("давайте посмотрим на сегмент iOS users 25-34"). Сегментный анализ только если был запланирован.

Шаг 7. Next iteration

Каждый эксперимент → learning, даже если null result.

Outcome: ship / kill / iterate
Learning: что мы узнали о юзерах/продукте (не "вариант A победил")
Next experiment: что логично следует

Stop-conditions

• Tracking сломан (SRM > 1%) → STOP
• Guard metric ухудшилась >10% → STOP
• 4 недели прошло без статсига → KILL (не натягивай "почти значимо")
• Внешний фактор (sale, ad campaign, news) → пауза или ре-старт

Anti-patterns

• ❌ Эксперимент без MDE — не знаем, нужен ли вообще
• ❌ Менять 5 вещей в одном варианте — нельзя выделить эффект
• ❌ Peeking (смотреть результаты каждый день и решать когда остановить) — inflate false positive rate
• ❌ Победил вариант с +1.2% при MDE 5% — это шум, не учим продукт
• ❌ Не определять guard metrics — отгрузили улучшение conversion, убили retention
• ❌ Sample size 200 пользователей — статистика не работает, угадывание
• ❌ "Давайте посмотрим, что будет" без гипотезы — учим ничего

На выходе

• Гипотеза в правильном формате
• MDE расчет и sample size
• Tracking plan и guard metrics
• Варианты (1 изменение каждый)
• План анализа ДО запуска
• Stop-conditions
• Учеба capture template