Как выводить продукт на пользователей после A/B теста?

Вывод продукта на пользователей после A/B теста

Очень часто PM думают, что если A/B тест показал +15% конверсию, то нужно сразу roll-out для 100% пользователей. Это опасно. Я использую структурированный подход, чтобы минимизировать риски.

Шаг 1: Анализ результатов теста

Перед тем как выводить, нужно тщательно изучить результаты.

1.1 Основные метрики

Проверю:

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

• Тест работал достаточно долго? (обычно минимум 1-2 недели)
• Размер выборки достаточный? (правило большого пальца: 100+ событий в каждую группу)
• Доверительный интервал не включает 0? (например, +15% ± 5%, а не ±20%)

Пример:

Конверсия в контрольной группе: 5.0%
Конверсия в экспериментальной: 5.75%
Прирост: +15%
Доверительный интервал: 95% (±3%)
P-value: 0.02 (статистически значимо)

→ ХОРОШО: тест валиден

Побочные метрики

• Может ли изменение сломать что-то ещё?
• Например, если добавил фичу для конверсии, но упал DAU—плохо

Проверяю:

• DAU, MAU не упали (или +10% при +15% конверсии—ок)
• Среднее время в приложении не упало (может вырасти—ок)
• Retention на неделю 7 день не упал
• Никаких жалоб в support

Сегментный анализ

• Результат одинаков для новых и старых пользователей?
• Одинаков для мобила и веба?
• Одинаков для разных геозон?
• Одинаков для разных устройств?

Пример:

Основная метрика +15%, но:
- На iOS: +20%
- На Android: +5%
- На планшетах: -10% (красный флаг!)

→ Нельзя выводить для всех, нужно или исправить, или отключить на планшетах

1.2 Качественная обратная связь

Проверю:

• Есть ли жалобы в поддержку?
• Что пишут пользователи в отзывах?
• Упали ли рейтинги приложения?
• Что говорят дизайнеры, разработчики, маркетеры?

Шаг 2: Планирование roll-out

Это не всегда 0% → 100%. Используется гарантийная рамповка (ramping).

2.1 Стратегия рамповки

День 1: 5% пользователей

• Включаю для 5% случайной выборки
• Жду 24 часа
• Проверяю метрики каждый час в первые 3 часа, потом каждые 6 часов
• Ищу критические проблемы (крахи, баги, резкие падения метрик)

День 2-3: 25% пользователей

• Если День 1 ок, расширяю до 25%
• Жду ещё 24 часа
• Проверяю каждые 12 часов

День 4-5: 50% пользователей

• Если День 2-3 ок, расширяю до половины
• Жду ещё 24 часа
• Проверяю каждые 24 часа

День 6+: 100% пользователей

• Если 50% выглядит ок, roll-out для всех
• Жду ещё 24 часа для финального чека

Общее время: 1 неделя.

2.2 Метрики для мониторинга

Во время рамповки смотрю на:

2.3 На-case: что произойдёт

Сценарий A: Всё хорошо → Продолжаю рамповку согласно плану → В конце недели 100% roll-out

Сценарий B: Метрики упали, но не критично → Жду ещё день, проверяю, может это noise → Если не восстановилось: откат и разбираюсь → Может быть бага, может быть в тесте проблема

Сценарий C: Критическая проблема (крахи, DAU упал на 15%) → Откат на 0% за минуты → Не жду, не проверяю—просто откатываюсь → Потом разбираюсь, что случилось

Сценарий D: Результаты в разных сегментах разные → Может быть, выводить только для части пользователей → Например, рамповка только для iOS, пока не исправим Android версию

Шаг 3: Инструменты и автоматизация

Я не вручную переключаю проценты. Используется:

Feature flags (LaunchDarkly, Unleash, Firebase Remote Config):

// В коде
if (featureFlags.isEnabled('new_checkout')) {
  // Новый checkout
} else {
  // Старый checkout
}

// В админ-панели просто меняю процент: 5% → 25% → 50% → 100%

Мониторинг и алерты (Grafana, DataDog):

Если conversion_rate упала на 10% за 1 час → Slack алерт
Если crash_rate > 0.2% → SMS алерт (критическо)
Если DAU упал на 15% → Email мне

Данные в реальном времени (дашборд, который я смотрю):

• Основная метрика сейчас vs. неделю назад
• Крахи и ошибки за последний час
• Количество пользователей в эксперименте
• Сегментный анализ (iOS vs. Android, новые vs. старые)

Шаг 4: Коммуникация

В процессе рамповки держу команду в курсе:

Перед началом (день до):

• Slack-сообщение: "Завтра начинаем рамповку фичи X. Метрики для мониторинга: Y. Откат за 15 минут если Z."

День 1:

• Час 1-3: проверяю каждый час, пишу в Slack
• День 2: сводка "День 1 прошёл отлично, 5%→25% на День 2"

Если проблема:

• Сразу alert в Slack
• Звоню tech lead
• Решаем вместе: откат или исправление

По завершению:

• Финальная сводка в Slack с результатами
• Celebrate в команде (если прошло хорошо)
• Постмортем (если были проблемы)

Шаг 5: Постмортем и learnings

После roll-out (успешного или неуспешного) провожу review:

Что произошло?

• Метрики совпали с А/B тестом?
• Если нет, почему?

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

• Добавляю в docs: как эта фича повлияла на бизнес
• Что выучили новое

Следующие фичи

• Если roll-out был медленный, может быть проблема в архитектуре
• Может быть нужно улучшить мониторинг
• Может быть нужны другие метрики

Пример из жизни

Фича: Новый checkout (убрали лишние поля) A/B тест: +12% конверсия, всё выглядит хорошо

День 1 (5%): +12%, нет крахов, всё ок День 2 (25%): +10%, notice: DAU упал на 3% (мб noise) День 3 (25%): +8%, DAU ещё ниже (-5%), нужно разбраться

Звоню разработчикам: "На новом checkout DAU упадает" Разработчик: "Проверил логи. На старых версиях приложения (не обновили) новый checkout ломается."

Решение:

• Откат рамповки до 0%
• Исправка бага (совместимость)
• Новый А/B тест
• Повторная рамповка

Ключевые принципы

Безопасность выше скорости: лучше разворачивать неделю, чем откатывать за день

Данные выше интуиции: если метрики не совпали с А/B тестом, разбираюсь почему

Автоматизация выше ручного труда: всё в feature flags и мониторинге

Коммуникация выше молчания: команда знает план и может помочь если что-то пойдёт не так

Быстрый откат выше медленного анализа: если критическая проблема—откатываюсь, потом анализирую

Грамотный roll-out—это разница между успешной фичей и инцидентом на production.