Что нужно сделать перед запуском теста?

Checklist: Что нужно сделать ДО запуска A/B теста

Фаза 1: Planning (День 1)

1.1 Определить hypothesis

Структура:

IF [изменение]
THEN [ожидаемый результат]
BECAUSE [механизм]

Пример: IF мы изменим кнопку с "Купить" на "Попробовать" THEN конверсия вырастет на 10% BECAUSE слово "попробовать" less scary для новых пользователей

Проверка:

• Hypothesis ясна? (можешь объяснить 5-летнему?)
• Гипотеза based на insights? (не случайная идея)
• Есть ли prior evidence? (успешно ли работало в других местах?)

1.2 Выбрать primary metric

Критерии:

• Actionable: можешь что-то сделать
• Measurable: можешь точно посчитать
• Relevant: связано с бизнес goal

Примеры:

Хорошо:
- Conversion rate: (buyers / visitors)
- Revenue per user
- Days until repeat purchase

Плохо:
- Page views (vanity)
- Average session length (может быть они confused)
- Click-through rate без follow-up

1.3 Определить secondary metrics (что ещё важно?)

Что может сломаться?

Примеры:

Testing: Green button for CTA
Primary: Conversion rate
Secondary:
  - Bounce rate (not increase)
  - Time on page (should decrease)
  - Cart abandonment (should decrease)

Если primary метрик вверх но secondary вниз → можно не запускать.

1.4 Оценить baseline

Что это? Текущее значение метрики.

SELECT 
  COUNT(DISTINCT CASE WHEN purchased = 1 THEN user_id END) as purchases,
  COUNT(DISTINCT user_id) as users,
  ROUND(100.0 * COUNT(DISTINCT CASE WHEN purchased = 1 THEN user_id END) / COUNT(DISTINCT user_id), 2) as baseline_conversion
FROM users
WHERE visit_date >= DATE_SUB(CURDATE(), INTERVAL 30 DAY);

Зачем? Без baseline, не знаешь как считать sample size и статистическую мощность.

Фаза 2: Calculation (День 1-2)

2.1 Определить Minimum Detectable Effect (MDE)

Вопрос: Какой smallest улучшение тебе интересует?

Примеры:

Baseline: 10% conversion
Testing: Green button

Option A: Interested в +0.5% (10% → 10.5%)
Option B: Interested в +1% (10% → 11%)
Option C: Interested в +2% (10% → 12%)

Оptions меньше MDE требует bigger sample size

Как выбрать MDE:

• Business perspective: Какой improvement стоит invest?
  • Если +0.5% = $100K/год → important
  • Если +0.5% = $10K/год → probably not worth

Recommendation: Start with 20% relative lift (или какой business требует)

2.2 Рассчитать sample size

from scipy.stats import norm

def calculate_sample_size(baseline, mde, alpha=0.05, power=0.80):
    z_alpha = norm.ppf(1 - alpha/2)
    z_beta = norm.ppf(power)
    
    p = baseline / 100  # convert % to proportion
    effect = mde / 100
    
    n = 2 * ((z_alpha + z_beta) / effect) ** 2 * p * (1 - p)
    return int(n)

# Пример
baseline_conversion = 10  # 10%
mde = 2  # want to detect 2% improvement (10% → 12%)

n = calculate_sample_size(baseline_conversion, mde)
print(f"Need {n:,} users per variant")  # ~5,000 per variant

2.3 Оценить sample availability

Вопрос: Есть ли достаточно трафика?

Daily traffic: 10,000 users
Needed per variant: 5,000 users
Experiment duration: 5,000 / (10,000 / 2) = 1 day

✅ OK, test можно запустить за 1 день

Esли нужно 100K users и ежедневно только 1K:

Days needed: 100,000 / 1,000 = 100 days

❌ Слишком долго, нужно increase MDE (detectим bigger effect)

2.4 Проверить предыдущие tests

Вопрос: Тестировали ли это раньше?

-- Query для проверки истории
SELECT 
  test_name,
  metric_changed,
  effect_size,
  p_value,
  result
FROM ab_test_history
WHERE test_name LIKE '%button%color%'
ORDER BY test_date DESC;

Eсли уже тестировали и результат negative → skip. Esли уже работало в другом варианте → maybe combine?

Фаза 3: Implementation Planning (День 2-3)

3.1 Подготовить design doc

# A/B Test: [Name]

## Objective
[1-sentence goal]

