Gtm проверка ошибок

Триггер (от анг. слова trigger в значении спусковой крючок, или приводящий в действие элемент) в GTM – это условие, при котором активируется или блокируется тег. Для запуска тега должен быть хотя бы один триггер.

Таким образом, нельзя создать тег без триггера. Триггер может принимать значение «true» (истина), либо «false» (ложь). Он выполняется только в том случае, когда его значение является истинным, и если выполняются все условия триггера.

А чтобы это определить (true или false), значение переменной сравнивается с тем, которое задано в триггере. Все триггеры в Google Tag Manager связаны с событиями. Также они могут иметь дополнительные условия или фильтры. В старой версии диспетчера тегов Google триггер назывался «правилом».

Существует два способа создания триггеров:

1. перейти на вкладку «Триггеры» и нажать на кнопку «Создать»;

2. через сам тег в блоке «Триггеры» по нажатию на «+» если в нем уже есть триггеры;

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

Тип триггера представляет собой комбинацию события GTM и типа взаимодействия (или события), которое вы хотите, чтобы GTM начал прослушивать. Они разбиты на несколько категорий:

• Просмотр страницы;
• Клик;
• Взаимодействие пользователей;
• Другое;

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

Просмотр страницы

• Модель DOM готова (DOM Ready) — передается gtm.dom событие, как только браузер загрузил объектную модель документа;
• Окно загружено (Window Loaded) – передается gtm.load событие после завершения загрузки всей страницы, когда окно полностью загружено;
• Просмотр страницы (Page View) – передается gtm.js событие, когда контейнер GTM готов к работе.

Google Tag Manager передает эти три события на уровень данных по умолчанию. Убедиться в этом можно перейдя в режим предварительного просмотра.

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

Выбрав событие, например, Window Loaded, и перейдя на вкладку «Variables» (Переменные), можно просмотреть зафиксированное пользовательское событие (переменная _event) и его значение (value – в нашем примере gtm.load):

или у переменной «Пользовательское событие»:

Клик

Тип триггера фиксирует клики по ссылкам или любым кликабельным элементам сайта.

• Все элементы — передается gtm.click событие когда на странице щелкнут любой элемент;
• Только ссылки – передается gtm.linkClick событие при нажатии на тег <a> элемента HTML.

Например, создадим триггер на «Все элементы» с условием активации триггера «Все клики».

В таком случае при каждом клике по любой области на странице в режиме предварительного просмотра GTM будет фиксировать событие gtm.click:

То есть вне зависимости от того, куда пользователь кликнул (на кнопку, на фон, в пустую область на странице) – все события будут зафиксированы. Если же мы хотим отслеживать события только по определенным элементам, то вместо условия активации триггера «Все клики» выбираем «Некоторые клики»:

Нам станет доступна настройка активации триггера при наступлении события и выполнении всех условий, а именно:

1. сначала задается переменная (на примере выше – Click Element);
2. затем выбирается оператор из списка (равно, содержит, соответствует селектору CSS, регулярному выражению и т.д.);
3. задается само значение (на изображении выше – CSS селектор одного элемента на сайте).

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

Условия и фильтры связаны между собой логическим «И». То есть задав две строки, триггер будет срабатывать только тогда (событие будет считаться истинным и принимать значение true), когда одновременно соблюдаются первое И второе условия.

В этом примере триггер сработает только тогда, когда пользователь кликнет по элементу с соответствующим селектором #features1 > div > ul > li:nth… И только на странице https://site.ru/catalog.

Важно: gtm.click — это предустановленные события GTM, они срабатывают при любом клике вне зависимости от того, был ли он осуществлен по некоторым элементам (при выборе такого) или же по всем элементам страницы. Главное, чтобы на нецелевых событиях не срабатывал тег, который активируется соответствующим триггером.

Аналогичным образом настраиваются триггеры для «Только ссылки», а событие в режиме отладки будет называться gtm.linkClick:

Однако данный тип триггера имеет дополнительные настройки. Такие же опции появляются при создании триггера «Отправка формы».

• Ждать теги – опция блокирует действие (задержка открытия ссылок или отправки формы) до активации всех тегов в контейнере GTM, то есть пока все теги не загрузятся или пока не истечет указанное время ожидания (смотря что произойдет раньше), событие зафиксировано не будет. Задается в миллисекундах (2000 мс = 2 секунды);
• Проверка ошибок – функция блокирует активацию тега, если для отслеживаемого элемента ссылки/формы не было выполнено действие по умолчанию («Клик по ссылке» или «Отправка формы»). Опция отвечает за то, на каких страницах нам необходимо использовать данный триггер.

Блок «Проверка ошибок» позволяет нам указать ГДЕ мы хотим использовать данный триггер, а блок с условиями активации определяет КОГДА этому быть. В качестве примера давайте разберем условие клика по ссылке (элемент – кнопка) со значением CSS-селектора и зададим «Проверка ошибок» на главной странице сайта.

В режиме предварительного просмотра при клике на данную кнопку зафиксируется событие gtm.linkClick:

Но если мы поменяем условие проверки ошибок, например, на такое:

То события gtm.linkClick фиксироваться не будут, поскольку не соблюдено условие ГДЕ. До обновления Google Tag Manager «Проверка ошибок» и условие активации назывались «Условия включения» и «Условия активации». Рядовой пользователь мог легко запутаться в данной терминологии.

Для триггера типа «Отправка формы» распространенным условием активации функции «Проверка ошибок» является указание только тех страниц, на которых есть формы.

Триггер можно использовать со специально встроенными переменными: Click Element, Click Classes, Click ID, Click Target, Click URL, Click Text.

Взаимодействие пользователей

• Видео YouTube – срабатывает событие gtm.video когда пользователь просматривает видео на сайте (пока доступен только сервис-поставщик YouTube);
• Глубина прокрутки – срабатывает событие gtm.scrollDepth в том случае, когда пользователь прокручивает страницу (как горизонтально, так и вертикально);
• Доступность элемента — срабатывает событие gtm.elementVisibility когда элемент становится видимым на странице;
• Отправка формы – срабатывает тег gtm.formSubmit в случае, если форма была отправлена.

Видео YouTube

Тоже самое, что было описано в разделе «Переменные»:

• Начало (Start) – пользователь начинает просмотр видео;
• Завершение (Complete) – пользователь достигает конца видео;
• Приостановка (пауза), перемотка, буферизация (Pause, Seeking, Buffering) – пользователь останавливает, перематывает видео или когда происходит буферизация;
• Ход просмотра (Progress) – пользователь проходит процентный или временный порог (время измеряется в секундах). Целые положительные числа указываются через запятую.
• «Включить поддержку JavaScript API для всех видео YouTube»

Установив этот флажок, вы включите YouTube iFrame Player API. В результате ко всем URL видеопроигрывателя YouTube будет добавлен параметр enablejsapi = 1 для управления проигрывателем через iframe или JavaScript.

Как правило, данный триггер используется в связке со встроенными переменными из блока «Видео»: Video Provider, Video Status, Video URL, Video Title, Video Duration, Video Current Time, Video Percent, Video Visible.

Глубина прокрутки

• Глубина вертикальной прокрутки в процентах – 10, 25, 50, 75, 90 (пример);
• Глубина горизонтальной прокрутки в пикселях – 100 (пример);
• Условия активации триггера – Все страницы.

Как правило, данный триггер используется в связке со встроенными переменными из блока «Прокрутка»: Scroll Depth Threshold, Scroll Depth Units, Scroll Direction.

Доступность элемента

Доступны следующие настройки:

Метод выбора:

• Идентификатор (id);

В большинстве случаев название атрибута id на странице уникальное.

• Селектор CSS

Применяется, если у отслеживаемого элемента нет атрибута id, а также если нам нужно отследить несколько элементов.

Например, у нас на сайте есть несколько форм отправки. У каждой из них есть свой уникальный id. Отслеживание всех форм через «Идентификатор» нам бы не подошло. А вот привязать метод выбора через «Селектор CSS» элементов вполне можно.

