Отслеживание одностраничных приложений (SPA-сайтов) в Google Analytics 4

Этот материал посвящен отслеживанию одностраничных приложений в Google Analytics 4 с помощью Google Tag Manager.

Обновление: я выпустил электронное руководство по Google Analytics 4. Бесплатно скачать его можно в формате .PDF по ссылке.

Что такое одностраничное приложение? (SPA)

Одностраничное приложение (Single Page Application, сокр. SPA) - веб-сайт или веб-приложение, которое загружает только один HTML-документ, а затем обновляет его содержимое через динамически подгружаемые HTML, CSS, JavaScript, обычно посредством AJAX запросов без перезагрузки страницы.

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

Чаще всего термин одностраничное приложение или Single Page Application применяется к сайтам, разработанным на фреймворках React, Angular, Vue.js, Gatsby.js или аналогичных решениях. Отслеживание хитов/событий на них отличается от настройки для классических сайтов, где при каждом обновлении страницы или переходе на другую в счетчик аналитики передается обращение (hit) просмотра страницы (pageview). Для SPA страница загружается только один раз, в самом начале, а потом необходим механизм для фиксации тех действий, которые совершают пользователи на таком сайте.

Такой функционал заложен в Google Analytics. Он позволяет отправлять "искусственные просмотры страниц" в счетчик аналитики и отслеживать переходы пользователей между страницами даже несмотря на то, что страница загружается только один раз в самом начале и больше не отправляет никаких других просмотров, а также между блоками внутри одной страницы, которые содержат хэш (#) в URL. Страницы, которые мы отслеживаем таким способом (искусственно передаем просмотр в аналитику), называют виртуальными страницами.

Примечание: если вам интересно, как отслеживаются виртуальные страницы в Universal Analytics и Яндекс.Метрике с помощью Google Tag Manager, обязательно прочитайте эту статью.

Виртуальные страницы в Google Analytics 4 можно отслеживать несколькими способами:

• с помощью событий типа Улучшенная статистика;
• с помощью триггера Изменение в истории и соответствующих переменных;
• с помощью уровня данных (dataLayer).

Разберем каждый способ подробнее.

Отслеживание с помощью улучшенной статистики

Улучшенная статистика (Enhanced measurement) - дополнительные события, которые Google собирает автоматически, но после того, как в настройках ресурса вы активируете эту функцию. Предназначена только для потоков данных Сайты.

Они включены по умолчанию в момент создания нового счетчика Google Analytics 4. Если вы по какой-то причине не активировали улучшенную статистику ранее, перейдите в Потоки данных - Веб:

И напротив улучшенной статистики также переведите ползунок в активное состояние:

Для отслеживания виртуальных страниц нам требуются не все события, которые есть в улучшенной статистике, а только Просмотры страниц. Нажмите на иконку шестеренки (1) и раскройте дополнительные настройки (2):

Проверьте, чтобы у вас стояла галочка Изменения состояния страницы в истории браузера (Page changes based on browser history events):

Эта опция позволит GA4 автоматически пытаться отслеживать события каждый раз, когда URL-адрес вашего сайта меняется.

Сохраните все изменения и перейдите в Google Tag Manager, активировав режим предварительного просмотра. В нем вы должны увидеть событие History (Изменение в истории) и его имя события gtm.historyChange-v2:

Если это так, то вы можете выбрать свой идентификатор Google Analytics 4 в верхней части режима отладки и проверить, передаются ли несколько событий просмотра страниц.

Если они фиксируются и данные в GA4 передаются, то вы можете использовать этот способ для отслеживания одностраничных приложений без каких-либо дополнительных настроек со стороны диспетчера тегов Google. Обязательно убедитесь, что в Google Analytics 4 передается событие page_view с правильными параметрами page_title и page_location.

Если вы не видите события History и нет просмотров страниц ни в режиме предварительного просмотра, ни в инструменте DebugView, используйте другой способ отслеживания.

Отслеживание с помощью триггера Изменение в истории

При условии активации триггера Изменение в истории срабатывает событие gtm.historyChange, если изменился фрагмент URL (хеш, #). Но это не всегда хеш. Динамическое окончание в URL может выглядеть как на обычном веб-сайте, например, /home, /contacts и т.д.

В GTM данный триггер можно использовать со встроенными переменными, активируйте их в своем контейнере Google Tag Manager:

• New History Fragment – возвращает переменную, которая содержит новое значение хеша (#) URL-сайта после совершения пользовательского события Изменение в истории;
• Old History Fragment – обратное действие, возвращает переменную, которая содержит предыдущее значение хеша URL-сайта до совершения пользовательского события;
• New History State – возвращает объект, содержащий новое состояние истории после того, как произошло событие и метод history.pushState() был выполнен;
• Old History State – возвращает объект, содержащий старое состояние истории перед тем, как произошло событие и метод history.pushState() был выполнен;
• History Source – возвращает строку-событие, которое привело к изменению объекта истории. Например, pushState или popstate;

Подробнее о методе pushState читайте здесь.

Примечание: если при изменении URL-адреса используется хеш (#), Google Analytics по умолчанию его не перехватит и не отобразит в своих отчетах.

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

Сохраните все изменения и откройте режим отладки диспетчера тегов Google. Перейдите в различные разделы вашего одностраничного приложения/сайта, чтобы изменить URL-адрес. Если на шкале событий вы увидите события History, то вы можете использовать данный способ отслеживания.

Обязательно зайдите в API Call и посмотрите, какие состояния принимают встроенные переменные типа История каждый раз, когда срабатывает событие History:

Например, вот так выглядит уровень данных после нескольких кликов по меню сайта graphanalytics.ru. Переменная gtm.newUrlFragment (New History Fragment) вернуло значение, которое содержало новое значение хеша (#), то есть то состояние, на которое перешел пользователь. Это переход на https://graphanalytics.ru/#book-cover. А переменная gtm.oldUrlFragment (Old History Fragment) вернуло значение, которое содержало предыдущее значение хеша URL-сайта до совершения этого события. В моем примере это https://graphanalytics.ru/#features2. То есть пользователь перешел на странице с блока #features2 (Услуги) на блок #book-cover (Книга). Такие действия пользователя мы можем передавать в Google Analytics как событие, а можем как виртуальный просмотр страницы.

Таким образом, триггер Изменение в истории и встроенные переменные соответствующего типа позволяют отслеживать изменения URL-адреса на вашем сайте, в том числе и хэша. Правда иногда бывают ситуации, когда при совершении одного действия в режиме предварительного просмотра срабатывает сразу же несколько событий History даже если URL-адрес изменился только один раз:

В этом случае вы можете поступить двумя способами:

1. посмотреть уровень данных каждого из отображаемых событий History на шкале, найти уникальное условие активации для одного из них и задать его в качестве дополнительного условия активации самого триггера Изменение в истории в интерфейсе Google Tag Manager. Например, History Source содержит pushState:

Точнее сказать сложно, все зависит от того, какие состояния они у вас принимают в определенный момент времени. Но благодаря этому вы конкретизируете срабатывание триггера и активацию тега только один раз на событие, а не "задваиваете" или "затраиваете" отправку хитов в Google Analytics.

2. использовать другой вариант отслеживания SPA-сайтов - с помощью разработчика и формирования уровня данных (dataLayer), о котором пойдет речь ниже.

Если вам подходит способ отслеживания с помощью триггера Изменение в истории, тогда вы можете создать тег для Google Analytics 4 и передавать эту информацию в счетчик аналитики как событие, поскольку любое обращение в GA4, любой хит - это событие. Даже просмотр страницы, который в Universal Analytics (Google Analytics 3) имеет отдельный тип отслеживания Просмотр страницы, в Google Analytics 4 является событием page_view.

Конфигурация тега Google Analytics 4 так же зависит от вашей реализации. Поскольку мы планируем отслеживать виртуальные просмотры страниц, а у них как и у обычных страниц, как правило, есть URL-адрес (путь к странице) и заголовок (title), то нам необходим механизм извлечения URL-адреса и заголовка с последующей передачей этих данных в GA4.

Если URL-адреса вашего веб-сайта содержат #, то вы можете использовать команду window.location.href - свойство объекта Location, которое возвращается весь URL-адрес, включая хэш:

Чтобы передать полный URL-адрес в Google Analytics 4, создайте переменную типа Переменная JavaScript с именем window.location.href:

Полный URL-адрес мы определили. Теперь необходимо найти способ передачи заголовка страницы. Сделать это не так просто, как кажется на первый взгляд, потому что вы можете отслеживать не только переходы со страницы на страницу, но и создавать "искусственный просмотр" для перехода между блоками, как это было в примере выше (с одного якоря/блока # на другой якорь/блок # страницы). А раз это одна страница сайта, то у блоков изначально нет никаких заголовков. Но мы можем назначить каждому блоку свое собственное значение заголовка с помощью пользовательской переменной Таблица регулярных выражений, используя в качетсве входного параметра переменную window.location.href, созданную на предыдущем шаге.

Для этого создайте переменную типа Таблица регулярных выражений, и задайте для нее следующие настройки:

• Входная переменная - window.location.href;
• Шаблоны (входящие значения) - фрагменты URL-адреса после хэша #, которые есть у вас на сайте. Как правило, они всегда идут в самом конце ссылки, после всех параметров, включая utm_метки, поэтому в конце я использую символ регулярного выражения $ (заканчивается на);
• Результат - введите в эти поля названия заголовков, которые хотите отправлять с тегом Google Analytics 4 в параметре page_title;
• Advanced Settings - уберите галочки с Только полное соответствие и Включите группы для извлечения подстроки и функцию замены.

Таким образом, когда пользователь перейдет на блок #price, в переменную подставится значение Тарифы, когда перейдет на URL-адрес, содержащий фрагмент #features2, то в переменную запишется значение Услуги, и когда на #book-cover - переменной присвоится значение Книга. Вот как это будет выглядеть в режиме отладки GTM на вкладке Variables:

Теперь мы можем создать тег Google Аналитика: событие GA4 и передать эту информацию в аналитику. Установите следующие настройки:

• Тег конфигурации - ваш Google Analytics 4;
• Название события - page_view;
• Параметры события - page_location и page_title со значениями переменных, созданных на предыдущих шагах;
• Триггер активации - Изменение в истории.

Если URL-адреса вашего веб-сайта не содержат # и вы не планируете переопределять заголовок виртуальной страницы, тогда тег будет точно таким же, только без дополнительных параметров событий:

Сохраните тег. Единственный вопрос, который остался открытым - это галочка Отправлять просмотр страницы, когда загружается эта конфигурация в теге конфигурации GA4:

Нужна ли она, если у вас Single Page Application? Вы должны проверить, что происходит после загрузки/перезагрузки страницы вашего одностраничного приложения. Появляется ли событие History каждый раз, когда вы перезагружаете страницу?

Если да, тогда вы должны убрать галочку, поскольку при такой реализации будет происходить "задубливание данных" - один раз хит отправится от тега конфигурации GA4, а другой от события GA4. Если события History не появляются сразу после обновления страницы, а срабатывают только тогда, когда вы начинаете перемещаться по своему сайту, то эту галочку следует оставить активной.

Проверить корректность передачи данных и отправку виртуальных страниц можно с помощью режима отладки GTM и инструмента DebugView в Google Analytics 4. Как только вы начнется перемещаться по сайту, вы должны увидеть событие History и активированный тег:

А в DebugView вы увидите событие page_view с переопределенными параметрами событий page_location и page_title, которые мы добавили в итоговый тег несколькими шагами ранее:

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

Отслеживание с помощью уровня данных (dataLayer) и разработчика

Самый универсальный и действенный способ отслеживания Single Page Application - это попросить разработчика добавить код dataLayer.push на те элементы страницы сайта, которые вы хотите фиксировать и передавать в качестве виртуальных страниц, когда пользователь перемещается между ними.

Пример кода, который разработчик может использовать:

Примечание:  переменные pagePath и pageTitle должны динамически изменяться на URL-адрес и заголовок страницы, которую в данный момент времени просматривает пользователь.

Например, для сайта graphanalytics.ru для отслеживания переходов между блоками разработчик должен добавить такие конструкции кода:

pagePath - это URL-адрес, значение для page_location, а pageTitle - заголовок виртуальной страницы, значение для page_title.

Такие конструкции можно добавлять не только на меню навигации, содержащее якорь (#), но и на другие элементы и события, включая нажатие на кнопку, открытие попапа, отправку формы и т.д. Перечень отслеживаемых элементов для своего SPA-сайта определяете вы вместе с программистом.

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

Вы также должны создать триггер типа Специальное событие с именем Pageview (как в примере кода):

На заключительном шаге создайте тег Google Аналитика: событие GA4 со следующими настройками:

• Тег конфигурации - ваш Google Analytics 4;
• Название события - page_view;
• Параметры события - page_location и page_title со значениями переменных, созданных на предыдущих шагах;
• Триггер активации - Pageview.

Проверить корректность передачи данных и отправку виртуальных страниц этим способом можно с помощью все тех же инструментов - режима отладки GTM и DebugView в Google Analytics 4. Как только вы начнется перемещаться по сайту и кликать по тем элементам, где ваш программист добавил дополнительный код уровня данных с событием, или вызывать тот контент, который подгружается на сайте динамически без перезагрузки страницы, на шкале событий диспетчера тегов Google должны появляться новые события Pageview:

Открыв настройки тега, вы увидите значения параметров событий, которые динамически подставляются в параметры page_location и page_title из pagePath и pageTitle соответственно, в зависимости от того, какое действие вы совершаете на своем сайте.

А в DebugView это будет выглядеть так:

Резюме

Отслеживание одностраничных приложений (SPA-сайтов) отличается от классических сайтов, где при каждом обновлении страницы или переходе на другую в счетчик аналитики передается обращение (hit) просмотра страницы (pageview). Для SPA страница загружается только один раз, в самом начале, а потом необходим механизм для фиксации тех действий, которые совершают пользователи на таком сайте.

Мы с вами рассмотрели три способа отслеживания Single Page Application для Google Analytics 4:

• с помощью событий типа Улучшенная статистика (встроенный, без использования Google Tag Manager);
• с помощью триггера Изменение в истории (History) и встроенных переменных (с использованием Google Tag Manager);
• с помощью сформированного уровня данных (dataLayer) и разработчика (с использованием Google Tag Manager).

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