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

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

Определение Customer Experience (CX)

Customer Experience — это совокупность ощущений пользователя при взаимодействии с приложением. Включает скорость работы, удобство интерфейса, надёжность, качество контента и поддержку.

Метрики CX отличаются от бизнес-метрик:

• Бизнес-метрики: DAU, ARPU, Retention (что происходит)
• CX-метрики: Скорость загрузки, количество кликов до цели, NPS (как ощущает пользователь)

Три слоя CX метрик

┌──────────────────────────────────────┐
│ 1. PERFORMANCE (Технические)         │ ← Как быстро?
│    Скорость, стабильность            │
├──────────────────────────────────────┤
│ 2. USABILITY (Удобство)              │ ← Как легко?
│    Навигация, интуитивность          │
├──────────────────────────────────────┤
│ 3. SATISFACTION (Удовлетворённость)  │ ← Как доволен?
│    NPS, CSAT, отзывы                 │
└──────────────────────────────────────┘

Слой 1: PERFORMANCE METRICS (Технические метрики)

1.1 App Launch Time (Время загрузки приложения)

Определение: Сколько секунд от тапа на иконку приложения до готовности к использованию.

METRИKA: Time to Interactive (TTI)
Формула: (когда приложение откликается на юзер-ввод)

Категории:
- < 1 секунда: Отлично ✓
- 1-2 секунды: Хорошо
- 2-3 секунды: Норм
- > 3 секунд: Плохо ✗ (много юзеров удаляет приложение)

Как собирать:

// iOS (Swift)
let startTime = CFAbsoluteTimeGetCurrent()
// ... приложение загружается ...
let endTime = CFAbsoluteTimeGetCurrent()
let launchTime = endTime - startTime
analytics.track("app_launch_time", {
    "duration_ms": launchTime * 1000
})

Пример результата:

Version    Launch Time
2.0        1.2s      ✓
2.1        1.5s      ✓
2.2        3.1s      ✗  ← РЕГРЕССИЯ! Нужна оптимизация
2.3        1.8s      ✓  ← Фиксили, улучшилась

1.2 Screen Load Time (Время загрузки экранов)

Определение: Сколько времени пользователь ждёт, пока отобразится контент на экране.

МЕТРИКА: First Contentful Paint (FCP)
Формула: Время от клика → первый контент видим

Нормы:
- < 0.5с: Отлично
- 0.5-1.5с: Хорошо
- 1.5-3с: Медленновато
- > 3с: Очень медленно

Примеры:

Экран              FCP    Статус
──────────────────────────────────
Homepage           0.3s   ✓ Отлично
Search Results     1.2s   ✓ Хорошо
Product Details    2.1s   ⚠️ Медленновато
Checkout           3.5s   ✗ Слишком медленно!
Profile            0.8s   ✓ Хорошо

Проблема: Если Search Results загружается 2+ секунды, юзеры отходят к конкурентам.

1.3 Frame Rate (Плавность прокрутки)

Определение: Сколько кадров в секунду (FPS) при прокрутке экрана.

МЕТРИКА: Frames Per Second (FPS)

Нормы:
- 60 FPS: Идеально (стандарт для iPhone 12+)
- 50-60 FPS: Отлично
- 30-50 FPS: Заметны зависания
- < 30 FPS: Очень плохо, юзеры расстраиваются

Э-читай время кадра:
60 FPS = один кадр каждые 16.67 ms
Если кадр > 16.67 ms → FPS падает

Инструменты:

• Xcode Instruments (iOS)
• Android Profiler (Android)
• Firebase Performance Monitoring
• Sentry (для production)

Пример проблемы:

Старое приложение:
- Прокрутка списка: 45 FPS (зависание видно)
- Анимация карточек: 30 FPS (очень плохо)

После оптимизации:
- Прокрутка списка: 58 FPS (почти не видно зависания)
- Анимация карточек: 55 FPS (плавная)

Результат: Удовлетворённость +20%

1.4 Crash Rate (Процент крахов)

Определение: Сколько % сессий заканчиваются крахом приложения.

МЕТРИКА: Crash Free Users
Формула: (Users without crash) / (Total Users) * 100%

Нормы:
- > 99.9% crash-free: Отлично ✓
- 99-99.9% crash-free: Хорошо
- 98-99% crash-free: Приемлемо
- < 98% crash-free: Плохо ✗

Пример:

# Из Firebase Crashlytics
crash_free_rate = (
    users_without_crash / total_users
) * 100

result = 99.5%  # Хорошо

1.5 API Response Time (Время ответа сервера)

Определение: Сколько времени сервер отвечает на запрос приложения.

МЕТРИКА: P95 API Latency
(95-й перцентиль, не среднее)