Совет: если не знаете, за что зацепиться, а нужно прослушивать конкретный элемент – цепляйтесь за его CSS-селектор. Получить его легко можно через консоль разработчика (в браузере Google Chrome вызывается через клавишу F12, см. скриншот выше).

Правило запуска этого триггера

• Один раз на страницу — если несколько элементов на странице сопоставляются идентификатором или CSS-селектором, этот триггер запускается только один раз, когда первый из них отображается на этой странице.

При перезагрузке страницы триггер сработает повторно;

• Один раз на элемент — если несколько элементов на странице сопоставляются CSS-селектором, этот триггер будет запускаться когда каждый из них будет видимым на этой странице в первый раз. Если несколько элементов на странице имеют одинаковый идентификатор, только первый согласованный элемент будет запускать этот триггер;

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

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

Минимальный процент видимости – какой процент выбранного элемента должен быть виден на экране для срабатывания триггера. Можно использовать собственную переменные.

Укажите минимальное время видимости – как долго выбранный элемент должен быть виден на экране для срабатывания триггера. Время периодов видимости на одной странице суммируется. Например, если элемент был виден в течение 4000 мс (4 секунд), затем скрыт из видимости окна браузера и после этого снова виден в течение 2000 мс, то общее время видимости этого элемента составит 6 000 мс.

Если галочку не ставить, то время видимости для срабатывания триггера не будет играть роли.

Регистрация изменений DOM — настройка отслеживает элементы, которых изначально нет на странице, которые подгружены динамически и могут не входить в DOM (Объектная Модель Документа). Например, всплывающие формы. Если у вас есть на сайте есть такой контент, поставьте галочку, и такие элементы будут регистрироваться.

Отправка формы

Триггер аналогичен настройкам другого триггера «Клик – Только ссылки». Можно использовать со специально встроенными переменными: Form Element, Form Classes, Form Target, Form URL, Form Text.

Другое

