Как найти проблемный шаг заказа в Вебвизоре

Запись визита — это наблюдение

В интернет-магазине видят, что покупатели кладут товар в корзину, но часть не завершает заказ. Есть версия: доставка слишком дорогая. Есть другая: форма ломается на мобильном. Цифра в отчёте показывает место, где маршрут теряет людей, а Вебвизор помогает посмотреть, что происходит на экране. Он не объясняет мотивы человека напрямую, поэтому записи полезнее читать как последовательность наблюдений, а причины формулировать отдельными гипотезами.

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

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

Собери выборку, которую можно сравнить

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

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

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

Как смотреть запись и что выписывать

Сначала прокрути до интересующего шага. Выпиши последовательность действий: где нажал, что появилось, куда прокрутил, какое сообщение увидел, куда ушёл. Отмечай время, состояние интерфейса и повторяемость. Запись «не смог выбрать доставку» слишком общая. Фраза «карта открылась, пользователь нажал на три точки, кнопка подтверждения осталась за нижним краем окна» уже даёт разработчику конкретную проверку.

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

Если смотришь запись вместе с дизайнером и разработчиком, дай каждому сначала описать увиденное своими словами. Иногда одно и то же действие воспринимают по-разному. Дизайнер заметит, что кнопка сливается с фоном. Разработчик увидит, что ответ сервиса приходит позже обновления формы. Менеджер уточнит, что люди звонят по тому же вопросу. Только после этого выбирайте, какую причину проверить первой.

Пример с пунктом выдачи

Допустим, в нескольких мобильных визитах покупатели открывают карту, выбирают пункт, закрывают окно и возвращаются к полю «Адрес». На успешных записях после выбора люди нажимают «Подтвердить» внизу окна. На неуспешных эта кнопка не попадает в видимую часть экрана. Гипотеза звучит конкретно: на небольшом экране после выбора пункта трудно увидеть подтверждение, поэтому адрес не сохраняется.

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

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

Как превратить разбор в задачу

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

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

• Шаг и тип посетителей, которых анализируем.
• Как выглядит нормальный проход и где он прерывается.
• Что повторилось в нескольких записях.
• Как воспроизвести это на тестовом заказе.
• Какое изменение проверяем первым.
• Что сравниваем после публикации и кто смотрит результат.

Где помогают другие инструменты

Воронка Метрики показывает, на каком шаге чаще прекращается маршрут. Записи визитов дают детали интерфейса. Логи сайта и сервисов помогают увидеть техническую причину, например отказ расчёта доставки. Обращения в поддержку подсказывают слова, которыми покупатели объясняют проблему. Вместе эти источники помогают выбрать одно изменение и проверить его, а не перестраивать весь магазин по одному ролику.

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

Быстрая памятка для разбора

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