# Найдите точку, где пользователь теряется

- **Канонический URL:** https://playbook.affpartners.io/ru/practices/quality-funnel/index.html
- **Markdown-версия:** https://playbook.affpartners.io/ru/practices/quality-funnel/index.md
- **Раздел:** Качество продукта
- **Время:** 60 минут на первый аудит

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

## Результат

Таблица с пятью шагами пути, одной точкой потери, вероятной причиной и владельцем следующего изменения.

## Ищем не весь плохой путь, а одно место

Представьте путь пользователя как пять дверей. На каждом шаге часть людей уходит. Ваша задача — увидеть, у какой двери теряется больше всего пользователей, понять вероятную причину и исправить сначала её.

## Что понадобится

- **Доступ:** AppMetrica, Firebase, Amplitude или любой отчёт, где видны действия пользователей.
- **Коллега:** Аналитик или разработчик на 15 минут, если вы не знаете названия событий.
- **Период:** Последние 14–30 дней без крупных сбоев и рекламных всплесков.

## Термины простыми словами

- **Воронка — Последовательность шагов от входа до результата:** Определение: Помогает сравнить число пользователей на каждом шаге и найти место с самым большим падением. Пример: Установка → первый запуск → регистрация → первое полезное действие → повторный визит.
- **Конверсия — Доля людей, которые перешли к следующему шагу:** Определение: Показывает, сколько пользователей из начавших шаг завершили его или дошли до следующего. Пример: 80 завершили регистрацию из 100 начавших: конверсия равна 80 ÷ 100 × 100% = 80%.
- **Событие аналитики — Запись о конкретном действии пользователя:** Определение: Приложение отправляет событие в аналитику, когда пользователь открыл экран, нажал кнопку или завершил действие. Пример: registration_started и registration_completed позволяют увидеть, сколько людей бросили регистрацию.
- **FTD — Первый депозит пользователя:** Определение: Первый случай, когда зарегистрированный пользователь пополняет счёт. Это бизнес-результат всего пути, а не отдельная кнопка, которую нужно агрессивнее продвигать. Пример: Если регистрацию закончили 100 человек, а первый депозит сделали 24, FTD-конверсия равна 24%.
- **D1 / D7 / D30 — Возврат через 1, 7 или 30 дней:** Определение: Буква D означает day — день. Метрика показывает, какая доля новой группы пользователей вернулась через выбранное число дней. Пример: D7 = 18% означает: через семь дней вернулись 18 из каждых 100 новых пользователей.
- **Crash-free rate — Доля пользователей без аварийного закрытия приложения:** Определение: Чем ближе показатель к 100%, тем меньше пользователей столкнулись с вылетом приложения за выбранный период. Пример: Crash-free users 99,5% означает, что 0,5% пользователей столкнулись хотя бы с одним вылетом.
- **ANR — Зависание Android-приложения:** Определение: Android фиксирует ANR, когда интерфейс слишком долго не отвечает на действия пользователя. Пример: Пользователь нажал кнопку, экран завис, и Android предложил закрыть приложение.

## Когда применять

Регистраций или первых полезных действий стало меньше, пользователи жалуются на путь, а команде непонятно, что исправлять первым.

## Где взять данные

Выберите тот вариант, который уже есть у команды. Если аналитика не настроена, начните с ручной проверки — практика всё равно даст результат.

- **AppMetrica или Firebase**
  - **Источник:** Откройте отчёт «Воронка» и добавьте: первый запуск → начало регистрации → завершение регистрации → первое полезное действие → повторный визит.
  - **Если доступа нет:** Если названия событий неизвестны, попросите разработчика прислать список событий для регистрации и первого полезного действия.
- **Таблица или BI-отчёт**
  - **Источник:** Возьмите количество пользователей на каждом шаге за один период. Не смешивайте iOS и Android в первой проверке.
  - **Если доступа нет:** Достаточно пяти чисел. Не ждите идеального дашборда, чтобы увидеть грубое падение.
- **Если событий ещё нет**
  - **Источник:** Пройдите путь на чистой установке десять раз на iOS и Android. Запишите ошибки, задержки и непонятные экраны.
  - **Если доступа нет:** Создайте короткое техническое задание на события — это и будет первым результатом аудита.