• Изменение в истории — срабатывает событие gtm.historyChange если изменился фрагмент URL (хэш, #). Как правило, используется на сайтах, контент которых подгружается динамически, без перезагрузки страниц;

В GTM можно использовать со встроенными переменными: New History Fragment, Old History Fragment, New History State, Old History State, History Source.

• Ошибка JavaScript – срабатывает событие pageError если происходит неперехваченное исключение JavaScript (window.onError);

В случае, если в JavaScript мы используем конструкцию «try..catch», то GTM не зафиксирует ошибку. Также триггер не будет сигнализировать об ошибках, которые произошли до загрузки кода Диспетчера тегов. Можно использовать со встроенными переменными Google Tag Manager: Error Message, Error URL, Error Line, Debug Mode.

• Пользовательское событие – срабатывает событие event, которое отправили с помощью конструкции push({‘event’: ‘event_name’});

Пользовательские события позволяют отслеживать те взаимодействия, для которых не подходят стандартные методы. Например, отслеживание отправки формы с переопределением события submit.

Допустим мы хотим отправлять событие на уровень данных (dataLayer) при нажатии кнопки «Отправить заявку». Для этого добавим код: dataLayer.push({‘event’: ‘button1-click’})

где button1-click – название пользовательского события;

Далее необходимо создать тег, а в настройках триггера «Пользовательское событие» задать название button1-click и условие активации – «Все специальные события». При необходимости можно использовать регулярные выражения.

Когда пользователь нажмет кнопку, на уровень данных будет отправлено пользовательское событие со значением button1-click. Затем GTM определит button1-click как значение пользовательского события и активирует тег.

В dataLayer.push() можно добавить не только одну переменную вида «ключ=значение», но и целый массив. А чтобы посмотреть порядок в котором события передаются на уровень данных, откройте консоль JavaScript в веб-браузере и введите dataLayer:

• start – запуск контейнера GTM;
• dom – модель DOM готова;
• load – окно загружено;
• linkClick – открытие формы;
• button1-click – клик по кнопке.

Таймер

Событие gtm.timer срабатывает через заданный интервал времени (в миллисекундах).

Доступны следующие настройки:

• Имя события (по умолчанию gtm.timer) – можем изменить на любое другое. Например, timer2018;
• Интервал — время, через которое должно активироваться событие. Например, через 2,5 секунды;
• Ограничение — максимальное число активаций события. Например, 1. Если оставить это поле пустым, событие будет активироваться до тех пор, пока пользователь не покинет страницу.

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

Так выглядит уровень данных события gtm.timer:

Триггеры в Google Tag Manager делятся на триггеры активации тегов и триггеры блокировки тегов.

Триггер активации — это условие, при выполнении которого срабатывает тег.

Например, вы хотите отслеживать клики по определенной кнопке на сайте. Зная значения переменной, вы можете настроить триггер активации, например, по Click ID:

Таким образом, тег активируется только в том случае, когда идентификатор HTML-тега равен menu-item-4306.

Триггеры активации делятся на:

• встроенные триггеры – доступны к использованию готовые шаблоны;
• пользовательские триггеры – ручная самостоятельная настройка.

Триггер блокировки — это условие, при выполнении которого активация тега блокируется.

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

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

В Google Tag Manager существует триггер, который добавлен по умолчанию и который нельзя удалить. Это All Pages (Просмотр страницы).

Также как и переменные, триггеры в GTM можно копировать, удалять, просматривать изменения, и у них можно вывести примечания. Для этого в правом верхнем углу нажмите на значок «три точки».

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

После создания триггеров их следует добавить к тегам.

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

Google Tag Manager — лучший инструмент для отслеживания конверсий и активностей на сайте. Помимо корректной интеграции контейнера GTM в код страниц, важна его тонкая и тщательная настройка. Работает ли он правильно, есть ли вообще на сайте? Второй вопрос актуален, если, скажем, вы только начинаете работу с новым ресурсом. Предлагаю вам несколько способов найти ответы.

Проверка наличия GTM на сайте

Если вы не уверены, подключен ли Google Tag Manager на сайте, есть несколько способов проверить наличие контейнера GTM.

Поиск в коде сайта

Самый простой и быстрый способ обнаружить следы GTM — посмотреть исходный код сайта. Для этого нужно:

• Перейти на сайт.
•  С помощью команды «ctrl+u» перейти к коду страницы.
•  Вызвать строку поиска с помощью команды «ctrl+f» и ввести «gtm.js» или «googletag». 

Если поиск выдает совпадения, значит контейнер GTM уже подключен.

Дальше нужно удостовериться, что в код внедрен именно тот контейнер GTM, к которому у вас есть доступ и с которым вы планируете работать. У каждого контейнера GTM свой уникальный код (Container ID). Увидеть его можно в кабинете Google Tag Manager.

Для этого нужно:

• Перейти на сайт.
• С помощью команды «ctrl+u» перейти к коду страницы.
• Вызвать строку поиска с помощью команды «ctrl+f» и ввести Container ID, к которому у вас есть доступ в кабинете Google Tag Manager.

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

Главный минус — так можно проверить только одну страницу сайта. GTM же должен быть на всех, а провести массовую проверку метод не позволяет.

Важно понимать, что наличие Google Tag Manager на одной странице не свидетельствует о его корректной настройке и работе на сайте в целом.

Проверка с помощью Google Tag Assistant

Google Tag Assistant — расширение для браузера, позволяющее в один клик проверить правильность установки GTM. Плагин от Google выделяет разными цветами теги в зависимости от их состояния.

1. Установите Google Tag Assistant в магазине Chrome.

2. Перейдите на страницу, для которой необходимо проверить корректность работы GTM, запустите расширение Google Tag Assistant, обновите браузер.

3. После обновления еще раз откройте Google Tag Assistant, и при наличии GTM расширение его обнаружит.

Минусом данного метода можно назвать точечность проверки. Если сайт большой, проверка всех страниц с помощью Google Tag Assistant займет очень много времени.

Инструменты разработчика Chrome

С помощью консоли разработчика также можно проверить корректность работы Google Tag Manager.

• Проверка во вкладке «Network»:
• с помощью комбинации «ctrl+shift+i» откройте консоль;
• нажмите «Network»;

• в поле «Фильтр» введите «GTM».

• Код ответа сервера 200 означает, что тег присутствует и срабатывает корректно.

Проверка во вкладке «Elements»:

• с помощью комбинации «ctrl+shift+i» откройте консоль;

• «ctrl+f» — откройте строку поиска;

• введите «gtm».

Если контейнер Google Tag Manager внедрен корректно, его можно будет увидеть.

Минусы проверки с помощью инструментов разработчика:

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

Если же проверка не удается, ознакомьтесь с документацией Google Developer для GTM или переустановите контейнер.

Проверка корректности работы GTM на сайте

Если Google Tag Manager уже подключен на сайте и настроен, необходимо проверить корректность срабатывания тегов. Существует несколько способов тестирования контейнера GTM.

Консоль предварительного просмотра и отладки Google Tag Manager
Самый подробный и наглядный способ проверки корректности работы — использовать консоль предварительного просмотра и отладки. Позволяет максимально точно определить, какие настройки и при каких условиях срабатывают. Помимо этого, консоль показывает все установленные теги независимо от корректности настроек. А значит, можно будет отсечь либо донастроить неработающие теги.

Чтобы перейти в консоль предварительного просмотра и отладки:

• Откройте Google Tag Manager и нажмите «Preview» в правом верхнем углу.

• Введите свой домен в соответствующую строку и жмите кнопку «Connect».

• После удачного подключения появится «Connected». Жмите «Continue».

При корректном выполнении действий перед вами откроется консоль отладки GTM с полным списком всех тегов для страницы.

Помимо этого, откроется новая вкладка: http://your-domain-name.com/?gtm_debug=12345678910, дублирующая страницу вашего сайта.

Если на вашем сайте есть теги, срабатывающие при открытии страницы, в консоли отладки они перейдут в категорию «Tags Fired». Под каждым из них сработает счетчик (в примере каждый тег сработал по одному разу).

Несработавшие теги будут находится в списке «Tags Not Fired».

Вам остается проверить корректность настроенных тегов на открывшейся странице http://your-domain-name.com/?gtm_debug=12345678910. Создайте условия, под которые вы настраивали тег, и в консоли отладки GTM данный тег должен перейти из списка «Tags Not Fired» в «Tags Fired» со значением счетчика +1.

Если тег уже находится в категории «Tags Fired» и вы повторно создаете те же условия, счетчик «Fired» корректно настроенного тега должен увеличиться на +1 к старому значению.

При создании условий тег не срабатывает или счетчик фиксирует некорректное количество срабатываний? Это означает, что допущена ошибка во время настройки и требуется внести коррективы.

Google Tag Assistant

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

С помощью утилиты Google Tag Assistant можно записывать действия и отслеживать срабатывание триггеров на них. Для этого:

1. Перейдите на проверяемый сайт.

2. Откройте расширение Google Tag Assistant и нажмите «Record».

3. Совершите необходимые для срабатывания триггеров действия на сайте.
4. Остановите запись, открыв расширение и нажав «Stop Recording».

5. В появившемся отчете увидите количество проверенных страниц и количество сработавших тегов.

6. Нажав на кнопку «Show Full Report», увидите страницу детальных итогов записи.

В этом подробном отчете теги подсвечены синим цветом, что свидетельствует о мелких, но не критичных проблемах

Google Analytics

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

1. Зайдите в Google Analytics.
2. Перейдите в раздел «Realtime» на «Conversions».

3. Создайте условия для сработки тега и фиксируйте срабатывание.

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

Выводы

Есть несколько простых и надежных способов оценить работу GTM на сайте.

Проверить наличие контейнера GTM можно с помощью:

• поиска в коде сайта;
• расширения Google Tag Assistant;
• проверки во вкладках «Network» или «Elements» в инструментах разработчика Chrome;
• парсинга в Netpeak Spider.

Проверить корректность работы GTM помогут:

• консоль предварительного просмотра и отладки Google Tag Manager;
• расширение Google Tag Assistant;
• Google Analytics.

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

Источник: Netpeak.net

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

Прежде чем приступить к настройке отслеживания 404 ошибок, убедитесь в том, что на сайте корректно установлен контейнер GTM и что через него встроен Google Analytics. О том, как правильно установить Google Tag Manager, мы писали в статье «Руководство по установке и настройке Google Tag Manager для новичков».

Шаг 1. Создайте переменную

Для этого выполните следующие действия:

А. На панели навигации слева перейдите по ссылке «Переменные».
Б. В разделе «Пользовательские переменные» нажмите на кнопку «Создать».
В. Придумайте название для переменной.

Мы назвали Http Request. Если вы назовете подругому, измените название и в коде следующей переменной. 

Г. Выберите тип переменной — «Собственный код JavaScript»

Д.  Вставьте следующий JavaScript код:

function getReq(){
 	var req = false;
	if (window.XMLHttpRequest) {
		try {
			req = new XMLHttpRequest();
		} catch (e) {
			req = false;
	 	}
	} else if (window.ActiveXObject){
	  	try {
			req = new ActiveXObject('Microsoft.XMLHTTP');
		} catch (e) {
			req = false;
		}
	}
	if (!req){}
	return req;
}

Шаг 2. Создайте еще одну переменную

Вторая переменная будет обращаться к первой и отдавать код ответа сервера

Для этого выполните те же действия, что и при создании первой переменной, только придумайте другое название (Мы назвали «Код ответа сервера») и вставьте следующий JavaScript код:

function() {
	var req = {{Http Request}};

	try {
		req.open('GET', '{{Page URL}}', false);
		req.send('');
	} catch (e) {
		success = false;
		error_msg = "Error: " + e;
	}

	return req.status;
}

Шаг 3. Создайте триггер с такими параметрами:

Тип триггера: «Просмотр страницы»
Условия активации: «Некоторые просмотры страниц»
Условие, при котором должен активироваться триггер: код ответа сервера содержит 404

Шаг 4. Создайте тег с такими параметрами:

Тип тега: «Universal Analytics»
Тип отслеживания: Событие
Категория: мы назвали «error404»
Действие: выберите значение {{Page URL}}, чтобы увидеть, на какой странице сработало событие

Триггер активации: триггер, созданный на предыдущем шаге

Шаг 5. Проверьте и опубликуйте тег

В режиме предварительного просмотра перейдите на несуществующую страницу вашего сайта. Если после нажатия на кнопку контейнер в консоли отобразился под строкой «Tags Fired On This Page», значит, тег установлен без ошибок.

После того как вы убедитесь в правильной настройке тега, настройте отслеживание цели в Google Analytics.

Для этого создайте и настройте новую цель в Google Analytics. Информацию, которые вы указали при настройке тега в GTM, продублируйте при настройке цели в Google Analytics.

Шаг 6. Проверьте, всё ли вы сделали правильно

Достижением цели станет переход на несуществующую страницу вашего сайта. Перейдите по ней и посмотрите событие в Google Analytics. Для этого перейдите в «Отчёты» — «В режиме реального времени» — «События».

Таким образом, мы настроили отслеживание 404 ошибок без вмешательства в исходный код страниц.

Еще статьи по теме:
Отслеживание отправки форм на сайте с помощью GTM
Отслеживание кликов в Google Analytics с помощью Google Tag Manager
Настройка отслеживания e-commerce с помощью Google Tag Manager

Еще по теме:

• Критично ли не использовать тег canonical и закрывать страницы пагинации в файле robots.txt?

Расскажите, пожалуйста, насколько критично не использовать тег canonical и закрывать страницы пагинации в файле robots.txt. Хочется выяснить больше нюансов и принять решение, стоит ли вносить…

• Автогенерация метаописаний title и description

Оптимизация метаописаний Title, Description и Keywords — это первое, на что должен обращать внимание SEO-специалист, начиная работу с проектом. Для тех, кто не знает, поясню….

• Lazy loading или «ленивая загрузка» для изображений

  Что такое «ленивая загрузка» Для кого нужна «ленивая загрузка» Почему следует внедрить lazy loading Виды отображения при «отложенной загрузке» Как реализовать: Рекомендации Google по…

• Страницы категорий и подкатегорий – инструкция по оптимизации ИМ

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

• Проектирование структуры и навигации интернет-магазина: возможные проблемы и их решение

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

Updated: August 17th, 2023

You can do many cool things with Google Tag Manager, like track purchases, form submissions, link clicks, etc. All of these are positive actions for the business. But what about negative ones? Errors should also be tracked, as they might provide you with some hidden gems.

Identifying where your visitors/customers are struggling and fixing those issues can quickly improve conversions on your website.

So what kind of errors can you track with GTM? In this guide, we’ll look at five different groups of errors that you can track with Google Tag Manager.

Here’s what you will learn in this article

• #1. Track JavaScript Errors with Google Tag Manager
  • #1.1. How to Configure JavaScript Error Trigger in Google Tag Manager
  • #1.2. Why is it useful?
• #2. Track 404 Errors with Google Tag Manager
  • #2.1. Using Page Title
  • #2.2. Ask a developer to push the 404 error to the Data Layer
• #3. Checkout Errors
• #4. Form Errors (e.g. Registration and Login forms)
  • #4.1. Using Element Visibility trigger to track form errors
  • #4.2. Working with an AJAX form? Try this
    • #4.2.1. Data Layer Variables
    • #4.2.2. Trigger (when the error message is pushed to the Data layer)
    • #4.2.3. Google Analytics tag
• #5. Server Error (like 50x, etc.)
  • #5.1. Lookup Table Variable
  • #5.2. Trigger
  • #5.3. Tag
• Several Tips Regarding Error Naming Convention
• Example of a setup + Reports in Google Analytics 4
• Final words

Errors are listed in no particular order, therefore, don’t think that error #5 is less valuable than #1.

#1. Track JavaScript Errors with Google Tag Manager

GTM has a built-in trigger that captures uncaught JavaScript errors. If you look at the list of all possible trigger types in GTM, you can probably easily guess which trigger I’m talking about. Yes, it’s a JavaScript Error trigger.

#1.1. How to Configure JavaScript Error Trigger in Google Tag Manager

Uncaught means an error wasn’t captured and handled by some script on a page. In plain English: if an unexpected error occurs in JavaScript code and that code was not programmed to deal with it, the JavaScript Error trigger will track it.

However, you should not think this trigger catches ALL possible errors on a page. If a JS error occurs on a page and the script was programmed to handle it by showing a specific error/warning popup to a visitor, such an error will not be tracked by GTM.

Go to Triggers > New > Trigger Configuration > JavaScript Error to get started. Leave all the settings as they are and save the trigger.

Also, go to Variables > Configure (in the Built-in Variables section) and enable Error Message, Error URL, and Error Line.

When GTM captures an error, you can get 3 data points with it:

• Error message (the text of the JavaScript error message, for example, Uncaught ReferrerceError: testvariable is not defined )
• Error URL (the address of the page where the error occurred)
• Error Line (the line number in the code where the error was detected)

You could send all of those data points to Google Analytics. To do that, go to Tags > New > Google Analytics: GA4 Event and enter the following settings (make sure that you have already enabled the Error Variables in the container):

Important: Google has replaced the GA4 configuration tag with Google Tag. So, this changed some parts of the GTM interface. Learn more.

Finally, assign the JavaScript error trigger (that you have previously created) to this GA4 Event tag. Save the tag, refresh/enable the preview mode.

If you want to test this, you can add this code (temporarily!) to a page via the content management system:

<script>
  setTimeout(function(){ 
      jstestingvarwithalongname.push({'key' : 'value'}); 
  }, 2000);
</script>

When you save the changes made and navigate back to the page to test (but before that, refresh or enable the GTM preview and debug mode), you should see the JavaScript error in the GTM debug console.

Remember, the aforementioned line of code intentionally contains a JS error. Remove it immediately after the test is done.

Now, if you want to see the variables passed along with the event (error_message, error_line, error_url) inside GA4 reports, you’ll need to register them as custom dimensions. I’ve written an extensive article on adding custom dimensions to GA4, which you can read by clicking here.

.

#1.2. Why is it useful?

If your developer is not tracking JavaScript errors with a dedicated tool (like TrackJS), JavaScript Error tracking with Google Tag Manager is better than nothing (of course, you should not think this is 100% accurate).

You can track JS errors as negative goals and then see the number of sessions that had at least one error (more on negative goals — later in the blog post).

Another idea: Sequence segments. For example, show all the sessions that entered the checkout and then had a JavaScript error but did not make a purchase.

This segment is more useful for those businesses where customers usually convert in the same session they arrive.

These are just several ideas, and everything depends on your imagination.

#2. Track 404 Errors with Google Tag Manager

Another type of error that you can track with Google Tag Manager is 404, a.k.a. Page Not Found. I have a separate blog post (covering other alternatives, too) for that, but here are some of the highlights + new ideas.

There are several different ways how to tackle 404 error tracking. I’ll mention two:

• Using the Page Title dimension to identify the “Page not found” errors.
• Asking a developer to push the 404 events to the Data Layer

#2.1. Using Page Title

This method will be helpful if the page title of 404 pages contains “Page not found”, “Page missing”, or some other phrase that lets you quickly identify that a visitor has landed on a 404 page.

How can you check that? Open a website you’re working on, and add some gibberish at the end of the URL, e.g., https://www.youwebsite.com/posts/somenonsense

Are you redirected to a 404 page? What is the title of the page? (you can check that in the browser tab):

To learn all the technical details, read this blog post.

#2.2. Ask a developer to push the 404 error to the Data Layer

Here’s another option; if the last one did not work for you. Ask your developer to activate the code below whenever a visitor lands on a page that contains a 404 (page not found) error

<script>
window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
  'event': 'page_not_found', 
});
</script>

