Какие основные этапы должны быть при проектировании эксперимента?

Основные этапы проектирования эксперимента

Проектирование экспериментов (A/B тестов) — фундаментальный навык Product Manager. Хорошо спроектированный эксперимент даёт достоверные данные, которые исключают предубеждения и проверяют гипотезы перед масштабными инвестициями в разработку.

1. Постановка гипотезы и цели

Формулирование чёткой гипотезы

Этап начинается с вопроса: что именно мы хотим проверить? Гипотеза должна быть:

• Конкретной: не "улучшить конверсию", а "изменение цвета кнопки с синего на зелёный повысит CTR на 15%"
• Основана на данных: предыдущие метрики, фидбек пользователей, анализ конкурентов
• Измеримой: связана с конкретной метрикой (конверсия, время на странице, retention)

Определение первичной метрики

Это главный KPI, который мы изменяем. Например:

• Для checkout-потока: % конверсии в покупку
• Для контента: engagement (лайки, комментарии, время прочтения)
• Для onboarding: % активных пользователей на День 7

2. Дизайн эксперимента

Выбор типа теста

• A/B тест: две версии, 50/50 трафика
• Multivariate тест: несколько переменных одновременно (сложнее, нужно больше трафика)
• Split test: разные пользовательские сегменты видят разные версии (например, по географии)

Определение сегмента

Кому мы показываем эксперимент?

• Всем пользователям или конкретному сегменту (новые, платящие, мобильная аудитория)?
• Важно, чтобы две группы (контроль и вариант) были статистически идентичны по профилю

Размер выборки

Это критично. Используем статистическую мощность (power analysis):

• Minimum detectable effect (MDE): какой минимальный прирост нас интересует? (5%, 10%, 15%?)
• Baseline conversion rate: текущая конверсия
• Statistical power: обычно 80% (риск false negative — 20%)
• Significance level: 95% (риск false positive — 5%)

Онлайн-калькуляторы (например, Evan Miller) показывают, сколько пользователей в каждой группе нужно. Например, для увеличения конверсии на 5% при текущей 2% нужно ~10k пользователей в группе.

3. Подготовка и техническая реализация

Координация с командой

• Инженеры: реализуют вариант B, убеждаются, что трафик распределяется корректно (обычно по userID хеш)
• QA: проверяют обе версии на ошибки, особенно логику трекинга событий
• Аналитики: убеждаются, что события правильно логируются в data warehouse

Техдолг и риски

Нужна стабильная техническая база:

• Если вариант вызывает баги, это исказит результаты
• Убедимся, что эксперимент не конфликтует с другими текущими экспериментами
• Проверяем, не влияет ли сезонность на метрики

4. Запуск и мониторинг

Фаза прогрева

• Запускаем на небольшом проценте трафика (5-10%) на 1-2 дня
• Проверяем: не сломалось ли ничего? Распределение равномерно? События логируются?

Основной период

• Масштабируем на запланированный процент трафика
• Не смотрим на результаты слишком рано! ("peeking" вводит bias)
• Мониторим аномалии (скачки трафика, баги,외부 факторы)

Длительность

Обычно 1-4 недели, в зависимости от:

• Размера трафика
• Волатильности метрики (покупки более волатильны, чем клики)
• Нужно ли охватить полный цикл пользователя (например, неделю)

5. Анализ результатов

Статистическая значимость

Экспериментом управляет статистика, не интуиция. Проверяем:

• p-value < 0.05: результат статистически значим (95% уверенность, что это не случайность)
• Доверительный интервал: например, "прирост конверсии 8-12%", а не просто "10%"
• Power analysis: если у нас 80 пользователей вместо 10k, результат может быть false positive

Практическая значимость

Даже если p-value < 0.05, важен размер эффекта:

• Если конверсия выросла на 0.1%, это статистически значимо, но практически неважно
• Если конверсия упала на 5%, это проблема, даже если p-value = 0.06

Анализ подгрупп

Иногда вариант хорошо работает для одного сегмента, но плохо для другого:

• Мобильные vs. десктоп
• Новые vs. вернувшиеся пользователи
• Платящие vs. бесплатные

6. Принятие решения и коммуникация

Три сценария

1. Вариант выиграл: развёртываем на всех пользователей, документируем обучение
2. Нет значимой разницы: отвергаем гипотезу, анализируем почему (может быть, вариант не готов или гипотеза неверна)
3. Вариант проиграл: отвергаем, но документируем инсайт (это тоже ценная информация)

Документирование

Создаём "post-mortem" эксперимента:

• Что мы проверяли и почему
• Результаты и статистическая значимость
• Инсайты: что мы узнали?
• Следующие шаги

Пример из практики

На e-commerce платформе мы тестировали удаление одного этапа при оформлении заказа (с 5 на 4 шага). RICE-анализ показал, что упрощение касается 80% пользователей. A/B тест на 20k пользователей (2 недели) показал рост конверсии на 12% (p-value = 0.02). Результат: развернули для всех, и это прибавило $2M годового дохода.

Ключевой момент: хорошо спроектированный эксперимент — это инвестиция в достоверность решений. Время на планирование экономит месяцы неправильной разработки.