## Hypothesis
IF [change] THEN [metric] increases BECAUSE [mechanism]

## Variants
- Control: [current state]
- Treatment: [proposed state]

## Metrics
- Primary: [metric] baseline=[X]%, target=[X+delta]%
- Secondary: [metric2], [metric3]

## Sample Size
- Needed: [N] per variant
- Duration: [Days]
- Traffic check: [OK/NOT OK]

## Implementation
- Where: [page/feature]
- Who: [engineer name]
- By: [date]

## Analysis Plan
- Method: Chi-square (for binary), t-test (for continuous)
- Significance level: 0.05
- Check date: [date]

3.2 Определить randomization strategy

Вариант 1: Random split (50/50)

IF random() < 0.5 THEN Control
ELSE Treatment

Плюсы: Simple Минусы: Can have imbalance at start

Вариант 2: Stratified randomization

IF user.country == 'US' THEN:
  IF random() < 0.5 THEN Control
  ELSE Treatment

Плюсы: Balanced by segment Минусы: More complex

Вариант 3: Bucketing (consistent user experience)

Variant = MD5(user_id) % 2
IF Variant == 0 THEN Control
ELSE Treatment

Плюсы: Same user always gets same variant Минусы: Harder to change assignment

Recommendation: Вариант 3 для consistency

3.3 Подготовить tracking

Что нужно логировать:

{
  "event_type": "test_assigned",
  "user_id": "user_123",
  "test_id": "button_color_test",
  "variant": "treatment",
  "timestamp": "2024-01-15T10:30:00Z"
}

Потом:

{
  "event_type": "purchase",
  "user_id": "user_123",
  "test_id": "button_color_test",
  "variant": "treatment",
  "amount": 50,
  "timestamp": "2024-01-15T10:35:00Z"
}

Code review checklist:

• Tracking correct field names?
• Events going to right place?
• No PII logging?
• Performance impact minimal?

Фаза 4: Pre-launch (День 3)

4.1 QA checklist

[ ] Test on staging environment
[ ] Randomization working (check 50/50 split)
[ ] Tracking events firing correctly
[ ] Dashboard updated and showing data
[ ] No errors in logs
[ ] Mobile and desktop both working
[ ] International users handled correctly

4.2 Alert PM и marketing

"Эй, запускаем тест завтра. Сразу могут видеть changes, это нормально."

Иначе они паникуют когда видят something different.

4.3 Подготовить communication plan

Day 0: Launch test
  └─ Slack message: "Test launched, dashboard here"

Day 7: Check results (preliminary)
  └─ "Preliminary results: +2% conversion, not statistically significant yet"

Day 14: Final results
  └─ "Test complete. Recommendation: LAUNCH / KILL / EXTEND"

Фаза 5: Launch (День 4+)

5.1 Запустить тест

1. Engineer deploys code
2. Verify: tracking events firing
3. Monitor: no errors/crashes
4. Slack notification: "Test is live!"

5.2 Monitor первые часы

-- Check every 1 hour for first 8 hours
SELECT 
  variant,
  COUNT(DISTINCT user_id) as users,
  COUNT(DISTINCT CASE WHEN purchased = 1 THEN user_id END) as purchases
FROM test_events
WHERE test_id = 'button_color'
AND timestamp >= NOW() - INTERVAL 1 HOUR
GROUP BY variant;

Eсли что-то странное (например 0 events) → investigate immediately!

My pre-launch checklist (один файл)

❑ Hypothesis clear & documented
❑ Baseline metric calculated
❑ Sample size calculated
❑ Traffic available for that size
❑ Primary & secondary metrics defined
❑ Design doc written & reviewed
❑ Tracking code written & reviewed
❑ QA on staging environment
❑ Dashboard created & tested
❑ Alerts set up
❑ PM & stakeholders notified
❑ Communication plan ready
❑ Engineer ready to deploy
❑ Analysis plan documented

If all ✅ → GO LIVE
If any ❌ → FIX FIRST

Biggest mistakes I see

❌ "Let's just launch and see what happens" → Без proper planning, можешь потратить неделю на wrong hypothesis

❌ "We'll analyze results after test ends" → Setup monitoring BEFORE launch

❌ "Sample size? Who cares" → Wrong sample size = неправильные conclusions

❌ "Tracking is complex, let's skip it" → Без tracking, test бесполезный

✅ Правильный подход: Plan → Calculate → Implement → Launch → Monitor → Analyze