P.S. You are free to use different values for those keys that match your own naming convention.

This code will push the error information to the Data Layer.

Once the developer implements the code, you will need to:

1. Create a Custom Event Trigger
2. Create a Data Layer Variable
3. Create a Google Analytics Event tag that sends the 404 error to GA4 as an event

First, let’s start with a trigger. Go to Triggers > New > Custom Event Trigger and enter the following settings:

Enter the value of the “event” key in the “Event name” field. If you used my code example, enter “page_not_found” (without quotation marks).

Important: event names are case-sensitive in GTM.

Now, we move to create the GA4 tag. Go to Tags > New > Google Analytics: GA4 Event and enter the following settings:

Don’t forget to test the setup with the GTM preview and debug mode + publish the changes after that.

Important: Google has replaced the GA4 configuration tag with Google Tag. So, this changed some parts of the GTM interface. Learn more.

#3. Checkout Errors

Checkout errors are the third group of errors you need to keep an eye on. I’d say these are among the most important because the visitor/user is very close to the conversion (e.g. purchase, signup, etc.).

Your goal is to reduce friction/struggle as much as possible.

What kind of errors should you track? Consult with a developer on what is possible.

Here are some ideas:

• Form-related errors (like “some required fields are not filled in: first name, address”)
• Form-field-related errors (like “invalid shipping address”)
• Payment-related errors (like “insufficient funds” or “card declined”) (just make sure things like credit card data are not tracked)

After identifying groups of errors that you want to track, ask a developer to push those errors to the Data Layer; here’s a sample code:

<script>
window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
  'event': 'checkout_error',
  'error_message': 'card declined' // some descriptive message about the error
});
</script>

Then apply the same principle I’ve explained in chapter #2.2. of this blog post, create:

• Custom event trigger
• Data Layer variable (for error_message)
• Google Analytics tag

