Продуктовый кейс: Оценка успешности новой фичи

Решение: Оценка успешности новой фичи

1. Как измерить успешность: Иерархия метрик

Уровень 1 — Первичный метрик (Primary Metric)

Выбор зависит от типа фичи, но принцип всегда одинаков: метрик должен быть связан с бизнес-целью.

Примеры:

• Фича для удержания пользователей → D7/D30 Retention Rate
• Фича для монетизации → Premium Conversion Rate или ARPU
• Фича для вовлечённости → Time Spent in App или DAU
• Фича для упрощения UX → Task Completion Rate или User Error Rate

Почему именно первичный метрик? Он напрямую влияет на стратегическую цель продукта. Если первичный метрик растёт, фича работает. Остальные метрики — для диагностики.

Уровень 2 — Вторичные метрики (Secondary Metrics)

Диагностические метрики, объясняющие, ПОЧ первичный работает (или не работает):

• Feature Adoption Rate — % пользователей, которые использовали фичу
• Feature Usage Frequency — как часто пользователи её используют
• Feature Satisfaction (NPS) — нравится ли фича
• Task Success Rate — успешно ли люди выполняют задачу
• Bounce Rate — сколько людей отказались от фичи после первой попытки

Уровень 3 — Метрики здоровья (Health Metrics)

Средства мониторинга для выявления регрессии:

• App Crash Rate — не сломала ли фича приложение
• Page Load Time — не замедлила ли производительность
• Support Tickets — не выросла ли нагрузка на поддержку
• Error Rate — не увеличилось ли количество ошибок

---

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

Пример: Фича "Сохранённые товары" в маркетплейсе

PRIMARY METRICS:

• Conversion Rate (add to cart → purchase): Control 12%, Target +10%
• Time to Purchase: Control 3.2 дня, Target -15% (2.7 дня)

SECONDARY METRICS:

• Feature Adoption Rate (% пользователей, нажавших Save)
• Save-to-Purchase Rate (% сохранённых товаров, куплены в течение 30 дней)
• Daily Active Savers (количество пользователей в день)
• Average Items Saved per User (глубина использования)

HEALTH METRICS:

• App Crash Rate
• API Response Time
• Support Tickets
• Data Integrity

---

3. Дизайн A/B-теста

Шаг 1: Сформулировать гипотезу

• Нулевая гипотеза (H0): Фича не влияет на конверсию
• Альтернативная (H1): Фича увеличивает конверсию на ≥10%

Шаг 2: Расчёт размера выборки

Параметры:

• Базовая конверсия (Control): 12%
• Минимальный эффект (MDE): +10% → 13.2%
• Статистическая мощность (Power): 80%
• Уровень значимости (α): 5%

Результат: ~12,000 пользователей в каждой группе (всего 24,000)

Шаг 3: Дизайн теста

ПРОВЕДЕНИЕ:

• Длительность: 14 дней (2 полные недели)
• Группы: 50/50 рандомизация
• Уровень рандомизации: user_id (не session)
• Sticky assignment: Да (один пользователь в одной группе)

СЕГМЕНТЫ:

• Target audience: Все пользователи
• Exclude: Beta-тестеры, Admins
• Geographic: Все регионы
• Device: Все платформы

МЕТОДОЛОГИЯ:

• Intent-to-treat (ITT) анализ (по группам рандомизации)
• Statistical test: Chi-square test
• Confidence interval: 95%

---

4. Подводные камни и как их избежать

Ошибка 1: Novelty Effect

Проблема: Новая фича нравится только потому, что она новая.

Признаки: День 1-3 огромный рост, затем День 7-14 замедление или падение.

Решение: Тест минимум 2 полные недели. Отслеживать adoption curve.

Ошибка 2: Simpson's Paradox

Проблема: Фича помогает одной подгруппе (Desktop +15%), вредит другой (Mobile -20%).

Решение: Делать segmented analysis по device, geography, user type.

Ошибка 3: Selection Bias

Проблема: Фича работает только для активных пользователей, которые её используют.

Решение: Использовать Intent-to-Treat (ITT) анализ — считаем всех, независимо от adoption.

Ошибка 4: Multiple Comparisons Problem

Проблема: Если отслеживаем 20 метрик, в среднем 1 будет значимым просто по случайности.

Решение:

• 1-2 primary metric ДО теста
• Остальное secondary с p-value 0.01
• Bonferroni correction: p-value = 0.05 / number_of_tests

Ошибка 5: Early Stopping (Peeking)

Проблема: Смотреть результаты в середине теста повышает вероятность false positive.

Правило: Не смотреть на результаты до конца теста.

Ошибка 6: Игнорирование механизмов

Проблема: Фича увеличила конверсию, но только потому что ускорилась система.

Решение: Анализировать secondary metrics, user feedback, логи использования.

---

Итоговый чек-лист

ДО ЗАПУСКА:

• Гипотеза чётко сформулирована
• Primary метрик определён
• Размер выборки рассчитан
• Длительность: минимум 2 недели
• Рандомизация проверена
• Логирование включено
• Stakeholders согласны

ВО ВРЕМЯ ТЕСТА:

• Проверка качества данных
• Баланс между группами
• Без раннего пика

ПОСЛЕ ТЕСТА:

• Statistical test (p-value < 0.05)
• Confidence interval (95%)
• Effect size (практическая значимость)
• Segmented analysis
• Post-hoc анализ
• Рекомендация (Rollout? Kill? Refine?)