Почему GMV тестовых вырос, а общий упал?

Анализ: GMV тестовой группы вырос, а общий GMV упал

Это классическая ситуация, которая часто встречается в A/B тестировании и требует глубокого анализа. Давайте разберём основные причины и подходы к диагностике.

Возможные причины: фундаментальные сценарии

1. Каннибализация (Cannibalization) — наиболее вероятная причина

Механизм:

• Тестовая группа получила улучшение, которое привело к росту её GMV
• Но это улучшение отняло покупателей/выручку у контрольной группы
• В результате: Test ↑5%, Control ↓10%, Total ↓2%

Пример: тестируем скидку для тестовой группы

Контроль: 1,000 заказов × 100 руб = 100,000 руб GMV
Тест: 1,200 заказов × 100 руб = 120,000 руб GMV
Общий GMV: (1,000 + 1,200) × 100 / 2,200 = ??? 
НЕТ ОШИБКИ! Каннибализация означает, что покупатели МИГРИРОВАЛИ:

По-правде:
Контроль: 800 заказов × 100 руб = 80,000 руб
Тест: 1,200 заказов × 95 руб (скидка) = 114,000 руб
Общий GMV: 80,000 + 114,000 = 194,000 (было 200,000)

Как обнаружить:

• Посмотреть на кривые тестовой и контрольной групп во времени
• Если Control падает параллельно с ростом Test — это каннибализация
• Проверить, упали ли цены/скидки в тестовой группе

2. Natural selection bias или дневные/недельные циклы

Механизм:

• Может быть, тест запущен в "хороший день" для тестовой группы?
• Или вы смотрите на неполные данные (день ещё идёт)?
• Или есть lag в reporting?

Диагностика:

SELECT
  DATE_TRUNC('day', event_time) as day,
  variation,
  SUM(gmv) as total_gmv,
  COUNT(DISTINCT user_id) as users
FROM orders
WHERE test_id = 'my_test'
GROUP BY 1, 2
ORDER BY 1 DESC;

Если видно, что Test высокий только в первый день, а потом выравнивается — это может быть:

• Reporting lag
• Selection bias
• Случайная флуктуация

3. Simpson's Paradox (Парадокс Симпсона)

Механизм:

• Тест имеет положительный эффект в каждом сегменте
• Но агрегированный результат — отрицательный
• Почему? Из-за разного распределения пользователей по сегментам

Пример:

Мобильные пользователи:
  Test: 500 заказов × 50 руб = 25,000 руб (lift +20%)
  Control: 600 заказов × 50 руб = 30,000 руб

Десктоп пользователи:
  Test: 300 заказов × 200 руб = 60,000 руб (lift +10%)
  Control: 2,000 заказов × 200 руб = 400,000 руб

Всего:
  Test: 85,000 руб
  Control: 430,000 руб
  Результат: контроль выигрывает! Почему?
  
Потому что в тесте больше доля мобильных (дешёвых заказов),
а в контроле больше доля десктопа (дорогих заказов).
Это может быть случайной флуктуацией в распределении.

Решение:

SELECT
  device_type,
  variation,
  COUNT(DISTINCT user_id) as users,
  COUNT(*) as orders,
  SUM(order_value) as gmv,
  AVG(order_value) as aov
FROM orders
WHERE test_id = 'my_test'
GROUP BY 1, 2;

Если видно неравномерное распределение по device_type — это Симпсон!

4. Статистическая флуктуация (False Negative)

Механизм:

• Размер выборки недостаточен
• Истинный эффект положительный, но из-за variance мы видим отрицательный результат
• Нужно больше времени/пользователей для конвергенции

Диагностика:

• Посчитать confidence interval и p-value
• Если p-value > 0.05 и CI включает 0 — это может быть просто noise
• Нужны расчеты power analysis

5. Ошибка в attribution или tracking

Механизм:

• Events логируются неправильно
• Есть дублирование заказов
• Есть missing data в одной из групп
• Event tracking отключился в контрольной группе

Диагностика:

SELECT
  variation,
  COUNT(*) as total_orders,
  COUNT(DISTINCT user_id) as unique_users,
  COUNT(*) / COUNT(DISTINCT user_id) as orders_per_user,
  COUNT(DISTINCT DATE(event_time)) as days_with_data,
  MIN(event_time) as first_order,
  MAX(event_time) as last_order