Here’s what the tag should look like (don’t forget to assign the Custom Event trigger to this tag).

Important: Google has replaced the GA4 configuration tag with Google Tag. So, this changed some parts of the GTM interface. Learn more.

#4. Form Errors (e.g., Registration and Login forms)

There are different ways how to track form errors. Some are more reliable, while others are not so much. Once again, the most robust way is to cooperate with a developer and ask them to push the error data to the Data Layer.

I will not explain this principle all over again. Please revisit chapter #2.2. of this blog post.

In addition to the “Developer + Data Layer” method, here are other alternatives. Remember, they might be more fragile and cause more significant data inaccuracies:

1. Track when the error message of the form appears on the screen
2. Using AJAX form? Check the response when the form is submitted (maybe you’ll find something useful there)

#4.1. Using Element Visibility trigger to track form errors

Warning: for this method to work, you must become familiar with CSS selectors, an advanced topic.

So if you have a form that displays an error message (after the form was submitted with an error), here’s what you could do.

First of all, right-click on that error message and see what kind of classes or IDs it has. Once again, I cannot stress this enough: this method will work if you have the correct CSS Selector fundamentals in your head.

Here’s an example of what I see after inspecting a specific element (P.S. This does not mean you will see the same thing (because most websites are unique)).

Take a closer look at the class attribute of that error message. One of the classes is wpcf7-validation-errors. We could use that in our GTM trigger.

Go to Triggers > New > Trigger Configuration > Element Visibility and enter the following settings:

In CSS, all classes start with a dot. That’s precisely what we did: we entered .wpcf7-validation-errors. Also, make sure you enable the “Observe DOM changes” setting.

Let’s test whether the trigger works properly. Save the trigger, refresh/enable the GTM Preview and Debug mode, refresh the page with the form and submit the form with one required field missing (or some other error you know).

The Element Visibility event should appear on the left side of the Preview mode panel.

Now, how can you access the text of that error message? The neat trick is that Click Text or Form Text, built-in variables in GTM, return the text from the element tracked by the Element Visibility trigger. Learn more about this here.

Now, it’s time for a tag. Go to Tags > New > Google Analytics: GA4 Event and enter the following settings:

Important: Google has replaced the GA4 configuration tag with Google Tag. So, this changed some parts of the GTM interface. Learn more.

Where will you see this event in Google Analytics?

• Click on Reports > Realtime and navigate to the widget that shows Event Count by Event Name
• Navigating to the default Events report (Reports > Events)
• Creating a new Exploration report to visualize the data and the parameters involved. But remember, the parameters need to be registered as custom dimensions to be viewed in your Exploration report. Here’s a quick guide on how you can do this.

#4.2. Working with an AJAX form? Try this

If your form does not reload the page after it was submitted (or when the error is displayed), it is possible that the form was built using AJAX.

How can you make sure you’re working with an AJAX form? Click this link (credit for this code goes to Bounteous), copy the entire code and paste it into a new Custom HTML tag within your GTM container. Set the tag to fire on All Pages. Save the container, refresh the preview mode, and navigate to where the form is located.

The custom HTML tag will fire on the Pageview event. Don’t worry about that. Now try to submit the form again. Did the ajaxComplete event appear in the GTM preview mode? Yes? This means you’re working with an AJAX form.

Now try to submit a form with at least one empty required field. Did the ajaxComplete event appear again? If yes, click that event in the preview mode and go to the Data Layer tab.

Scroll down and keep looking for the response section.

Do you see something meaningful there that is related to an error? In my case, I see this (Warning: the data structure of the response might look totally different in your case):

It would be cool to access that statusCode and message values, right? Luckily, we can do that.

#4.2.1. Data Layer Variables

Go to Google Tag Manager > Variables > User-defined Variables > New > Data Layer Variable.

In my example, the status key is outside the object response, which is inside another object called attributes. That is why in the Data Layer Variable, you should enter attributes.response.status (if you have no clue what I’m doing here, read this guide)

Save the variable. Now, it’s time to access the message. Enter attributes.response.message in the Data Layer Variable.

Save the variable.

#4.2.2. Trigger (when the error message is pushed to the Data layer)

It’s time to create a trigger that will be activated when an ajaxComplete will be pushed to the Data Layer and attributes.response.status will equal validation_failed.

Save the trigger

#4.2.2. Google Analytics tag

And the last step — the GA4 Event tag. Go to Tags > New > Google Analytics: GA4 Event and enter the following settings.

Important: Google has replaced the GA4 configuration tag with Google Tag. So, this changed some parts of the GTM interface. Learn more.

I’ve inserted the attributes.response.message as an event parameter. Whenever an AJAX form error is pushed to the Data Layer, I will pass its text/message to Google Analytics.

Important: If you have named your variables differently (e.g., not dlv – attributes.response.message), use your naming in the GA4 tag, not mine.

Save the tag, refresh the preview mode, navigate to the form, and submit it with an error. Check if the ajaxComplete event was fired and whether it is visible in the GA real-time reports. Otherwise, you can populate the event details using the Exploration report.

#5. Server Error (like 50x, etc.)

When a server error occurs on a page (e.g., “Internal server error” or “Bad Gateway”, etc.), they look like this (pardon me or an old screenshot I found online):

Simple plain text page. However, GTM (or any other snippets) on that page is not available. Thus, you cannot track them by default. As a solution (I honestly don’t know whether this is the only workaround), you could ask a developer to redirect visitors to a static error page (each error will probably have a unique error page (visually similar but with a different error message)).

For example, if a 500 error occurs, a developer could redirect visitors to yourwebsite.com/500error.html (or something like that). If 503, then yourwebsite.com/503error.html.

My examples here are totally made up. The URLs of your error pages might look totally different. However, remember that only a developer can implement these redirects to error pages.

All error pages could use the same HTML file template with some basic error information and the Google Tag Manager container snippet. The snippet is the key here. Without it, no error tracking will be possible. Some companies even go the extra mile with a custom error page design that might look like this:

If URLs of the error pages contain the error code (e.g., yourwebsite.com/500error.html), you can implement the same method I’ve explained in #2.1 chapter of this article.

If the URLs aren’t very friendly, e.g., yourwebsite.com/error1.html means 500 error, then you could implement something like this. Create a Lookup Table or Regex Table variable that will check the Page Path and return a more meaningful/readable value.

#5.1. Lookup Table Variable

For this example, I will use a Lookup Table variable (that will be looking for exact matches).

A hypothetical situation. Our website has five error pages for different types of server errors:

• mywebsite.com/error1.html is for error 500 (if you are not familiar with error codes, here they are)
• mywebsite.com/error2.html is for 502
• mywebsite.com/error3.html is for 503, etc.

Here is what we could do. In GTM, go to Variables > User-defined Variables > New > Lookup Table. Choose {{Page Path}} as an input variable. Then create separate rows for each error page.

Since we will be working with a {{Page Path}}, we must enter what comes after the slash in the URL, e.g., error.html. Let’s do that:

Then, on the right side of each column, enter the output you want to use (in other words, we will turn the ambiguous error.html into 500 error).

If, in the future, you plan to implement more error page templates, it’s a good practice to set the “default” value of the table variable. If none of the conditions/rows is met, this variable will default to the {{Page Path}}.

Save the variable.

#5.2. Trigger

Now, let’s create a trigger that will be activated when the visitor loads an error page. Go to Triggers > New >Trigger Configuration > Pageview and enter the following condition:

In our case, Page Path or an error page starts with “error” and ends with “.html”.

#5.3. Tag

Finally, create a Google Analytics event tag to send the error to GA4. Go to Tags > New > Google Analytics: GA4 Event and enter the following settings.

Important: Google has replaced the GA4 configuration tag with Google Tag. So, this changed some parts of the GTM interface. Learn more.

With the help of the Lookup Table variable, you will be sending the actual error codes to GA.

Assign the pageview trigger to this tag, and save it. Don’t forget to test and then publish your changes.

