Какие критерии выбираешь для тестов?

Критерии выбора фич для A/B тестирования

Основной принцип

Тестировать нужно не всё подряд. Тесты стоят ресурсов, времени и могут создать шум в данных. Я разработал систему критериев, которая помогает определить, стоит ли тестировать конкретную фичу.

Критерий 1: Неуверенность (Uncertainty)

Это самый важный критерий. Если я на 90% уверен, что фича поднимет метрику, зачем тестировать?

Высокая неуверенность (тестируем):

• Новый UI элемент, который не юзер-тестировался
• Радикальное изменение в UX потока
• Противоречивые гипотезы в команде (дизайнер и аналитик спорят)

Низкая неуверенность (не тестируем):

• Исправление бага (очевидный выигрыш)
• Улучшение скорости загрузки на 50% (все хотят быстрее)
• Добавление feature, которую просили 100 юзеров

Формула простая: Uncertainty Score = 10 - (% уверенности / 10). Если выше 5 — тестируем.

Критерий 2: Объём трафика (Traffic Volume)

Для статистической значимости теста нужно достаточно юзеров. Правило большого пальца:

Нужно минимум 1000-2000 конверсий в control группе для надёжного результата.

Если твой продукт имеет 10k DAU и конверсия 2%, то конверсий в день ~200. Тебе нужна неделя теста, чтобы получить 1400 конверсий. Приемлемо.

Если 1k DAU и 2% конверсия, то ~20 конверсий в день. Тебе нужно 50-70 дней теста. Это слишком долго. Альтернатива — не тестировать и запустить на всех, если уверен.

Проверяю: есть ли достаточно трафика для теста длительностью 1-2 недели?

Критерий 3: Размер эффекта (Expected Lift)

Какой процент улучшения я ожидаю?

Большой эффект (>15% lift) — тестируем, даже при среднем трафике

• Например, редизайн checkout с 50% конверсией → ожидаем 60% (+10 пп)
• Даже при низком трафике статистика будет чистая

Маленький эффект (<5% lift) — нужен высокий трафик

• Например, изменение цвета кнопки с ожидаемым +2% лифтом
• Нужна большая выборка, чтобы эффект не был случайным

Критическое значение: Expected Lift = (New - Old) / Old × 100%

Если меньше 5% и трафик низкий, не тестирую.

Критерий 4: Стоимость ошибки (Cost of Being Wrong)

Что произойдёт, если тест покажет отрицательный результат или мы внедрим некорректную фичу?

Высокая стоимость ошибки (обязательно тестируем):

• Изменение в платёжном процессе (потеря даже 1% конверсии = большие деньги)
• Изменение цены подписки
• Удаление популярной фичи

Низкая стоимость ошибки (можно не тестировать):

• Косметическое изменение (новый цвет кнопки)
• Добавление помощи/подсказок
• Улучшение производительности

Формула: Cost Score = Monthly ARR Impact × % Change Risk

Если стоимость ошибки высокая, тестируем независимо от прочих факторов.

Критерий 5: Стратегическая важность (Strategic Alignment)

Привязана ли фича к квартальным OKR?

Стратегически важно (тестируем):

• OKR: увеличить LTV на 20%. Тест новой price strategy → валидируем перед масштабированием
• OKR: улучшить retention. Тест новой onboarding flow → понимаем impact

Не стратегично (можем пропустить тест):

• Случайный bug fix
• Улучшение по feedback одного юзера

Критерий 6: Скорость реализации (Time to Implement)

Если фича уже разработана, стоит хотя бы 1-2 дня на A/B тест.

Если реализация займёт месяц, а тест 2 недели — это 2 недели задержки. Оценивается относительно benefit.

Esle можно быстро откатить фичу, рисковать проще.

Практический пример: готовой к тестированию?

Сценарий 1: Редизайн checkout

• Uncertainty: HIGH (дизайнер и аналитик спорят)
• Traffic: 50k DAU, 5% конверсия = 2500 конверсий/день → ДОСТАТОЧНО
• Expected Lift: +15% → БОЛЬШОЙ
• Cost of Error: ОЧЕНЬ ВЫСОКАЯ (24% конверсии × 30% пользователей × $50 LTV = $3.6k/день на кону)
• Time to implement: уже готово

Вывод: ОБЯЗАТЕЛЬНО ТЕСТИРУЕМ. A/B тест минимум неделю.

Сценарий 2: Изменение цвета submit кнопки с синего на зелёный

• Uncertainty: LOW (очевидно, что зелёный ассоциируется с позитивным действием)
• Traffic: достаточно
• Expected Lift: +1-2% → МАЛЕНЬКИЙ
• Cost of Error: LOW
• Time to implement: быстро

Вывод: НЕ ТЕСТИРУЕМ. Запускаем на всех, если дизайнер уверен. Если через неделю метрика упадёт, откатываем.

Сценарий 3: Добавление нового фильтра в поиск

• Uncertainty: СРЕДНЯЯ (хотим валидировать, нужен ли юзерам этот фильтр)
• Traffic: 10k DAU, 8% клик-rate = 800 кликов/день → МАРГИНАЛЬНО
• Expected Lift: +8% → СРЕДНИЙ
• Cost of Error: LOW (это дополнительный фильтр, не ломаем ничего)
• Time to implement: готово

Вывод: ТЕСТИРУЕМ, но растягиваем на 2-3 недели, чтобы набрать статистику.

Метрики для тестирования

Какие метрики смотрю в тесте? Всегда выбираю primary и secondary:

Primary метрика — главный KPI, на который рассчитываем влиять.

• Например: CTR кнопки для новой кнопки
• Например: конверсия для редизайна checkout

Secondary метрики — побочные эффекты. Может, новая фича повысит основную метрику, но сломает retention?

• Например: время сессии, bounce rate, возврат пользователя

Guardrail метрики — красные линии. Если эта метрика упадёт, тест провален, несмотря на успех primary.

• Например: не должны потерять более 5% DAU
• Например: loading time не должна возрасти более чем на 10%

Выводы

Тестирование — это инвестиция, а не закономерность. Я выбираю, что тестировать на основе:

1. Неуверенности в результате
2. Объёма доступного трафика
3. Ожидаемого размера эффекта
4. Стоимости ошибки
5. Стратегической важности
6. Скорости реализации

Эти 6 критериев дают мне объективный фреймворк, чтобы не тратить ресурсы на очевидные решения и не пропустить важные валидации.