Задача Иногда у владельцев сервисов, менеджеров проектов и SEO-специалистов возникает желание подсмотреть за пользователем, как он нажимает кнопки и о что ударяется лбом.
Бывает, что такое желание подглядывать позволяет выявить проблемы интерфейса, которые могут косвенно повлиять на эффективность сервиса и даже на прибыль.
Я знаю несколько способов решения этой проблемы:
- набрать группу испытуемых для юзабилити-тестирования;
- интегрировать на сайт сторонний сервис, фиксирующий действия пользователей;
- напишите свое решение.
- требуется тщательно подбирать состав команды тестирования, чтобы в нее входило как можно больше пользователей разных возрастных групп (разумеется, из целевой аудитории), разной квалификации и опыта использования.
При этом имеет значение и размер команды — большее количество позволит получить больше данных для анализа, но и будет стоить дороже;
- необходимо оборудовать место для проведения исследований.
Как минимум офисное помещение, компьютерное оборудование, средства аудио- и видеозаписи;
- необходимо отвлекать сотрудников от основного процесса или привлекать дополнительных для организации процесса и анализа результатов.
Возможно, не в этот раз.
Сторонняя служба аналитики Большинство сервисов предлагают тепловые карты кликов и состояний прокрутки, что позволяет более или менее достоверно определить, что пользователи видели на сайте и на что обратили внимание.
Некоторые предлагают анализ форм, регистрацию ключей, а также отслеживание распределения и копирования, что также может помочь отслеживать сложные шаблоны взаимодействия человека и машины.
Навскидку нашел пару сервисов:
- Вебвизор от Яндекса;
- ХотДжар.
Сервис обещал запомнить и воспроизвести для нас всю сессию пользователя, т.е.
повторить поведение пользователя на ресурсе от начала до конца.
Первоначальное интегрирование тривиально; вам просто нужно добавить код на страницы.
Стоит сразу отметить, что запросы, заведомо разрушительные для состояния сессии (т. е.
все, кроме GET), игнорируются.
Есть две версии.
Принцип их работы примерно одинаковый.
Сначала мы получаем параметры аутентификации пользователя и передаем их на сервер, который загружает текущую страницу и сохраняет ее.
На стороне клиента он собирает действия пользователя: движения мыши, клики, ввод данных и т.д. Реализованный код транслирует действия на сервер с меткой времени (дельта от начала или дата/время, я не выяснил).
Позже вы сможете перейти на страницу пользовательских сессий в сервисе Яндекс.
Метрики и воспроизвести действия пользователя.
Вроде бы все хорошо, но есть ряд проблем.
Версия первая:
- неправильно преобразует события кликов в сложный настраиваемый интерфейс.
В конкретном случае нажатие на значок «крестик» модального окна не закрывает это модальное окно;
- любые действия, приводящие к AJAX-запросам, за исключением GET, нарушаются и поведение интерфейса воспроизводится некорректно, что опять же не дает понимания того, что увидел пользователь;
- случайным образом теряет действия пользователя.
Если у вас есть опыт интеграции со SPA, поделитесь, но у меня подозрение, что и там будут такие же страдания.
Пытаюсь собрать свое решение И тогда мы постепенно приближаемся к моменту «о, дай мне попробовать!» Что необходимо реализовать:
- получение начального состояния страницы.
Не терять пользовательский контекст (у разных пользователей страница может существенно отличаться);
- отслеживание размера оконного объекта;
- Отслеживание прокрутки элементов страницы, в том числе самого документа;
- регистрация активности пользователей.
Контролируйте движения мыши, клики и ввод данных в поля формы;
- компактный протокол обмена серверами.
Начальное состояние
Исходное состояние можно получить двумя способами:- возьмите HTML и стили из события window.load. Это создаст нагрузку на сеть, поэтому при плохом качестве сети придется отказаться от этого варианта;
- запросить страницу на стороне сервера.
Пользовательский контекст должен быть передан.
Вы можете украсть файл cookie неявно или попросить явно передать URL-адрес и параметры авторизации при инициализации библиотеки.
Остается вопрос со стилями и статическими данными.
В целом их можно оставить как есть, но возможны спецэффекты, если статика изменится в момент между получением исходного состояния и моментом просмотра записанной активности.
Когда страница загружается, мы сохраняем текущие размеры объекта окна.
Отслеживание событий
Вам необходимо отслеживать все события поддерева DOM независимо от использования stopImmediatePropagation()/stopPropagation().
Для этого мы будем использовать addEventListener() с параметром useCapture=true. Для отслеживания изменений в структуре и атрибутах документа можно использовать механизм MutationObserver. Для регистрации обработчиков в параметрах инициализации мы будем использовать DOM Node, по умолчанию — document. Вам также необходимо следить за положением прокрутки окна document.scroll и изменением размера window.resize. Чтобы идентифицировать объект события, мы создадим селектор CSS.
Протокол обмена
Из-за отсутствия практических данных для обмена будем использовать формат JSON. Для борьбы с блокировщиками рекламы и прочего следует использовать GET-запросы и возвращать небольшое изображение, например, в формате GIF. Например, URL-адрес /path/to/api/[строка JSON].gif. Стоит помнить, что URL-адрес не резиновый, имеет ограничение в 2000 символов.
Достаточно небольшое значение с учетом отправки информации об изменении структуры документа, поэтому следует сразу побеспокоиться о сжатии данных, например, с помощью алгоритма GZIP, реализация которого существует. Для передачи сжатых данных вам придется дополнительно закодировать их в BASE64. Также нужно будет предусмотреть перенос по частям, но для проверки концепции на данном этапе это будет ненужно.
Нижняя граница
Исходный код прототипа клиентской библиотеки Здесь .Для экспериментов был выбран реальный проект:
- адаптивная верстка (HTML5, CSS3);
- Вяз.
Виджеты (формы регистрации/авторизации, многошаговые формы создания пользовательского контента) и профиля пользователя (SPA);
- Встроенные карты Google.
Созданный трафик оказался не таким большим, как ожидалось.
С учетом ограничений сохранения раз в 10 секунд или, исходя из накопления, 100 событий, объем данных не превышал 4 килобайт. Степень сжатия сильно варьируется от единиц до десятков, но для достаточно больших объемов (десятки килобайт) лежит в районе десятков, что логично, т.к.
данные текстовые и имеется много повторяющихся подстрок.
Нижняя граница Прототип показал свою жизнеспособность.
Чтобы было совсем понятно, необходимо реализовать плеер и серверную часть, где ожидается ряд проблем:
- получение исходного состояния, борьба с дублированием данных.
Возможно, вам придется кэшировать связанные данные.
Есть подозрение, что вам придется использовать headless-браузер для первоначального воспроизведения активности пользователя с целью определения статических элементов;
- Поддержка кроссбраузерного плеера.
Зоопарк и интерверсионное разнообразие никто не отменял.
Например, атрибут style нельзя просто взять через коллекцию атрибутов (Element.attributes), придется использовать свойство HTMLElement.style.cssText. Количество таких нюансов на данный момент оценить невозможно.
Если вы используете headless-браузер с предварительным воспроизведением активности пользователя, то вам следует рассмотреть вариант записи видео.
В этом случае отпадает необходимость в плеере, но увеличивается необходимое количество вычислительных ресурсов и размер получаемого хранилища данных, что не всегда может быть рациональным.
Теги: #вебвизор #Яндекс #аналитика #браузеры #dom #elm #JavaScript #JavaScript #HTML #Веб-аналитика #Интернет-маркетинг
-
Пляж
19 Oct, 24 -
Microsoft Беспокоится Об Odf В Калифорнии
19 Oct, 24 -
Как Тестируют В Google
19 Oct, 24 -
Rails Для Php-Разработчиков
19 Oct, 24 -
Онлайн-Игра «Варвары» Перезапущена
19 Oct, 24