## Проведите первый аудит за 5 шагов

1. **Нарисуйте путь.** Запишите пять шагов простыми действиями пользователя — без внутренних названий экранов и командных терминов.
   - **Где сделать:** Лист бумаги, FigJam или первая колонка готовой таблицы.
   - **Пример:** Установка → первый запуск → начало регистрации → первое полезное действие → повторный визит.
2. **Поставьте рядом пять чисел.** Укажите, сколько уникальных пользователей дошло до каждого шага за один и тот же период.
   - **Где сделать:** Отчёт «Воронка» в AppMetrica / Firebase или выгрузка от аналитика.
   - **Пример:** 1 000 запустили приложение, 820 начали регистрацию, 460 завершили её.
3. **Посчитайте переход между шагами.** Разделите число на следующем шаге на число на предыдущем и умножьте на 100%. Самый низкий процент — первый кандидат на проверку.
   - **Где сделать:** В таблице рядом с каждым шагом.
   - **Пример:** 460 ÷ 820 × 100% = 56%. Значит, 44% начавших регистрацию её не закончили.
4. **Проверьте причину.** Посмотрите ошибки, обращения в поддержку и пройдите этот шаг вручную. Не меняйте интерфейс, пока не исключили техническую проблему.
   - **Где сделать:** Crash-отчёты, тикеты поддержки и чистая установка приложения.
   - **Пример:** На Android 12 код подтверждения приходит поздно, а повторная отправка не объяснена.
5. **Выберите одно изменение.** Запишите изменение, владельца и метрику, которую сравните после релиза. Не включайте в первый эксперимент сразу несколько экранов.
   - **Где сделать:** Задача в backlog или короткий план ближайшего релиза.
   - **Пример:** Исправить повторную отправку кода; владелец — Android-команда; проверка — конверсия завершения регистрации через 14 дней.

## Примеры из практики

- **Долгая загрузка после регистрации:** Пользователь создал аккаунт, но 40 секунд ждёт первый экран и закрывает приложение. Приоритет — скорость и понятный статус загрузки, а не ещё одно поле формы.
- **Разный путь на платформах:** На Android регистрация завершается заметно реже, чем на iOS. Сначала проверьте ошибки конкретной версии, затем меняйте интерфейс.

## Готовый артефакт: Одна таблица для решения команды

Не нужен большой отчёт. Заполните пять строк и выделите одно падение, которое команда проверит в ближайшем релизе.

| Шаг | Пользователи | Конверсия | Что видим |
| --- | --- | --- | --- |
| Первый запуск | 1 000 | — | Точка отсчёта |
| Начали регистрацию | 820 | 82% | Падение допустимое |
| Завершили регистрацию | 460 | 56% | Главная точка потери |
| Сделали первое полезное действие | 350 | 76% | Проверить подсказки |
| Вернулись на D1 | 150 | 43% | Смотреть после исправления |

Вывод: сначала проверяем регистрацию на Android — ошибки, обязательные поля и время ожидания. Владелец: продукт + Android-разработчик.

## Чек-лист перед решением

Если какого-то пункта нет, зафиксируйте это как отдельную задачу — не угадывайте.

- [ ] Пять шагов названы действиями пользователя, а не экранами команды.
- [ ] Для каждого шага есть число за один и тот же период.
- [ ] iOS и Android проверены отдельно.
- [ ] Технические ошибки и обращения поддержки проверены до изменения интерфейса.
- [ ] Выбрано одно изменение с владельцем и датой проверки.

## Как понять, что изменение помогло

- **Основной сигнал:** Конверсия проблемного шага выросла по сравнению с периодом до релиза.
- **Защитная метрика:** Не выросли ошибки, вылеты и обращения в поддержку на соседних шагах.
- **Бизнес-результат:** Больше пользователей дошли до первого полезного действия и FTD без дополнительного давления.

## Главное правило

FTD — первый депозит пользователя и итог всего пути. Сначала сделайте путь понятным и надёжным, затем проверяйте бизнес-результат.

---

- [HTML-версия](https://playbook.affpartners.io/ru/practices/quality-funnel/index.html)
- [Все практики](https://playbook.affpartners.io/ru/)