Нормы:
- < 200 ms: Отлично
- 200-500 ms: Хорошо
- 500-1000 ms: Медленновато
- > 1000 ms: Слишком медленно

Правило: Никогда не используй среднее (mean), используй перцентили:

P50 (median) = 300 ms  # Половина запросов
P95 = 1200 ms  # 95% быстрее, 5% медленнее
P99 = 3000 ms  # 99% быстрее, 1% медленнее

# Если P95 = 1.2s, то 5% пользователей ждут > 1.2s
# Это плохо для UX

1.6 Battery Drain (Потребление батареи)

Определение: Сколько % батареи тратит приложение за час использования.

МЕТРИКА: Battery Consumption (% per hour)

Нормы:
- < 5% per hour: Отлично
- 5-10% per hour: Хорошо
- 10-20% per hour: Приемлемо
- > 20% per hour: Слишком много ✗

Проблема: Юзеры удаляют приложения, которые быстро сажают батарею. Особенно на Android.

1.7 Data Usage (Потребление трафика)

Определение: Сколько МБ/ГБ трафика тратит приложение.

МЕТРИКА: Data per Session (МБ)

Нормы:
- < 10 МБ per session: Отлично (например, мессенджер)
- 10-50 МБ per session: Хорошо
- 50-200 МБ per session: Приемлемо (соцсеть с видео)
- > 200 МБ per session: Слишком много

Проблема: В странах с дорогим интернетом (Индия, Африка)
juзеры очень внимательны к трафику

Слой 2: USABILITY METRICS (Метрики удобства)

2.1 Task Completion Rate (Процент завершённых задач)

Определение: Сколько % пользователей успешно завершают основную задачу.

Задача: Купить товар

Шаги:
1. Открыть приложение
2. Найти товар
3. Добавить в корзину
4. Перейти к оплате
5. Оплатить
6. Подтверждение

MЕТРИКА: Completion Rate = (Шаг 6) / (Шаг 1) * 100%

Пример:
100k юзеров открыли приложение
95k нашли товар (95%)
80k добавили в корзину (80%)
60k перешли к оплате (60%)
45k оплатили (45%) ← COMPLETION RATE = 45%

Интерпретация: 55% юзеров не завершили покупку. Нужно выяснить, на каком шаге они падают.

2.2 Funnel Drop-off (Падение на этапах)

Определение: На каких этапах пользователи уходят.

Funnel Analysis:

Шаг 1: Открыли приложение ────────── 100,000
          ↓ (Потеря 5%)
Шаг 2: Нашли товар ───────────────── 95,000
          ↓ (Потеря 15%)
Шаг 3: Добавили в корзину ─────────── 80,000
          ↓ (Потеря 20%)
Шаг 4: Перешли к оплате ──────────── 60,000
          ↓ (Потеря 15%)
Шаг 5: Оплатили ──────────────────── 45,000

Самое большое падение: Шаг 3 → Шаг 4 (20%)
Вывод: Проблема при оформлении, нужно улучшить UX

2.3 Clicks to Goal (Количество кликов до цели)

Определение: Сколько в среднем кликов нужно, чтобы достичь цель.

Гипотеза: Чем меньше кликов, тем лучше

Примеры:
────────────────────────────────────
Цель: Открыть профиль
- Плохо: 5 кликов (Settings → Account → Users → Profiles → My Profile)
- Хорошо: 2 клика (Bottom Tab → Profile)
- Отлично: 1 клик (Bottom Tab → Profile автоматически)

Цель: Отправить сообщение
- Плохо: 4 клика (Chats → Find Contact → Select → Send)
- Хорошо: 2 клика (Chats → Recent Contact → Type → Send)

Правило: Для основных действий < 3 кликов.

2.4 Error Rate (Процент ошибок юзер-действий)

Определение: Сколько % действий приводит к ошибке.

МЕТРИКА: Action Error Rate
Формула: (Actions with error) / (Total actions) * 100%

Примеры:
- Неправильный ввод данных: "Email not valid" → Error
- Сервер не ответил: "Network error" → Error
- Форма не отправилась: "Please try again" → Error

Нормы:
- < 1%: Отлично
- 1-5%: Хорошо
- 5-10%: Приемлемо
- > 10%: Плохо

Слой 3: SATISFACTION METRICS (Метрики удовлетворённости)

3.1 Net Promoter Score (NPS)

Определение: "Насколько вероятно ты рекомендуешь приложение друзьям?"

Шкала: 0-10
- 9-10: Промотеры (рекомендуют)
- 7-8: Пассивные
- 0-6: Детракторы (критикуют)

Формула: NPS = % Промотеров - % Детракторов
Целевое значение: > 50 (отлично)

3.2 CSAT (Customer Satisfaction Score)

Определение: "Насколько ты доволен приложением?"

