Общий тег событий для Google Analytics 4
Перевод статьи Дэвида Вальехо (David Vallejo), в которой он описывает процесс отслеживания событий Google Analytics 4 с помощью одного тега в Google Tag Manager.
Обновление: я выпустил электронное руководство по Google Analytics 4. Бесплатно скачать его можно в формате .PDF по ссылке.
Вступление
Если вы используете Google Tag Manager для настройки Google Analytics 4, возможно, вы заметили необходимость создания отдельного тега для каждого события, которое хотите отслеживать (в GA4 рекомендуемый подход: 1 событие - 1 триггер - 1 тег). Хоть это и дает простую для понимания картину всех используемых событий, так как снижается риск возникновения ошибки, в то же время это может добавить вам сложностей в будущем, когда количество таких триггеров и тегов в рабочей области GTM будет исчисляться сотнями.
В Universal Analytics для упрощения работы с контейнером можно воспользоваться универсальным способом отслеживания событий с помощью конструкции dataLayer (уровень данных), используя общий синтаксис:
|
1 2 3 4 5 6 7 8 |
window.dataLayer = window.dataLayer || []; dataLayer.push({ 'event': 'eventName', 'category': 'eventCategory', 'action': 'eventAction', 'label': 'eventLabel', 'value' : 'eventValue' }); |
, где:
- 'event': 'eventName' - неизменное название для ваших событий (может быть другим);
- 'category': 'eventCategory' - категория события (может быть другим);
- 'action': 'eventAction' - действие события (может быть другим);
- 'label': 'eventLabel' - ярлык события (может быть другим);
- 'value' : 'eventValue' - ценность события (может быть другим).
Таким образом, разработчик на все отслеживаемые элементы на вашем сайте может добавить общий уровень данных с уникальным названием события (будет одно для всех), которое вы зададите, а Категория, Действие, Ярлык и Ценность для каждого события будет меняться и подставляться автоматически в зависимости от того, какое действие пользователь совершит. В результате, вместо комбинации 1 событие - 1 триггер - 1 тег в Universal Analytics вы создаете 4 переменных, 1 триггер и 1 тег на все события, что значительно сокращает количество сущностей. В моем блоге есть отдельная статья на эту тему, в которой подробно описывается последовательность такой настройки.
В Google Analytics 4 так сделать нельзя, потому что конструкция отслеживаемого события отличается от Universal Analytics, и вместо привычных eventCategory, eventAction, eventLabel, eventValue используются параметры событий, значений которых мы должны индивидуально сопоставить с каждым из событий, которое настраиваем.
Но решение есть, оно описано в статье Дэвида (спасибо!) и позволяет использовать только один GA4 тег события, сохраняя при этом все возможности и функциональность, которые были бы у нас, если бы мы настраивали отдельные теги для каждого события.
Определение наших push-уровней dataLayer
Первое, что нужно сделать, это определить, как мы собираемся передавать данные в dataLayer. Это можно сделать так:
|
1 2 3 4 5 6 7 8 9 10 11 |
window.dataLayer.push({ 'event': 'my_action_name', 'event_params': { 'param1': 'value1', 'param2': 'value2' }, 'user_properties': { 'prop1': 'value1', 'prop2': 'value2' } }) |
На этом этапе вы можете задаться вопросом, почему мы группируем параметры событий, а не просто помещаем их в метод .push(), например так:
|
1 2 3 4 5 6 7 |
window.dataLayer.push({ 'event': 'my_action_name', 'param1': 'value1', 'param2': 'value2' 'prop1': 'value1', 'prop2': 'value2' }) |
Примечание: метод .push() добавляет один или более элементов в конец массива и возвращает новую длину массива, то есть изменяется исходный массив (он становится больше), а старые значения не перезаписываются.
На это есть причина: dataLayer в Google Tag Manager является кумулятивным. Это означает, что все новые передаваемые данные продолжают добавляться во внутреннюю модель данных, от события к событию. И когда мы будем отслеживать событие с параметром param1, то он будет доступен не только для текущего события, но и для последующих. А поскольку мы хотим использовать один общий тег событий, то эти данные будут добавлены к следующим событиям.
Чтобы справиться с этим, в диспетчере тегов Google необходимо использовать переменную уровня данных версии 1 для чтения параметров событий и свойств пользователей, поскольку все данные, находящиеся в этих ключах, будут переопределяться при всех нажатиях:
Версия уровня данных 1
Разница версий переменной уровня данных:
- Версия 1 не поддерживает вложенную нотацию, ключи перезаписываются, а не объединяются;
- Версия 2 поддерживает нотацию вложенных объектов (ecommerce.purchase.actionField.id) и ключи объединяются.
Дэвид в своей статье приводит наглядный пример, чтобы вы лучше поняли отличия в версиях. Допустим, у нас есть 2 push-уведомления dataLayer, выполненные поочередно, к каждому из которых прикреплен свой параметр события:
|
1 2 3 4 5 6 |
window.dataLayer.push({ 'event': 'outgoing_click', 'event_params': { 'clicked_url': 'David Vallejo' } }); |
Параметр события - clicked_url
|
1 2 3 4 5 6 |
window.dataLayer.push({ 'event': 'tab', 'event_params': { 'tab_id': '1' } }): |
Параметр события - tab_id
Затем в Google Tag Manager мы создаем две переменные типа Переменная уровня данных с названиями {{dl - clicked_url}} и {{dl - tab_id}} соответственно. В зависимости от того, какую версию мы будем использовать, они будут принимать разные значения:
Сравнение результата
Если мы используем версию 2, второе событие закончилось бы присоединением значения clicked_url к событию, чего мы не хотим.
Основной тег события
Перейдите в Google Tag Manager и создайте тег типа Google Аналитика: событие GA4. Задайте название события, которое будет динамически подставляться из встроенной переменной {{Event}} и считывать фактическое значения push-события из dataLayer, а затем передавать его в название события:
Тег с названием события из {{Event}}
Пока это все, что необходимо сделать, прежде чем начать сопоставлять параметры событий (event_params) и свойства пользователей (user_properties).
Переменные
Как вы уже поняли, необходимо использовать переменные уровня данных с версией 1. Но мы также знаем, что этот тип переменной не поддерживает вложенные значения. Обходной путь для этого - использовать переменную типа Собственный код JavaScript, которая будет захватывать основной ключ (user_properties , event_params), а затем возвращать нам значения, которые нужны.
Для примера выше создадим переменную уровня данных с версией 1 для параметров событий (event_params):
event_params для параметров событий
И такую же переменную уровня данных с версией для свойств пользователей (user_properties):
user_properties для свойств пользователей
Следующий шаг - создание переменной для каждого из значений, к которым мы хотим иметь доступ. В нашем случае их 2 - {{dl - clicked_url}} и {{dl - tab_id}}. Создайте пользовательские переменные типа Собственный код JavaScript со следующим кодом (актуален только для этого примера!):
|
1 2 3 |
function () { return {{dl - event_params - v1}}.clicked_url; } |
В Google Tag Manager:
Извлечение значения из параметра события clicked_url
И:
|
1 2 3 |
function () { return {{dl - event_params - v1}}.tab_id; } |
В Google Tag Manager:
Извлечение значения из параметра события tab_id
Вместо того, чтобы читать их из dataLayer, мы читаем их из созданной переменной уровня данных с версией 1. Это приведет к тому, что параметры событий (event_params) будут сбрасываться каждый раз, а значения будут неопределенными для параметров, которые не добавляются к текущему push-уведомлению. Функционально это похоже на то, что все события/пользовательские данные будут «сброшены» при каждом совершении события.
Добавление параметров события в тег
Вернитесь к своему тегу, созданному на предыдущем шаге, и добавьте все параметры событий, которые вы определили для себя. В примере Дэвида их два, но их может быть и больше:
Тег события с параметрами
Настройка триггера
А как быть с триггером? Если в Google Analytics 4 рекомендуется настраивать для каждого события свой собственный триггер, а здесь мы используем один общий тег, то как его активировать и в каких случаях? Здесь нам на помощь придет универсальный триггер с регулярным выражением .*, который будет запускать события только в том случае, если они находятся в таблице поиска.
Таблица поиска
Создайте переменную типа Таблица поиска и для каждого входного события определите выходное значение, задав ему цифру 1. В примерах Дэвида названия событий были 'event':'outgoing_click' и 'event':'tab', поэтому итоговая таблица поиска будет выглядеть следующим образом:
Таблица поиска
В таблице поиска в качестве входных значений вы перечисляете все названия событий, которые определили для своего проекта и которые разработчик внедрил на отслеживаемые элементы на сайте. В поле Результат введите 1, а значение по умолчанию установите 0. Если текущего события нет в этом списке, оно не не будет активироваит ваш тег события GA4.
Эта переменная будет использоваться в условии триггера типа Специальное событие:
Триггер на специальное событие
Не забудьте поставить галочку Использовать регулярные выражения.
Общий тег события
В завершение вы этот триггер добавляете к своему общему тегу событий:
Общий тег событий для Google Analytics 4
Не забудьте проверить корректность настройки и опубликовать изменения контейнера.
Резюме
Эти действия могут показаться сложными и более запутанным, чем просто создавать триггер на каждое событие и тег со своими параметрами событий и свойствами пользователей. Но для тех, кто работает с большими проектами, где десятки и сотни различных переменных, триггеров и тегов, разложенных по разным папкам, это решение окажется полезным.
Вам лишь нужно:
- настроить один единственный тег;
- использовать таблицу поиска для контроля и просмотра того, какие события определены и запущены;
- использовать общий триггер специального события с регулярным выражениям и условием проверки из таблицы поиска.
