Аналитика роста StudyFlow: активация, оплата и удержание

Портфельный проект по продуктовой аналитике SaaS/EdTech-продукта на воспроизводимых синтетических данных.

Как увеличить оплату и удержание пользователей, не ухудшая возвраты, надёжность платежей, нагрузку на поддержку и NPS?

Краткий ответ

После исключения тестовых аккаунтов проанализирован 5 141 активный пользователь. Активация за 7 дней составляет 69,4%, конверсия в оплату за 14 дней — 22,3%, ARPU за 30 дней — 387, ARPPU — 1 733.

В синтетическом рандомизированном A/B-тесте умный онбординг повысил:

• активацию за 7 дней на 16,89 п.п.;
• конверсию в оплату за 14 дней на 7,37 п.п..

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

Управленческие выводы

1. Умный онбординг — главный кандидат на внедрение по результатам сгенерированного эксперимента.
2. organic показывает лучший показатель приближённой прибыли, а email — лучшую конверсию в оплату. Бюджет нельзя перераспределять только по конверсии: нужны CAC, ROAS, удержание и предельный эффект.
3. На mobile_web доля неуспешных платежей достигает 7,0%; это приоритет для отдельной диагностики платёжного пути.
4. Событийные этапы в исходной генерации не всегда вложены друг в друга. Поэтому таблицу покрытия этапов нельзя интерпретировать как строгую последовательную воронку без дополнительной проверки условий.

Что сделано

• проверка качества и очистка данных;
• продуктовые KPI и пользовательские сегменты;
• когортный анализ и 30-дневное удержание;
• приближённая юнит-экономика по каналам;
• A/B-тест: z-тест долей, доверительные интервалы и защитные метрики;
• SQL-запросы с сохранёнными ответами;
• спецификация дашборда и сценарий защиты проекта.

Структура проекта

studyflow-growth-analytics/
├── data/
│   ├── raw/                 # исходные синтетические таблицы
│   └── processed/           # витрины, KPI и база SQLite
├── docs/                    # словарь, методология, дашборд и защита
├── notebooks/               # два выполненных аналитических ноутбука
├── reports/                 # отчёт, SQL с ответами и графики
├── sql/                     # запросы и результаты
└── src/                     # генерация данных и воспроизводимый анализ

Навигация

• Итоговый аналитический отчёт
• Полный код и выводы
• SQL-запросы с ответами
• Словарь данных
• Спецификация дашборда
• Подготовка к защите
• Полный ноутбук Python, статистики, A/B-теста и SQL

Воспроизведение

python -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt
python src/generate_data.py
python src/run_analysis.py

Основные точки входа:

• src/01_python_product_analytics.py — KPI, этапы продукта, каналы, когорты и сегменты;
• src/02_statistics_ab_testing.py — доверительные интервалы, z-тест, t-тест, хи-квадрат и корреляции;
• src/03_run_sql_queries.py — выполнение SQL и сохранение ответов.

Ограничения

• Данные синтетические: выводы показывают аналитический подход, а не состояние действующего продукта.
• Выручка ограничена 30-дневным окном, поэтому LTV является приближением.
• A/B-тест сгенерирован как рандомизированный. В реальном эксперименте нужны проверки SRM, логирования, пересечений тестов и мощности.
• Приближённая прибыль не учитывает все операционные расходы.
• Для настоящей последовательной воронки каждый следующий этап должен быть определён только среди пользователей, прошедших предыдущий.