FROM orders
WHERE test_id = 'my_test'
GROUP BY 1;

Если видны аномалии (NULL values, дубликаты, странные распределения) — это tracking issue.

Детальный план анализа (ВАЖНО!)

Шаг 1: Проверка качества данных

• Есть ли missing data?
• Есть ли дубликаты заказов?
• Равномерно ли распределены пользователи?
• Есть ли странные pattern (все Test заказы на день 1?)?

Шаг 2: Сегментированный анализ

SELECT
  variation,
  device_type,
  user_segment,  -- new/existing/high-value
  geography,
  COUNT(DISTINCT user_id) as users,
  SUM(gmv) as total_gmv,
  AVG(gmv) as avg_order_value,
  COUNT(*) / COUNT(DISTINCT user_id) as orders_per_user
FROM orders
WHERE test_id = 'my_test'
GROUP BY 1, 2, 3, 4;

Ищите сегменты, где есть:

• Неравномерное распределение пользователей
• Разные AOV
• Разные conversion patterns

Шаг 3: Анализ временных трендов

• Растёт ли Test линейно или скачком?
• Падает ли Control параллельно?
• Есть ли дневные циклы?
• Есть ли день, когда произошёл скачок?

Шаг 4: Анализ каннибализации

SELECT
  variation,
  COUNT(DISTINCT user_id) as users,
  COUNT(DISTINCT user_id FILTER (WHERE is_new)) as new_users,
  COUNT(DISTINCT user_id FILTER (WHERE NOT is_new)) as returning_users
FROM orders
WHERE test_id = 'my_test'
GROUP BY 1;

Если в Test больше returning users, а в Control больше new — это может объяснить каннибализацию (вы переманивали existing customers).

Практические примеры и решения

Пример 1: Скидка в тесте

Что произошло: Test получил скидку 20%, что привело к росту volume, но снижению цены Решение: Смотреть на GMV до скидки (pre-discount) и с скидкой. Если pre-discount volume вырос, а цена была разумной — это победа. Если volume вырос только из-за скидки — это может быть убыточно.

Пример 2: New feature только в Test

Что произошло: Test получил улучшение UI, которое сработало, но переманило пользователей из Control Решение: Это нормальная каннибализация. Если эффект значительный и долгосрочный — развернуть всем. Если пользователи просто рассеялись — это может быть временным эффектом.

Пример 3: Simpson's Paradox

Что произошло: Control получил случайно больше high-value пользователей просто из-за randomization noise Решение: Увеличить размер выборки (нужно больше пользователей), чтобы распределения выравнялись.

Ключевые метрики для проверки

Смотри не только на GMV:

• AOV (Average Order Value) — средняя стоимость заказа
• Conversion Rate — % пользователей, которые совершили покупку
• Orders per User — среднее количество заказов на пользователя
• Revenue per User (RPU) — выручка на пользователя
• New vs Returning — распределение новых и повторных

Правильная декомпозиция:

GMV = Users × Conversion Rate × AOV
Или:
GMV = Users × RPU (Revenue Per User)

Если Test GMV вырос, но total упал:

• Скорее всего, Users или Conversion вырос в Test, но упал в Control
• Это может быть каннибализация или флуктуация

Выводы

Если GMV Test ↑, но Total ↓ — это обычно означает:

1. Каннибализация (70% вероятность): Test отнял пользователей/заказы у Control

   • Решение: Смотреть на long-term retention. Если тест имеет positive lifetime value — развернуть.

2. Simpson's Paradox (15% вероятность): Неравномерное распределение по сегментам

   • Решение: Смотреть на segmented анализ. Увеличить sample size.

3. Статистическая флуктуация (10% вероятность): Просто noise, нужно больше времени

   • Решение: Дождаться статистической значимости (power analysis указывает когда).

4. Ошибка в tracking (5% вероятность): Данные собираются неправильно

   • Решение: Проверить логи, валидацию, дебаг tracking.

Главный принцип: Никогда не смотри на один метрик в изоляции. Всегда разбирай результат по сегментам, типам пользователей, временным периодам. Контекст — король в анализе A/B тестов.