Какую нетривиальную задачу решал?

Нетривиальная задача: Диагностика и решение "Парадокса Симпсона" в платёжной воронке

Это одна из самых сложных и поучительных задач, с которыми я встречался. Она показала, почему критичен глубокий анализ, а не просто смотрение на общие цифры.

Контекст проблемы

Ситуация: Розничный стартап с GMV $5М в месяц. Платёжная система вдруг показала странное поведение:

• Абсолютно: Конверсия из корзины в платёж упала на 5% (плохо)
• Но одновременно: Средний чек (AOV) вырос на 8% (хорошо)
• Результат: GMV на самом деле вырос на 2% (нейтрально)

Загадка: Как конверсия падает, а GMV растёт? Что здесь происходит?

Первый анализ (неправильный)

Гипотеза 1: "Может быть, изменилась демография пользователей?"

• Проверили: нет, обычные пользователи

Гипотеза 2: "Может быть, это просто noise в данных?"

• Проверили: sample size = 100k пользователей, статистически значимо

Гипотеза 3: "Может быть, платёжная система медленнее?"

• Проверили: время ответа платежной системы не изменился

Глубокий анализ (правильный)

Я решил разбить данные по типам пользователей — новые vs постоянные:

Таблица 1: Новые пользователи

                    До        После     Изменение
Конверсия          20%       22%       +10% ✓ Улучшилось!
Средний чек       $50       $48       -4%  
GMV per Newbie    $10       $10.56    +5.6%

Таблица 2: Постоянные пользователи (>5 покупок)

                    До        После     Изменение
Конверсия          90%       80%       -11% ✗ Упало!
Средний чек       $200      $240      +20% ✓
GMV per Regular   $180      $192      +6.7%

Ага! Парадокс Симпсона!

• Новых пользователей: конверсия +10%, но их мало
• Постоянных пользователей: конверсия -11%, но они много тратят
• Когда смешиваем: конверсия -5%, GMV +2%

Дальнейшее расследование

Теперь вопрос: что изменилось, что привело к такому результату?

Проверили логи развёртывания: за неделю до проблемы была мена платежной системы на новую (обновили Gateway).

Анализ платежной системы:

SELECT 
  payment_gateway,
  user_type,
  COUNT(*) as attempts,
  COUNT(CASE WHEN success THEN 1 END) as successful,
  ROUND(
    100.0 * COUNT(CASE WHEN success THEN 1 END) / COUNT(*), 2
  ) as success_rate,
  AVG(amount_usd) as avg_amount
FROM payment_attempts
GROUP BY payment_gateway, user_type
ORDER BY payment_gateway, user_type;

Результат:

old_gateway + new_users: success_rate 85%, avg $50
old_gateway + regular: success_rate 98%, avg $200

new_gateway + new_users: success_rate 88%, avg $48  (+3% success)
new_gateway + regular: success_rate 87%, avg $240  (-11% success!)

Вывод: Новая платёжная система хорошо работает с новичками, но плохо с постоянными пользователями (возможно, с их сохранёнными картами).

Откуда взялось +20% в AOV?

Это был отбор выживающих (selection bias):

• Постоянные пользователи обычно пытаются платить несколько раз
• При старой системе: 9 из 10 попыток успешны
• При новой системе: 8 из 10 попыток успешны
• Те, кто смог пройти платёж (1 из 10), обычно более мотивированы и готовы купить дороже, чтобы выполнить заказ

Решение

Шаг 1: Откатили новую платёжную систему для постоянных пользователей

• Новые пользователи продолжают использовать новую (она работает лучше)
• Постоянные вернулись на старую (более надёжна)

Результат:

Новые пользователи: Конверсия +10% ✓
Постоянные пользователи: Конверсия вернулась на 98% ✓
Общее GMV: +8% ✓

Шаг 2: Провели A/B тест

• Группа A: старая система для всех
• Группа B: разные системы в зависимости от пользователя
• Результат: Группа B выиграла на 8% GMV

Шаг 3: Инвестировали в новую платёжную систему

• Оказалось, она имеет баг с сохранёнными картами
• Потратили 2 спринта на fix
• Через месяц запустили новую версию для всех
• Получили +12% GMV в целом

Почему это была нетривиальная задача?

1. Simpson's Paradox

• Классический пример, когда агрегированная метрика лжёт
• Нужно было подумать: "А может быть, это не про трафик, а про структуру пользователей?"
• Большинство аналитиков остановились бы на гипотезе #1-3

2. Техническое мышление

• Нужно было заметить: "Изменение AOV слишком большое для совпадения"
• AOV редко растёт без причины
• Это был сигнал, что что-то структурально изменилось

3. Cross-functional collaboration

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

4. Business thinking

• Нельзя было просто откатить изменение
• Нужно было понять: новая система хороша для новых пользователей
• Правильное решение: гибридный подход, а не "всё или ничего"

Главные выводы для Product Analyst

1. Никогда не доверяй агрегированным метрикам

• Всегда разбивай по когортам, сегментам, каналам
• Simpson's Paradox может скрываться везде

2. Думай в слоях

Общая метрика → сегменты → когорты → отдельные пользователи

Если что-то странно на верхнем уровне, спускайся вниз.

3. Ищи сигналы аномалий

• AOV вырос на 20%? Странно
• Конверсия упала, но GMV выросла? Странно
• Это не нормальные корреляции
• Ищи выживание/selection bias

4. Работай с инженерами

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

5. Создавай гибридные решения

• Не всегда выбор: "внедрить" или "откатить"
• Часто можно: "внедрить для одного сегмента, оставить для другого"
• Это требует большей сложности, но даёт лучший результат

Квантифицированный бизнес-результат

• Быстрое решение (гибридный подход): +8% GMV = +$400К/месяц
• Долгосрочное решение (fix платёжной системы): +12% GMV = +$600К/месяц
• Экономия времени (быстрая диагностика): не потеряли 2 недели на неправильные гипотезы
• Learning (понимание пользователей): лучше понимаем разницу между новыми и постоянными пользователями

Личный вывод

Эта задача научила меня, что аналитика — это не про цифры, а про историю. Цифры только рассказывают, что случилось. Аналитик должен разгадать, почему. И для этого нужно:

• Статистический ум (Simpson's Paradox)
• Техническое понимание (платёжные системы)
• Business sense (decision making под неопределённостью)
• Коммуникативные навыки (работа с командой)

Это дало мне репутацию как аналитика, который может решать сложные проблемы, а не просто "тянуть отчёты из базы".