Several Tips Regarding Error Naming Convention

This is NOT some hard rule that you MUST follow. It’s up to you how you will name your events in Google Analytics. But I prefer that all event names contain the word “error”. But it’s up to you to decide.

Then the event name could also contain the type of the error:

• Page not found (e.g., event name could be page_not_found or page_not_found_error)
• server (e.g., server_error)
• form (e.g., form_error), etc.

You can send the event message as an event parameter error_message, describing the nature of the error. What exactly was the error? For example:

• If the error is in the checkout, an error message/text would be valuable (like “credit card declined”)
• If the error originated from the server-side, then the error code (e.g., 503) and the location (URL) would be nice (or at least the error code)
• If the error is related to a form, then I’d like to know the error text

You get the idea. But once again, these are just my thoughts. You are free to choose a different naming convention.

Also, don’t forget to register custom dimension(s) if you send custom parameters with events to GA4.

Example of a setup + Reports in Google Analytics 4

Enough of a theory. How about a practical example? Let’s say that we want to see which pages have the most JavaScript errors.

To do this, let’s begin by adding an event tag that fires every time there is an error with the website. In this case – Javascript errors, for example:

• cannot read properties of null (reading ‘addeventlistener‘)
• cannot read properties of null (reading ‘queryselectorall‘)
• null is not an object (evaluating ‘readmorebtn.addeventlistener‘)

Head over to Google Tag Manager, and enter the following settings into the new tag.

As the trigger for the event, use the built-in trigger for Javascript errors.

Save your changes and publish the container.

Remember to add custom parameters from the tag as custom dimensions inside the GA4 interface.

Using this, you can now see the instances of Javascript errors and where they occurred inside your Exploration reports.

How do we do this? I will explain it simply here to address the topic at hand. However, there’s much more to learn about creating exploration reports, so you should read it.

Navigate to Explore and select Create a Blank Exploration.

The new page that opens will allow you to customize your report as you see fit. You’ll see various options to modify the report, but we will focus on the ones in the screenshot below.

Add the following metrics to the Dimensions and Metrics section.

To avoid any stray details entering the report, we must restrict the report to show results only when the Event Name exactly matches javascript_error.

The final report should appear like this.

If you need more clarity on how to use Exploration reports, I have a detailed article which you can read here.

Final words

These were some of the ideas about Error Tracking with Google Tag Manager. Every business is different; therefore, the types of errors that you can/will measure will also be different.

Personally, I always try to track:

• Form-related errors
• Checkout errors
• Registration errors
• “Page not found” errors

The first three are directly related to revenue or lead acquisition (that may eventually lead to revenue increase). “Page not found” errors are easy to track and may help you identify missed opportunities when a visitor lands on your page, finds nothing, and bounces.

Got something to add? Use the comments section below!

Подробное руководство по отслеживанию отправки форм 9 различными способами с помощью Google Tag Manager.

Данный материал — отрывок из электронного руководства по Google Tag Manager (2020).

Примечание:

• в октябре 2020 года (после выхода книги) Google Tag Manager изменил режим предварительного просмотра;
• в 2021 году в диспетчере тегов Google переименовали некоторые триггеры: Пользовательское событие на Специальное событие, а Доступность элемента на Видимость элемента.

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

В этой публикации рассмотрим девять способов отслеживания отправки форм с помощью Google Tag Manager и отправки данных в Universal Analytics, а именно:

1. с помощью отдельной страницы;
2. с помощью триггера Отправка формы;
3. с помощью триггера Доступность элемента (Видимость элемента);
4. с помощью триггера Пользовательское событие (Специальное событие) и уровня данных (dataLayer);
5. с помощью прослушивателя автоматических событий;
6. с помощью универсального кода для форм на AJAX;
7. с помощью DOM Scraping;
8. с помощью виртуальных страниц;
9. брошенные формы.

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

На моем YouTube-канале есть отдельная лекция, посвященная отслеживанию отправки форм веси перечисленными способами. Рекомендую к просмотру:

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

Способ №1. Отслеживание отправки формы с помощью отдельной страницы

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

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

Но если вы все же захотите настроить отслеживание как событие через GTM, то можете воспользоваться триггером Просмотр страницы с условием активации на конкретной странице (странице Спасибо):

В моем примере – это Page Path содержит thank—you, поскольку URL-страницы имеет адрес /thank—you.html. А тег, который используется для передачи данных в Universal Analytics, имеет вид:

Через некоторое время все данные по событиям появятся в Google Analytics отчете Поведение — События — Лучшие события. Если вы планируете отслеживать отправку формы не только как события, но и как цель-события (конверсии), настройте цель с типом Событие:

Данный способ является наиболее простым в отслеживании.

Способ №2. Отслеживание отправки формы с помощью триггера Отправка формы

Если на вашем сайте есть форма с тегом <form> и кнопкой, которые имеют синтаксис:

вы можете попробовать использовать стандартный триггер Отправка формы. Но перед тем, как это сделать, необходимо активировать встроенные переменные типа Формы, которые позволят вам настроить корректное условие активации:

Затем создайте триггер типа Отправка формы. Для начала зададим условие активации на все формы и сохраним изменения.

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

Если событие Form Submit появилось в консоли предварительного просмотра, то вы можете использовать стандартный прослушиватель для своей формы. Воспользуйтесь значениями активированных переменных, чтобы узнать, есть ли у данной формы идентификатор (id) или класс (class), и активировать триггер только для конкретной формы, а не всех, которые есть на сайте. Для этого кликните на событие Form Submit и перейдите на вкладку Variables:

Как видим из рисунка выше, у данной формы есть и то, и то. Поэтому мы можем указать в качестве условия активации триггера Form Classes содержит st_contact_form_box или Form ID содержит email—form.

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

Сохраним настройки триггера. Чтобы передать информацию об успешной отправке формы в Google Analytics необходимо создать тег Google Аналитика – Universal Analytics с типом отслеживания Событие, задать соответствующие настройки Категории и Действия, и в качестве триггера активации выбрать созданный триггер типа Отправка формы. Например, так:

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

Иногда вы можете наблюдать следующее: в режиме предварительного просмотра GTM события Form Submit фиксируются, тег на отправку формы срабатывает, и данные в инструменты веб-аналитики передаются даже тогда, когда пользователь не заполнял форму. Или вы просто обновляете страницу и, когда страница загружается, видите событие gtm.formSubmit. Как правило, такие события возникают из-за установленного Facebook Pixel (пикселя Facebook). Подробнее об этом я писал в этом материале.

Способ №3. Отслеживание отправки формы с помощью триггера Доступность элемента (Видимость элемента)

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

Тот же самый метод может быть применен и к формам, когда после успешной отправки обращения появляется некоторое сообщение, например, «Спасибо! Данные успешно отправлены»:

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

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

После этого откроется консоль разработчика на вкладке Elements (браузер Google Chrome) с подсвеченным элементом. Из рисунка выше видно, что у данного элемента есть класс js-successbox t-form__successbox t-text t-text_md, который мы можем применить при настройке триггера в Google Tag Manager.

