Анализируем навигацию посетителей с помощью вкладок браузера

Настроим отслеживание, соберем разрозненные данные в навигационный отчет и проанализируем перемещение посетителей по сайту.

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

С этой целью справляется Analytics. Например, посетитель зашел на главную страницу, а затем перешел на страницу контактов. Analytics в этом случае объединит два «просмотра» посетителя в навигационное поведение.

Если посетитель откроет страницу на отдельной вкладке и не заглянет в нее, Analytics засчитает это за просмотр. Если посетитель обновит текущую страницу, Analytics засчитает это за переход. Analytics также не видит разницы между переходом по ссылке, вводом адреса напрямую и нажатием кнопки «назад». Можно попытаться сформировать «Карту поведения» — отчет, который должен выявить закономерности в переходах посетителей, но его тяжело анализировать и он порой показывает невозможные сценарии перехода. Получается, что в реальности анализировать навигацию посетителя по сайту сложно.


Отчет «Карта поведения»

Проблема усугубляется тем, что каждая вкладка создает в браузере свою сессию (не путайте с сессиями в Analytics). Analytics пытается показать перемещение посетителя как линейную последовательность, но в действительности эта последовательность нелинейна и имеет древовидную структуру:


Основные сведения о визуализации переходов

В Analytics «переходы» созданы для рекламных кампаний, поэтому не учитывают перемещение внутри сайта. Чтобы фиксировать переходы, нам понадобятся «специальные параметры и показатели».

Итак, проблема: инструменты аналитики сводят непредсказуемую пользовательскую навигацию к линейной последовательности. Мы предлагаем добавить новый пункт в схему обработки браузерного поведения в Analytics:

БЫЛО: Пользователь > Сессия > Обращение
СТАЛО: Пользователь > Сессия > Вкладка > Обращение

Это поведение будет настроено в «специальных параметрах и показателях»: вы сможете получать информацию напрямую, без обращения к «Просмотрам страницы».

Подготавливаем решение

В Analytics нельзя анализировать вкладки браузера и контекстное меню, поэтому мы не узнаем, открыл ли посетитель страницу в новой вкладке:

Пример контекстного меню

Хорошая новость: то, что нельзя в веб-аналитике отследить напрямую, можно отследить косвенно. Например, нельзя отследить, оставил ли посетитель заявку на покупку, но можно понять косвенно — через автоматический переход посетителя на страницу с деталями заказа. Мы используем похожий прием со вкладками браузера: если каждой вкладке присваивать отдельный идентификатор, мы сможем по отдельности отслеживать навигацию посетителя по сайту.

Для этого нам понадобится объект PerformanceNavigation и связка из двух свойств: localStorage и sessionStorage.

PerformanceNavigation определяет тип навигации и помогает отследить перемещения посетителей по сайту. У него 2 параметра:

performance.navigation.type — определяет, каким образом посетитель перешел на страницу:

  • TYPE_NAVIGATE (0) Через ссылку, закладку, форму подтверждения, скрипт или адресную строку.
  • TYPE_RELOAD (1) Через кнопку «обновить страницу».
  • TYPE_BACK_FORWARD (2) Через историю в браузере или с помощью кнопок «назад»/«вперед».
  • TYPE_RESERVED (255) Прочим способом.

performance.navigation.redirectCount — число переадресаций, через которые страница стала доступна.

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

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

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

Когда мы объединим метаданные из PerformanceNavigation и связку localStorage + sessionStorage, мы получим пользовательский параметр, который поможет отслеживать перемещение посетителей по вашему сайту.

Сложности решения

Решение, к которому мы придем, основывается на нестабильных компонентах, которые зависят от поведения браузеров в разных ситуациях.

Кросс-доменные переходы. sessionStorage и localStorage ограничены только доменом вашего сайта. Если некоторые страницы вашего сайта работают с разными протоколами (HTTP и HTTPS), то это 2 разных домена, а значит каждый домен будет плодить свои идентификаторы вкладок. В этом случае лучше перевести сайт на HTTPS и придерживаться одного протокола.

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

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

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

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

Решение

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

Пользовательский HTML-тег. Создадим пользовательский HTML-тег и добавим в него этот код:

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

Код в Custom HTML делает несколько вещей:

— Генерирует идентификатор вкладки для страницы, которая находится в sessionStorage. Если сгенерирован новый идентификатор, то страница помечается как открытая в новой вкладке. Если идентификатор уже был в хранилище, то страница помечается как существующая в текущей вкладке.

— Этот идентификатор вкладки также хранится в массиве внутри localStorage, где хранятся все идентификаторы вкладок, сгенерированные на сайте. Длина массива — число открытых в данный момент вкладок на сайте.

— Когда посетитель покинет страницу, закроет вкладку или браузер, то идентификатор, чтобы поддерживать точное число открытых вкладок, удалится из массива localStorage,

— Если страница была загружена после нажатия на ссылку или напрямую через адресную строку браузера, то текущая страница попадает в массив в sessionStorage.

— Если страница была перезагружена, тип навигации помечается как RELOAD. Навигационный путь остается без изменений.

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

— Число вкладок, переадресаций, навигационных типов, идентификаторов и состояний вкладок (новая или существующая) — все это добавляется в модель данных GTM, чтобы тег просмотра страниц смог взять значения из переменных Data Layer.

Теперь, когда мы добавляем всю информацию в Data Layer, настало время собрать метаданные и отправить их в Analytics.

Создайте специальные параметры в Analytics с областью действия hit:

Redirect count — Число переадресаций
Navigation type — Тип навигации
Tab type — Тип вкладки
Tabs open — Вкладки открыты
Tab ID — Идентификатор вкладки

Создайте переменные уровня данных (Data Layer) в GTM:

Пример того, как выглядит одна из переменных:

Добавьте переменную уровня данных (Data Layer) в тег просмотра страницы. Откройте тег просмотра страницы, который вы уже отредактировали для последовательности тегов в начале этой главы. Добавить переменную уровня данных можно тремя способами: прикрутить к нужному индексу, вбить напрямую в поле тега или через настройки переменной в Analytics.

Протестируйте решение. Сохраните тег, зайдите в «Предварительный просмотр» и перейдите на свой сайт.

Поскольку вы обновляете модель данных через последовательность тегов, вы не сможете использовать предварительный просмотр, чтобы убедиться, что переменные Data Layer заполняется корректно. Вам придется либо смотреть на сетевые запросы напрямую, или использовать инструмент Google Tag Assistant recordings или Google Analytics Debugger, чтобы убедиться, что данные отправляются корректно.

Если все настроено правильно, в «специальном параметре» начнет собираться нужная информация.

Отчет Google Tag Assistant Recordings

Специальный (пользовательский) отчет в Analytics. Создайте специальный отчет в Analytics, чтобы держать всю информацию в одном месте. Пример настроек:


Этот отчет содержит информацию о том, как пользователи перемещаются по разным страницам на сайте.


Добавьте к отчету идентификатор сессии (Session ID) и время обращения (Hit Timestamp), и вы начнете лучше понимать навигацию посетителей на своем сайте.

Что в итоге

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

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

 

По материалам статьи Симо Ахавы Track Browsing Behavior In Google Analytics

Полезные материалы:
GTM. Как отслеживать прокрутку на сайте

Руководство: как перенести сайт

Работа с офлайн-пользователями в Google Analytics

Разница между кликами, сеансами, пользователями, входами, просмотрами страниц и уникальными просмотрами страниц