Какая решенная задача повлияла на метрики команды или бизнеса?

Кейс: Анализ причин низкого retention в мобильном приложении

Контекст задачи

В одном из проектов я работал на позиции Product Analyst в компании с мобильным приложением (финтех). Наблюдалась серьёзная проблема: retention через 7 дней был всего 25%, а через 30 дней упал до 10%. Это было критично, так как приложение затрачивало значительные ресурсы на привлечение пользователей, но они быстро уходили.

Приложение уже полгода находилось на рынке, но никто глубоко не анализировал, почему именно пользователи уходят.

Этап 1: Формулировка гипотез

Я начал с того, что определил основные гипотезы падения retention:

1. Проблемы с onboarding: может быть, пользователи не понимают, как пользоваться приложением
2. Слабое предложение ценности: нет стимула возвращаться
3. Технические проблемы: краши, баги, медленная работа
4. Проблемы с первой транзакцией: если первый платёж не прошёл, пользователь может не вернуться
5. Неправильная целевая аудитория: привлекаем не тех пользователей

Этап 2: Сбор и анализ данных

Во-первых, я подготовил SQL запросы для анализа пути пользователя:

WITH user_cohorts AS (
  SELECT 
    DATE_TRUNC('day', created_at)::date AS cohort_date,
    user_id,
    EXTRACT(DAY FROM MAX(last_activity_at) - MIN(created_at)) AS days_active
  FROM users
  WHERE created_at >= NOW() - INTERVAL '90 days'
  GROUP BY cohort_date, user_id
)
SELECT 
  cohort_date,
  COUNT(*) AS total_users,
  COUNT(CASE WHEN days_active >= 1 THEN 1 END)::numeric / COUNT(*) * 100 AS d1_retention,
  COUNT(CASE WHEN days_active >= 7 THEN 1 END)::numeric / COUNT(*) * 100 AS d7_retention,
  COUNT(CASE WHEN days_active >= 30 THEN 1 END)::numeric / COUNT(*) * 100 AS d30_retention
FROM user_cohorts
GROUP BY cohort_date
ORDER BY cohort_date DESC;

Затем я начал сегментировать пользователей по разным параметрам:

Сегментация по источнику трафика:

SELECT 
  source_channel,
  COUNT(*) AS users,
  COUNT(CASE WHEN retention_d7 THEN 1 END)::numeric / COUNT(*) * 100 AS d7_retention,
  COUNT(CASE WHEN made_first_transaction THEN 1 END)::numeric / COUNT(*) * 100 AS conversion_rate,
  AVG(CASE WHEN made_first_transaction THEN transaction_amount ELSE 0 END) AS avg_first_txn
FROM users
WHERE created_at >= NOW() - INTERVAL '30 days'
GROUP BY source_channel
ORDER BY d7_retention DESC;

Результат: пользователи из TikTok имели D7 retention 35%, а из Facebook всего 15%. Это был намёк.

Этап 3: Глубокий анализ когорт

Я разделил пользователей на группы по поведению на первый день:

• Группа A: Зарегистрировались и завершили первую транзакцию → D7 retention 62%
• Группа B: Зарегистрировались, но не совершили транзакцию → D7 retention 8%
• Группа C: Завис на экране входа → D7 retention 2%

Вывод: главный bottleneck — это первая транзакция. Если пользователь не платит в первый день, вероятность его возврата близка к нулю.

Этап 4: Анализ причин недоделок первой транзакции

Далее я изучил логи и поведение пользователей, которые начали транзакцию, но не завершили:

SELECT 
  checkout_step,
  COUNT(*) AS drop_offs,
  ROUND(100.0 * COUNT(*) / LAG(COUNT(*)) OVER (ORDER BY sequence), 2) AS drop_rate
FROM checkout_funnels
WHERE created_at >= NOW() - INTERVAL '14 days'
GROUP BY sequence, checkout_step
ORDER BY sequence;

Результат:

• Регистрация → Выбор плана: 85% завершают
• Выбор плана → Способ оплаты: 70% завершают ⚠️ (15% drop-off!)
• Способ оплаты → Подтверждение: 50% завершают ⚠️ (20% drop-off!)

Главная проблема: экран выбора способа оплаты был очень сложный, требовал ввода кучу данных, и много пользователей отказывались.

Этап 5: Рекомендации и решение

На основе анализа я подготовил рекомендацию:

Приоритет 1 (Высокий): Упростить процесс добавления способа оплаты

• Убрать лишние поля
• Добавить saved payment methods
• Добавить Apple Pay / Google Pay

Приоритет 2 (Средний): Улучшить целевую аудиторию

• Снизить бюджет Facebook (low retention)
• Увеличить бюджет TikTok (35% retention vs 15%)

Приоритет 3 (Низкий): Оптимизировать onboarding

• Добавить tutorial для новых пользователей

Этап 6: Реализация и результаты

Разработка реализовала приоритет 1: упростили чекаут (что заняло ~2 недели спринта).

Результаты через месяц:

Этап 7: Дополнительный impact

В денежных терминах:

• Приложение тратило $3 на привлечение пользователя (CAC)
• LTV был $45, LTV/CAC = 15
• После улучшения LTV = $72, LTV/CAC = 24 (на 60% лучше)
• При 10,000 новых пользователей в месяц это означало +$270,000 дополнительного дохода за год (при условии, что число пользователей останется тем же)

А поскольку LTV/CAC стал лучше, команда смогла увеличить маркетинговый бюджет на 50%, привлекая больше пользователей прибыльно.

Ключевые выводы

1. Данные показывают проблему, но не всегда причину — нужно глубоко копать
2. Сегментация критична — один средний показатель может скрывать большие различия между группами
3. Первая транзакция = ключевой момент — если пользователь не платит вначале, он вряд ли вернётся
4. Анализ должен привести к действию — главное не цифры, а то, что на них делать
5. Нужно отслеживать impact — убедиться, что рекомендация действительно сработала

Этот анализ был поворотным пунктом для компании, так как он четко определил bottleneck и показал, какие изменения принесут наибольшую отдачу.