Вебвизор: как искать препятствия в интерфейсе, а не гадать по записям

Редакция Romanov Lab · Опубликовано 13 октября 2026

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

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

Сформулируйте вопрос до просмотра

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

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

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

Убедитесь, что запись пригодна для анализа

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

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

Также проверьте, доступен ли нужный период. У сервиса есть ограничения хранения и количества записей; их актуальные условия приведены в той же документации. Список воспроизведений нельзя без дополнительной проверки объявлять полным журналом всех визитов.

Защитите содержание до начала исследования

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

В настройках Вебвизора предусмотрены запрет записи содержимого полей и CSS-классы: ym-disable-keys для полей, ym-hide-content для скрытия элементов. Это разные области защиты. Маскирование поля не скрывает автоматически то же значение, если приложение после отправки вывело его обычным текстом.

Проверяйте страницы подтверждения, меню профиля, сообщения об ошибке и всплывающие подсказки на искусственных данных. Автоматическое распознавание конфиденциального поля не заменяет такой проверки. Отдельно убедитесь, что сбор соответствует настройкам согласия и правилам организации; это не решается одним CSS-классом.

Записывайте факт отдельно от объяснения

Хорошая заметка выглядит так: «На узком экране посетитель трижды нажал на область выбора пункта выдачи; карта не изменилась; затем открылся другой раздел». Плохая заметка: «Посетитель не понял доставку и разозлился». Во втором случае наблюдение незаметно заменено предположением о мыслях человека.

Карточка наблюдения может содержать страницу, устройство, место в сценарии, последовательность действий, ожидаемую реакцию интерфейса, фактическую реакцию и альтернативные объяснения. Идентификатор записи храните только в рабочем доступе команды, а в общие материалы переносите обезличенное описание.

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

Эти варианты не нужно все проверять одинаково глубоко. Они нужны, чтобы не выбрать первое удобное объяснение и не переделать работающий интерфейс.

Учебный пример: кнопка под мобильной клавиатурой

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

Команда повторяет сценарий на соответствующих устройствах: фокусирует последнее поле, вызывает ошибку, пробует прокрутку и закрытие клавиатуры. Если кнопка действительно остаётся вне доступной области, фиксируется воспроизводимый дефект. Если на устройствах всё работает, проверяют особенности записи и ищут другое объяснение.

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

Оцените охват, не превращая выборку в статистику сайта

Фраза «в четырёх из десяти просмотренных записей была проблема» описывает только выбранные записи. Если они заранее отобраны по ошибке, нельзя утверждать, что проблема затрагивает 40% посетителей. Эти учебные числа иллюстрируют ошибку вывода, а не результат исследования.

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

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

Превратите находку в задание на исправление

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

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

Критерии законченного исследования

1. Известны вопрос, способ отбора и ограничения пригодности записей.
2. Факты отделены от интерпретаций, для значимых находок рассмотрены альтернативные объяснения.
3. Препятствие воспроизведено либо прямо обозначено как неподтверждённая гипотеза.
4. Охват оценён по подходящим данным или оставлен неизвестным без выдуманного процента.
5. Есть конкретное действие и проверка после изменения, а личные сведения не попали в рабочие материалы без необходимости.

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