Отслеживайте качество вашего dataLayer в режиме реального времени с помощью Google Tag Manager и Firebase.

В своей первой статье на Medium я объяснил, как можно использовать addEventCallBack API Google Tag Manager в сочетании с функциями Firebase и базой данных в реальном времени, чтобы отслеживать и получать уведомления, когда теги не загружаются.

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

Внедрение этого монитора dataLayer поможет вам сделать следующий шаг в улучшении качества ваших данных с помощью управления тегами.

Бизнес-кейс Customer ID

Допустим, ваш веб-сайт или приложение загружает идентификаторы клиентов, когда пользователь (автоматически) входит в систему, в слой данных, чтобы каждое обращение, отправляемое в Google Analytics, содержало этот идентификатор. Это лучшая практика, поскольку она позволит вам или вашим аналитикам более детально отслеживать поведение пользователей.

Можете ли вы представить, каковы будут последствия, если этот идентификатор клиента не загрузится должным образом? Точно. Я видел этот сценарий из первых рук с клиентом, и потребовалось 2 недели, чтобы узнать об ошибке, и еще несколько дней, чтобы исправить проблему.

Что делать? Тогда вообще ничего. Теперь вы можете использовать мой собственный шаблон Диспетчера тегов Google и функцию Firebase с базой данных Firebase Real-Time, чтобы получать уведомления, когда это происходит.

Можете ли вы придумать какие-нибудь кейсы для себя? У меня уже есть список для моих клиентов. Это решение чрезвычайно универсально.

Шаблон монитора DataLayer

У этого решения есть 2 аспекта:

1. Пользовательский шаблон Диспетчера тегов Google
2. Учетная запись Firebase с активированными функциями и базой данных в реальном времени

Во-первых, пользовательский шаблон Google Tag Manager. Этот шаблон позволит вам сделать 2 основные вещи:

1. Определите, какие значения dataLayer вы хотите проверить, по какому условию и по конкретному значению.
2. Определите конечную точку для отправки неудачных проверок для мониторинга и уведомлений в реальном времени, как и в моем предыдущем решении.

Пользовательский шаблон позволяет выполнять условные проверки, такие как:

• равно
• содержать
• начинается с
• заканчивается
• не равно (включает проверку undefined)
• не содержит
• не начинается с
• не заканчивается
• имеет длину (для проверки длины строки)

Как вы можете быстро убедиться, условные проверки, связанные с регулярными выражениями, отсутствуют. Это связано с тем, что песочница пользовательских шаблонов Google Tag Manager не поддерживает эту функцию. Таким образом, хотя теоретически вы можете ввести аргумент регулярного выражения в последнее поле, в коде нет способа изменить это значение со строки на аргумент регулярного выражения. Как только это произойдет, я обновлю шаблон.

Другие элементы, которые отсутствуют, — это ваши количественные условные проверки, такие как less than или greater than or equal to. Опять же, это связано с невозможностью изменить тип значения последнего поля со строки на число. Например, parseFloat не распознается.

Особое условие — does not equal, в которое я встроил функцию проверки undefined типов. Я надеюсь, что это поможет некоторым из вас преодолеть это препятствие при проверке неопределенных значений.

Чтобы дополнительно компенсировать отсутствие проверки регулярных выражений, я добавил has length of к опции, с помощью которой вы можете проверить, имеет ли значение dataLayer по крайней мере определенную длину, такую ​​как идентификаторы клиентов, идентификаторы транзакций и т. д.

Что вам понадобится?

Предпосылки такие же, как и для моей ранее задокументированной системы уведомлений в реальном времени.

1. IDE, для редактирования кода
2. Узел на локальном компьютере для установки Firebase Tools
3. Аккаунт Firebase с включенным планом Blaze
4. Инструменты Firebase от NPM
5. учетная запись Zapier
6. Скрипт Firebase Functions (репозиторий Github)
7. мой пользовательский шаблон DataLayer Monitor (репозиторий Github)

Как реализовать свой монитор dataLayer?

ШАГ 1 Загрузите или клонируйте оба репозитория Github.

ШАГ 2 Настройте Firebase, создав проект, активируйте функции и базы данных, а затем разверните скрипт функций. Выполните шаги с 1 по 7 в другой моей статье со скриптом новых функций.

ШАГ 3 Скопируйте и сохраните URL-адрес конечной точки функции Firebase и подготовьте его для использования в шаблоне тега в Диспетчере тегов Google.

ШАГ 4. Импортируйте пользовательский шаблон в Диспетчер тегов Google.

ШАГ 5.Создайте новый тег в Диспетчере тегов Google, используя новый шаблон, и назначьте ему триггер для Всех страниц и, если хотите, также для всех событий.
Последнее можно сделать, создав триггер с помощью шаблона Custom Event. Введите .* в качестве имени события и установите флажок Использовать сопоставление регулярных выражений. Это должно выглядеть примерно так:

