Как читать воронку и не принять шум за продуктовую проблему

Что считается началом и успехом

Если считать конверсию записи от всех открытий главной страницы, мы смешаем намерения посетителей. Я предлагаю отдельно смотреть начало целевого сценария и его успешное завершение. В GOV.UK completion rate определяется через завершённые транзакции и начатые попытки; конкретные события для коммерческого продукта всё равно нужно определить самостоятельно.

Записываю определения обычным языком. Начало - пользователь открыл выбор времени; успех - сервер подтвердил запись. Нажатие кнопки "Отправить" ещё не успех: запрос мог завершиться ошибкой. Определения помогают разработчику и аналитику проверять одну и ту же логику.

Словарь событий для записи

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

1. Начало: открыта доступная пользователю форма записи после выбора времени. Простое посещение главной в знаменатель не входит.
2. Успех: сервер создал запись и вернул её подтверждённый статус. Клик по кнопке сам по себе не считается успехом.
3. Единица: одна попытка с техническим идентификатором. Повторные события этой попытки не увеличивают число успехов.
4. Окно: команда заранее определяет, как долго завершение относится к начатой попытке и что делать с возвращением позже.
5. Исключения: тестовые отправки и известные технические события обрабатываются по одинаковому правилу в обоих периодах.

Условный расчёт: из 100 подходящих попыток 60 завершены по этому определению; доля завершения равна 60%. Это арифметический пример, не показатель клиента. Если 10 успешных записей не попали в события, отчёт покажет другую цифру при том же поведении людей.

Одно падение допускает разные объяснения. При исправном сборе событий можно исследовать затруднение в форме. При расхождении с серверным журналом сначала нужно восстановить измерение. Нажмите "Отправить" в тестовом контуре дважды, проверьте ошибку и возвращение к форме: так определение станет проверяемым заданием для разработчика и аналитика.

Проверка событий до сравнения

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

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

Аудитории и окно завершения

Общая конверсия может снизиться из-за изменения состава трафика. Например, увеличилась доля новых посетителей, которые только знакомятся с предложением. Я сравниваю подходящие сегменты и одинаково определённые периоды. Пример объясняет возможную причину, а не утверждает, что она есть у вас.

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

Вопрос, который стоит исследовать

Самая большая потеря не всегда означает самую полезную доработку. Сначала спрашиваю, что человек пытается сделать на этом шаге и какое объяснение подтверждается наблюдениями. Затем выбираю способ проверки.

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