Примечание: элемент может иметь/не иметь идентификатор (#id) или класс (.class). В этом случае вы можете привязаться к его CSS-селектору. Подробно о селекторах было разобрано в соответствующей главе.

Вернемся в Google Tag Manager и создайте триггер типа Доступность элемента. В качестве метода выбора будем использовать Селектор CSS, поскольку у данного элемента нет идентификатора. Как вы уже знаете, в CSS перед каждым классом ставится точка (.), а пробелы между несколькими классами также заменяются на точки.

Первая настройка для моего примера будет выглядеть так:

Правило запуска этого триггера оставим без изменений — Один раз на страницу. Настройку Минимальный процент видимости также не будем менять – 50%. Главное – это не забыть поставить галочку напротив Регистрация изменений DOM, поскольку изначально данного элемента нет в структуре DOM-дерева, и сообщение об успешной отправки формы появляется на экране только после ее отправки.

Сохраним настройки триггера. Чтобы проверить срабатывание события после отправки формы воспользуемся режимом отладки GTM и повторно создайте тестовое обращение.

Видим, что событие Element Visibility (gtm.elementVisibility) сработало после успешной отправки формы. Теперь вы можете использовать этот триггер в различных тегах для передачи информации в инструменты веб-аналитики (Яндекс.Метрику, Google Analytics, Facebook Pixel и др.). Например, как событие в Universal Analytics:

Способ №4. Отслеживание отправки формы с помощью триггера Пользовательское событие (Специальное событие) и уровня данных

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

Если стандартный триггер Отправка формы может не работать с вашей формой, то отслеживание отправки формы с помощью триггера Пользовательское событие и уровня данных 100% вызовет нужное событие (при условии, что настройка верна!). Вы можете попросить разработчика внедрить конструкцию dataLayer.push () в функцию обратного вызова, которая вызывается при успешной отправке формы.

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

, где после event может и вовсе не быть дополнительных переменных. В моем примере есть formName, в которую вы можете попросить разработчика добавить название формы, при условии, что на сайте их несколько, и они имеют разное назначение.

Таким образом, используя переменную уровня данных, вы сможете передавать информацию в аналитику не только об успешной отправке формы, но и ее название, чтобы всегда знать, какую конкретно форму на сайте отправил пользователь, а также ряд других дополнительных параметров. Потом статистику по каждой заполненной форме можно будет сравнить между собой в отчетах Google Analytics и Яндекс.Метрики. Кроме formName можно передавать и другие данные.

Здесь уже зависит от вашего желания и конкретной задачи.  Например, на моем сайте (osipenkov.ru) есть 5 различных форм:

1. бесплатный анализ проекта;
2. запись на вебинар;
3. скачать бесплатные книги;
4. подписка на рассылку новостей;
5. связаться по форме «Контакты»;

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

Последовательность отслеживания следующая:

• определяетесь с именем события, которое в дальнейшем вы будете использовать в триггере GTM типа Пользовательское событие (в примере выше – это formSuccess);
• определяетесь с количеством дополнительных данных/переменных, которые вы хотите передавать в dataLayer;
• записываете итоговый код для разработчика (за аналог берете код в примере выше);
• отправляете разработчику текст такого вида: просьба внедрить конструкцию dataLayer.push () в функцию обратного вызова (код прилагаю к ТЗ), которая вызывается при успешной отправке формы со следующими данными (ниже перечисляете все параметры, которые необходимо передать вместе с формой, чтобы программист вас понял);

Ожидайте, пока разработчик выполнит ваше ТЗ и добавит код на все отслеживаемые формы. На это требуется время. После внедрения вы должны протестировать сформированный уровень данных. Для этого в Google Tag Manager также воспользуйтесь режимом предварительного просмотра., перейдите на сайт и отправьте тестовую форму. В результате одним из событий должно идти с вашим названием:

Посмотрите на вкладке Data Layer вашего события все ли данные правильно переданы в уровень данных:

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

Теперь в Google Tag Manager создайте триггер типа Пользовательское событие с именем, которое вы назначили. В моем примере это formSuccess:

Поскольку в нашем примере в уровне данных еще есть дополнительные переменные, которые мы передаем (речь о formName), то можно создать пользовательскую переменную типа Переменная уровня данных для извлечения значения из нее:

Сохраните настройки. На заключительном шаге создайте тег Google Аналитика – Universal Analytics с типом отслеживания Событие с соответствующими настройками для передачи информации об успешной отправки формы в Google Analytics. Пример:

В Категории передайте произвольное название, в Действии я укажите пользовательскую переменную DLV – formName, которая передает название формы, а в Ярлыке события можно передать URL-адрес страницы, на которой произошло событие отправки формы. Конфигурация тега может быть иной. Главное, чтобы при отслеживании отправки формы с помощью уровня данных и пользовательского события наш триггер был добавлен в качестве условия активации тега, то есть триггер активации – Пользовательское событие, которое было создано на предыдущем шаге.

Способ №5. Отслеживание отправки формы с помощью прослушивателя автоматических событий

Прослушивание автоматических событий — это очень полезная функция в JavaScript, которая позволяет отслеживать определенные взаимодействия пользователя на страницах сайта. При срабатывании запускается событие, которому назначается обработчик (функция, которая отвечает за реакцию на действие пользователя), а само событие помещается в уровень данных (dataLayer). Это событие в дальнейшем можно использовать в качестве триггера активации в Google Tag Manager. Кроме этого, в момент срабатывания события, уровень данных может содержать дополнительную информацию о самом объекте. Помните предыдущий пример, где в dataLayer вместе с отправкой формы передавалась информация по и названию формы?

По умолчанию диспетчер тегов Google предоставляет встроенный прослушиватель (триггер Отправка формы). Но в большинстве настроек он не подходит или не может быть использован. Тогда на помощь приходит прослушиватель автоматических событий. Их еще называют прослушивателями пользовательских событий.

Если вы используете готовый CMS-движок (OpenCart, WordPress, 1С-Битрикс), то, как правило, для них существует ряд готовых решений (модулей, плагинов), которые вы можете приобрести или скачать бесплатно. Например, на своем сайте я использую плагин Contact Form 7.

Подробнее об отслеживании отправки форм с помощью прослушивателя автоматических событий я писал в отдельном материале как раз на примере Contact Form 7.

Способ №6. Отслеживание отправки формы с помощью универсального кода для форм на AJAX

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

AJAX (аббревиатура от Asynchronous JavaScript and XML) – это технология взаимодействия с сервером без перезагрузки страницы. Поскольку не требуется каждый раз обновлять страницу целиком, повышается скорость работы с сайтом и удобство его использования (см. приложение).

Компания Bounteous (ex LunaMetrics) в 2015 году опубликовала в своем блоге бесплатный прослушиватель AJAX событий для диспетчера тегов Google, который прекрасно работает и сейчас для большинства сайтов на этой технологии и который передает информацию на уровень данных.

Все, что требуется сделать, это скопировать код с их страницы и вставить его в тег типа Пользовательский HTML с условием активации триггера на всех страницах сайта (All Pages).

В Google Tag Manager это выглядит так:

Сохраните изменения. Тег будет прослушивать все $.ajax запросы, включая $.post, $.getJSON, $.getScript и другие. Чтобы проверить корректность выполнения, в Google Tag Manager перейдите в режим предварительного просмотра и отправьте тестовую заявку.

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

Выбрав событие ajaxComplete, перейдите на вкладку Data Layer. Здесь отображаются данные, которые были переданы на уровень данных после успешной отправки формы. Каждую строку в dataLayer можно использовать в качестве переменной уровня данных в GTM. Но перед этим следует определить, какая из представленной информации свидетельствует об успешной отправке формы. Чаще всего в этом коде используют значения из двух переменных:

1. statusText;
2. response.

К сожалению, в данном примере никакой информации в response нет, поэтому будем использовать значение success из переменной statusText. Но если бы она была, вы могли бы использовать сообщение, которое отобразилось в message в качестве триггера активации. Пример:

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

Ниже вы увидите перечень событий в хронологическом порядке, точно такой же, какой представлен в режиме отладки GTM. Найдите событие ajaxComplete и раскройте его на всех уровнях с помощью стрелочки:

Найдите ту переменную, которую хотите использовать в качестве переменной уровня данных. Как я написал ранее, я буду использовать statusText со значением success. Нажмите на переменную правой кнопкой мыши и выберите пункт меню Copy property path. Вставьте полученное значение в переменную GTM и удалите все лишнее перед словом attributes, чтобы получилось так:

Каждый уровень пути должен быть разделен точкой (точечная нотация). Если вы будете использовать message, то имя переменной уровня данных в диспетчере тегов будет attributes.response.message, поскольку message находится внутри response, а response внутри attributes.

После этого создайте триггер типа Пользовательское событие с такими настройками:

• Имя события – ajaxComplete;
• Условие активации триггера – statusText содержит success.

Триггер будет срабатывать в случае, если в отправленной форме переменная уровня данных примет значение, содержащее success. Для переменной attributes.response.message триггер тот же самый, только условие активации будет примерно следующим:

Условие содержит будет для каждого свое, в зависимости от того текста, который отображается на вашем сайте после успешной отправки формы и определяется данным прослушивателем в переменной message.

Сохраните триггер. Добавьте тег Google Аналитика – Universal Analytics с типом отслеживания – Событие, в котором задайте собственные настройки и используйте триггер активации ajaxComplete, созданный на предыдущем шаге:

Поскольку мы настроили отслеживание отправки форм как событие, то через некоторое время все данные по событиям появятся в отчете Поведение — События — Лучшие события.

Способ №7. Отслеживание отправки формы с помощью DOM Scraping

Технология получения веб-данных путем извлечения их со страниц сайтов по-английски называется DOM Scraping (Web scraping). Этим мы и будем заниматься.

В таком способе извлечения данных со страницы сайт есть один существенный недостаток — все, что вы будете делать, завязано на объектной модели документа (DOM). И при изменении каких-либо классов, идентификаторов отслеживаемых элементов на сайте есть вероятность потерять текущие настройки. Именно поэтому лучше выполнять отслеживание отправки формы или любых других нестандартных событий на сайте с помощью функций и привлечения разработчика, а не извлекая данные с помощью DOM-скрапинга.

Но такой метод отслеживания тоже существует и давайте разберем его. Например, на сайте после отправки заявки страница перезагрузилась, отображаемый контент поменялся, но URL-страницы не изменился, то есть произошло перенаправление на ту же самую страницу. Такое бывает, но встречается на практике реже (обычно наоборот – страница не перезагружается, а URL меняется). В этом случае нам как раз поможет встроенная переменная Элемент DOM.

Для демонстрации такого способа отслеживания я создал форму с двумя полями: Имя и E-mail.

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

Для отслеживания отправки такой формы вы можете использовать пользовательскую переменную типа Элемент DOM и извлечь значение элемента с текстом Спасибо за вашу подписку…

Чтобы настроить переменную, необходимо сначала проинспектировать данный элемент и узнать его селектор. Откройте консоль разработчика, в которой будет отображен наш подсвеченный элемент в структуре DOM-дерева, нажмите на него правой кнопке и выберите Copy – Copy selector:

В Google Tag Manager создайте пользовательскую переменную типа Элемент DOM, в которой будут следующие настройки:

• Метод выбора – Селектор CSS;
• Селектор элементов – скопированный селектор.

Отправив тестовое обращение, поверьте корректность извлечения данных с помощью режима предварительного просмотра. Если вы указали верный селектор CSS и выбрали событие Container Loaded, то напротив имени вашей переменной отобразится текст сообщения:

Теперь нам нужно создать триггер, который зависит от нашей новой переменной DOM. Я буду использовать тип триггера Просмотр страницы с условием срабатывания Некоторые просмотры страниц – переменная Элемент DOM – содержит – Спасибо за вашу подписку.

Таким образом, триггер будет срабатывать только на тех страницах, на которых посетителям отображается сообщение об успешной подписке. Остается только создать тег Google Аналитика – Universal Analytics с типом отслеживания Событие, а в качестве триггера активации задать Просмотр страницы.

Если вы все сделали правильно, то после отправки формы в режиме отладки должен активироваться тег:

А поскольку тег имеет тип отслеживание Событие, то данные в Google Analytics будут отображаться в отчете Поведение — События — Лучшие события.

Способ №8. Отслеживание отправки формы с помощью виртуальных страниц

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

• обновляете веб-страницу (на которой установлен счетчик веб-аналитики);
• переходите на новую страницу (на которой установлен счетчик веб-аналитики).

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

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

Как правило, при таком отслеживании используется все та же технология AJAX. Наиболее распространенным примером SPA являются сайты на конструкторе Tilda. Тильда передает данные в системы веб-аналитики на основе просмотра страниц. Когда пользователь совершает какое-либо действие на странице, создается виртуальная страница. Подробнее о том, как работают виртуальные страницы, читайте в этой статье.

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

Существует два подхода к анализу статистики:

1. через создание целей и фиксирование событий;
2. через просмотр страниц.

Когда пользователь совершает какое-либо действие на странице: открывает попап, нажимает на кнопку или заполняет форму, создается виртуальная страница. Данные о том, сколько человек «посетили» эту виртуальную страницу (другими словами, открыли попап или нажали на кнопку) всегда доступны в системах аналитики без дополнительных настроек.

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

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

• tilda/popup/rec31654896/opened — для попапа;
• tilda/click/rec31742916/button1— для клика на кнопку;
• tilda/form31751802/submitted — для заполнения формы.

Об этом подробно написано в справочном центре сервиса.

Если вы устанавливаете идентификаторы отслеживания Google Analytics и Яндекс.Метрики через интерфейс Тильды, то просмотры страниц создают автоматически при выполнении пользователями определенных событий. В случае установки кода Google Tag Manager необходимо произвести дополнительные настройки, поскольку в GTM виртуальные страницы по умолчанию не передаются. Вы можете воспользоваться этим руководством и настроить отслеживание отправки формы с помощью виртуальных страниц.

Сначала необходимо создать три пользовательских переменных с типом Переменная уровня данных. Их имена eventAction, referer и title соответственно.

Переменная eventAction отвечает за адрес виртуальной страницы, а именно за формирование уникальной ссылки отправки формы. title – это заголовок формы, который предопределен в Тильде, а referer содержит URL исходной страницы, с которой был осуществлен переход на текущую страницу.

Затем создайте триггер с типом Пользовательское событие и именем pageView:

На завершающем этапе добавьте тег Google Аналитика — Universal Analytics с типом отслеживания Просмотр страницы и следующими настройками:

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

• page – {{eventAction}}
• title – {{title}}
• referrer – {{referer}}

Триггер активации – пользовательское событие pageView

Сохраните изменения. Таким образом, когда пользователь отправит заявку на сайте, сработает событие pageView, а с помощью тега Google Analytics и поля page вы передадите в аналитику просмотр страницы с заголовком и реферера.

Если вы хотите передать такую же информацию в Яндекс.Метрику, то создайте тег типа Пользовательский HTML со следующим кодом:

где XXXXXXXX – идентификатор счетчика Яндекс.Метрики. а конструкция {{ }} ссылается на три наших переменных уровня данных, которые были созданы на шаге ранее.

Подробнее об отправке данных о просмотре страницы в Яндекс.Метрику и методе hit читайте в официальной документации Яндекса (см. приложение).

Выполнить проверку настройки можно с помощью режима отладки Google Tag Manager и отправки тестового обращения. Если вы увидите событие pageView и активированный тег Google Analytics, это значит, что данные успешно отправлены в аналитику, а на вкладке Data Layer будет отображена информация по событию и трем нашим переменным:

О том, как настроить цели в Яндекс.Метрике и Google Analytics для сайтов на Tilda с помощью Google Tag Manager, смотрите в моем видео:

Способ №9. Отслеживание данных брошенных форм

Брошенная форма — это когда пользователь частично или полностью заполняет форму, но не отправляет ее нам по какой-либо причине: отвлекли, передумал, нечаянно закрыл вкладку браузера и не знает, как вернуться назад и т.д. С помощью Google Tag Manager вы можете отслеживать и такие формы.

Алгоритм отслеживания брошенных форм я подробно описал в отдельной статье.

Заключение

Основная проблема с отслеживанием форм в Google Tag Manager — отсутствие единого стандарта создания форм. Разработчик может сделать форму на HTML, а может в AJAX. В каких-то случаях будет достаточно встроенного триггера Отправка формы, а где-то поможет только уровень данных и пользовательское (специальное) событие.