ШАГ 6 Заполните ключи dataLayer в теге пользовательского шаблона dataLayer Monitor, который вы только что создали на шаге 4, значениями, которые вы хотите отслеживать.

dataLayer = [{
'customerId': '123456789',
'country':'nl',
'meta': {
    'path':'/some/path',
    'title':'Some Title'
  }
}];

Теперь предположим, что ваш dataLayer был установлен при загрузке страницы и содержит значения из приведенного выше примера.

В поля DataLayer Key вы можете ввести следующие значения для каждого:

• Пользовательский ИД
• страна
• мета.путь
• мета.заголовок

ПРЕДОСТЕРЕЖЕНИЕ В настоящее время существует одна проблема со чтением ключей dataLayer из пользовательского шаблона. Диспетчер тегов Google по умолчанию не позволит вам получить доступ к корневому уровню данных. На вкладке «Разрешения» шаблона вам нужно будет ввести все ключи dataLayer, которые вы хотите отслеживать, прежде чем вы сможете сохранить свой тег.

Вы можете использовать точечную нотацию для перехода по dataLayer на более глубокие уровни.

Теперь ваш тег должен выглядеть так:

Теперь нам нужно добавить условные операторы. Давайте использовать следующее:

• идентификатор клиента имеет длину 9 цифр/символов
• страна имеет длину 2 символа
• meta.path не равно undefined
• meta.title содержит тегицианов

Теперь ваш тег будет выглядеть так:

Теперь скопируйте URL-адрес конечной точки функции Firebase в поле URL-адрес конечной точки уведомления внизу. Убедитесь, что он заканчивается на /collect, так как это определенная конечная точка, которую Firebase прослушивает для входящих запросов.

ШАГ 7 Сохраните и просмотрите. Тест (см. ниже). Когда все будет удовлетворено, опубликуйте в производство.

Тестирование монитора dataLayer, чтобы увидеть, работает ли он

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

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

Удалите все триггеры из только что созданного тега монитора dataLayer и добавьте новый триггер тестирования. Сохраните и просмотрите.

Теперь в консоли Javascript вашего браузера используйте метод dataLayer.push для ввода данных в dataLayer.

dataLayer.push({
'event':'dataLayerMonitorCheck',
'customerId': '123456789',
'country':'nl',
'meta': {
    'path':'/some/path',
    'title':'Some Title'
  }
});

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

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

Так же, как и другие скрипты функции мониторинга, которые я сделал, запись будет приостановлена ​​и отправлено уведомление, когда в течение 60 минут произойдет более 3 ошибок (по умолчанию). Вы можете изменить это ограничение времени в скрипте функций на что угодно.

Теперь, когда он протестирован и все работает, давайте настроим Zapier.

Настройте Zapier Webhooks для получения и анализа данных

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

Единственная разница между этой статьей и этим новым скриптом — это значения, которые я отправляю в Zapier.

Так что не забудьте добавить свой URL-адрес Zapier Webhook в скрипт функций мониторинга dataLayer и повторно развернуть его в Firebase!

Значения сценария монитора dataLayer, которые впоследствии можно использовать в Zapier:

1. keyRaw: это исходный ключ, который вы проверяли, т.е. meta.path или country.
2. keyValue: это записанное значение, вызвавшее срабатывание ошибки.
3. условие: это условный оператор, который вы использовали для проверки значения dataLayer.
4. URL-адрес: это URL-адрес страницы, на которой в последний раз произошла ошибка перед отправкой уведомления.
5. timepause: это число, указывающее, как долго уведомления были приостановлены для определенного отслеживаемого ключа dataLayer.

Я оставлю вам решать, как вы хотите построить свое действие в Zapier, но вы уже можете сделать довольно много с этими 5 значениями, чтобы обнаружить эти надоедливые ошибки dataLayer.

Запоздалые мысли

Прежде чем приступить к реализации этого монитора dataLayer, необходимо учесть несколько моментов.

Прежде всего, ВСЕГДА ТЕСТ! Если у вас есть веб-сайт с высоким трафиком и много ошибок dataLayer, вызовы вашего сервера в Firebase могут выйти за пределы бесплатных лимитов, и с вас будет взиматься плата.

Не применяйте его, если вы не способны или не имеете доступа к ресурсам для исправления ошибок. Цель монитора dataLayer — обнаруживать ошибки и уведомлять вас о превышении определенных предопределенных параметров.

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

Будущие итерации

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

Другие идеи включают в себя пользовательский интерфейс для приостановки всех или определенных уведомлений, изменения значений приостановки уведомлений и проверки значений в dataLayer только для ключа, или другой ключ имеет определенное значение, т.е. loggedInStatus или isClient. Вы называете это. Поделитесь своими идеями в комментариях или свяжитесь с нами через LinkedIn.