Карта мобильной аналитики: какие события нужны в MVP

Зачем карта событий

Без заранее согласованной схемы аналитики данные становятся шумом, и продуктовые решения принимаются «на ощущениях».

Core-события для MVP

• app_open
• signup_started
• signup_completed
• trial_started
• payment_success
• feature_core_used

Правила именования

• snake_case
• единые параметры (user_id, plan, platform)
• версии событий (event_version)

Проверка качества

• Сверка events volume между iOS/Android
• Проверка обязательных параметров
• Дашборд активации и week-1 retention

Framework событий для MVP

Удобно группировать события на 4 слоя:

1. Acquisition — откуда пользователь пришёл и дошёл ли до первого экрана.
2. Activation — завершил ли первый ключевой шаг.
3. Engagement — использует ли core-функции регулярно.
4. Monetization — начал ли trial/подписку/оплату.

Так вы не теряетесь в "сотне событий", которые никто не анализирует.

Пример event taxonomy

auth.signup_started
auth.signup_completed
onboarding.step_completed
feature.chat_message_sent
billing.trial_started
billing.payment_success

Важный момент: название должно сразу объяснять домен и действие.

Параметры, которые стоит стандартизировать

• platform: ios/android
• app_version
• user_tier: free/pro
• locale
• experiment_id (если A/B)

Без этого сравнивать когорты и делать нормальные выводы будет сложно.

Валидация данных в продакшене

Типичная проблема: событие отправляется, но без критичного поля. Команда думает, что данные есть, а в BI пусто.

Решение:

• schema validation перед отправкой;
• alert, если обязательное поле отсутствует > X% событий;
• еженедельный audit top-20 событий.

Дашборды, которые нужны сразу

1. Activation funnel: open -> signup -> core action.
2. Retention D1/D7.
3. Paid conversion: trial -> payment.
4. Crash + ANR рядом с продуктовой воронкой.

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

Частые anti-patterns

• Логировать "всё подряд", но не использовать.
• Разные имена событий на iOS и Android.
• Изменять параметры без версионирования.
• Не фиксировать owner аналитики.

Практический чеклист

• Есть единый словарь событий
• Есть owner за событийную модель
• Ключевые события покрывают activation и monetization
• Данные валидируются и мониторятся
• Команда использует дашборды в weekly review