Где теряются пользователи —
и всегда ли это проблема?

1. Начните с пользовательской задачи

Продолжим пример сервиса записи к специалистам. Человеку нужно выбрать подходящее время и получить консультацию. Для исследования этого пути возьмём четыре шага: начало записи, выбор времени, подтверждение записи и состоявшаяся консультация.

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

У каждого шага должен быть понятный смысл. «Нажал подтвердить» и «система создала запись» — разные события. Во втором случае мы ближе к результату, а первое полезно для отдельной диагностики ошибок формы.

2. Договоритесь, кого и как считать

В учебном примере считаем пользователей, начавших запись в выбранную неделю. Единица — внутренний ID пользователя, а не браузер и не число кликов. Каждому даём 21 сутки после первого начала записи в этой неделе.

Начало другой попытки не продлевает окно. Каждый пользователь входит в число прошедших шаг один раз. Для такой логики нужен идентификатор попытки и связь с записью; если этих данных нет, нельзя молча считать, что разрозненные события относятся к одному процессу.

Это воронка с обязательным первым шагом: люди, которые пришли сразу к подтверждению из другого канала, сюда не входят. Для них нужен отдельный путь. Если разрешить вход с любого шага, смысл показателей изменится — такие варианты нельзя сравнивать без оговорок.

3. Посмотрите и доли, и количество

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

Общая конверсия: 1 184 ÷ 2 843 × 100% = 41,65%. Она отвечает на вопрос о результате всего пути. Переход от выбора времени к подтверждению: 1 329 ÷ 1 967 × 100% = 67,56%. Он помогает локализовать участок исследования.

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

4. Отсев бывает следствием правил, а не поломки

Пользователь достиг результата другим путём

Он мог записаться через оператора или повторить прошлую запись без нового выбора времени. Для общей оценки продукта этот результат важен. Но воронка именно нового выбора времени его не описывает. Сначала решите, исследуете ли вы конкретный интерфейс или все способы получить услугу.

Пользователь ещё не готов

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

У продукта нет подходящего предложения

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

Событие потерялось

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

5. Повторные попытки не должны ломать смысл

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

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

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

6. Самый большой отсев — ещё не первый приоритет

В примере 876 пользователей не дошли до выбора времени, а между выбором и подтверждением потерялись 638. Первая потеря больше, но это не доказывает, что начинать нужно с неё.

Допустим, на втором участке обнаружена воспроизводимая ошибка подтверждения. Для оценки масштаба можно построить сценарий: увеличение перехода на 3 процентных пункта среди 1 967 пользователей даст примерно 59 дополнительных подтверждений.

Если последующий переход останется на уровне 1 184 ÷ 1 329, это около 53 дополнительных пользователей с консультацией. Это расчёт сценария, а не прогноз и не доказанный эффект. Он предполагает неизменность состава аудитории, дальнейшей конверсии и достаточное число свободных консультаций.

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

7. Как проверить воронку перед обсуждением

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

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

Следующая статья

Разберём, почему пользователи возвращаются и как читать изменения retention.