Шкала: 1-5 звёзд
- 5 звёзд: Очень доволен
- 4 звезды: Доволен
- 3 звезды: Нейтрально
- 2 звезды: Недоволен
- 1 звезда: Очень недоволен

Целевое значение: ≥ 4.2 звезды

3.3 App Store Rating

Определение: Рейтинг в App Store / Google Play.

Целевое значение: ≥ 4.5 звёзд

Проблема: Если упало ниже 4.3, это видно новым юзерам,
и они не скачивают приложение

3.4 Issue Frequency (Частота проблем)

Определение: Сколько проблем встречает пользователь за сессию.

ПРОБЛЕМА = любой непредсказуемый результат:
- Баг
- Медленная загрузка
- Неправильное отображение
- Потеря данных
- Confusing UI

МЕТРИКА: Issues per session
Нормы: < 0.5 проблемы на сессию

Пример:
100k сессий
30k сессий без проблем
70k сессий с 1+ проблемой

Изус фрекуэнси = 1 - (30k / 100k) = 0.7 = 70%

Интегральные метрики CX

4.1 Core Web Vitals (Google's Standard)

Google определил 3 главные метрики (для веба, но применимо и к мобилю):

1. LCP — Largest Contentful Paint
   (время до загрузки основного контента)
   Норма: < 2.5 seconds

2. FID — First Input Delay
   (отзывчивость на клик)
   Норма: < 100 ms

3. CLS — Cumulative Layout Shift
   (стабильность макета, нет ли скачков)
   Норма: < 0.1

4.2 CX Score (Композитная метрика)

# Мой способ:
CX_Score = (
    (100 - crash_rate) * 0.2 +  # 20% — стабильность
    (launch_time_score) * 0.2 +  # 20% — скорость
    (completion_rate) * 0.2 +    # 20% — эффективность
    (nps_score) * 0.2 +          # 20% — лояльность
    (app_rating * 20) * 0.2      # 20% — отзывы
) / 100

# 0-100 score
# > 80 = Отличный CX
# 60-80 = Хороший CX
# 40-60 = Приемлемый CX
# < 40 = Плохой CX

Как я отслеживал CX в реальном проекте

Контекст: Мобильное приложение для доставки еды

Dashboard CX:

┌─────────────────────────────────────────────────┐
│ CX DASHBOARD — Food Delivery App                 │
├─────────────────────────────────────────────────┤
│ 📊 Overall CX Score: 78/100  ✓ Good            │
│                                                  │
│ Performance Layer:                              │
│ ├─ App Launch Time: 1.5s (Target: < 1s)        │
│ ├─ Screen Load Time: 1.2s avg (Target: < 1.5s) │
│ ├─ Crash Rate: 0.8% (Target: < 0.1%) ✗        │
│ ├─ P95 API Latency: 450ms (Target: < 200ms)    │
│ └─ Battery: 8% per hour (Target: < 5%)         │
│                                                  │
│ Usability Layer:                                │
│ ├─ Order Completion: 72% (Target: > 80%) ✗    │
│ ├─ Clicks to Order: 5 (Target: < 4) ✗         │
│ ├─ Error Rate: 2.1% (Target: < 1%)             │
│ └─ Task Success: 85%                            │
│                                                  │
│ Satisfaction Layer:                             │
│ ├─ NPS: 45 (Target: > 50) ✗                    │
│ ├─ CSAT: 4.1/5 (Target: ≥ 4.5)                │
│ ├─ App Rating: 4.3 stars (Target: ≥ 4.5)      │
│ └─ Churn: 12% MoM (Target: < 5%)               │
│                                                  │
│ 🔴 Critical Issues:                            │
│ • Crash rate выше нормы (версия 3.2)           │
│ • Падение заказов на 8% в последнюю неделю    │
│ • NPS упал с 50 на 45 за месяц                 │
│                                                  │
│ ✅ Action Items:                               │
│ 1. Выпустить hotfix для крахов (P0)            │
│ 2. Упростить UI заказа (уменьшить клики)       │
│ 3. Провести UX исследование (что не нравится)  │
└─────────────────────────────────────────────────┘

Результаты улучшений:

До оптимизации:        После оптимизации:
─────────────────      ──────────────────
Crash Rate: 0.8%       Crash Rate: 0.1%    ✓
Completion: 72%        Completion: 82%     ✓
NPS: 45                NPS: 52              ✓
CX Score: 78           CX Score: 86         ✓
Retention D30: 55%     Retention D30: 68%   ✓

Резюме: Главные CX метрики для мобильного приложения

Главный принцип: Следи за всеми тремя слоями. Не бывает хорошего CX с плохой производительностью или невыносимой навигацией, даже если люди в опросах говорят, что им нравится.