Обзор альтернативной схемы передачи данных о конверсиях через Google Tag Manager и инструкция по настройке
Дата публикации: 18.12.2017
Большинство интернет-маркетологов и аналитиков уже познакомились с Google Tag Manager (GTM). Многие даже стали применять его на своих сайтах: поставили через него базовые скрипты счётчиков Google Analytics и Яндекс Метрики. Мы заметили, что чаще всего передача данных о конверсионных действиях на сайте всё равно производится напрямую с сайта в счётчики аналитики. При этом, уровень данных не используется, что нередко приводит к прямым и косвенным потерям времени. Это происходит примерно так:
Для каждого инструмента отслеживания синтаксис передачи данных о конверсиях разный. Это приводит к тому, что после установки каждого нового инструмента отслеживания (например, пикселя Facebook) необходимо повторно задействовать разработчиков сайта: просить их добавить дополнительный скрипт, который будет вызываться после конверсионного действия. Срок выполнения такого ТЗ иногда исчисляется в днях, а настроить цели надо было ещё вчера. При этом любые изменения, связанные с текущими конверсионными действиями или с добавлением новых, также придётся отражать в нескольких разных скриптах — по одному на каждый счётчик.
Необходим сайт, мобильное приложение, услуги по SEO или контекстной рекламе? Тендерная площадка WORKSPACE поможет выбрать оптимального исполнителя. База проекта насчитывает более 10 500 агентств. Сервис работает БЕСПЛАТНО как для заказчиков, так и для исполнителей.
Предлагаем рассмотреть альтернативную схему передачи данных о конверсиях:
Она предполагает передачу всех данных, которые могут вам понадобиться при настройке целей (как сейчас, так и в будущем), в уровень данных, а уже оттуда — куда угодно.
Преимущества данного варианта:
Экономия времени разработчиков сайта: сокращает количество ваших взаимодействий с ними, а также сокращает объёмы ТЗ для них (соответственно, экономит и ваше время, затраченное на проверку правильности выполнения ТЗ);
Расширение спектра возможностей в настройке сбора данных, большая гибкость для вас как аналитика/маркетолога. Имея всю информацию в уровне данных, вы можете настроить сложное условие срабатывания определённого скрипта (сложную цель и т.п.) на основе любой комбинации имеющихся параметров, и всё это без дополнительных ТЗ для разработчиков.
Ускорение настройки отслеживания целей и добавления новых инструментов отслеживания.
Конечно, есть и недостатки:
Немного больше времени придётся уделить настройкам в интерфейсе GTM;
Передавать данные в уровень данных редко возможно при отслеживании конверсий через виджеты некоторых сервисов (JivoSite, LiveTex и т.п.), потому что они, как правило, отправляют события в счётчики аналитики стандартным способом: вы не можете заставить их отправлять информацию в уровень данных (иногда частично решается с помощью техподдержки).
Скорее всего, вы уже:
Умеете настраивать цели на события в GA и Метрике стандартным способом, проверять корректность настройки целей;
Вдалеете базовой терминологией (теги, триггеры и т.п.) GTM и знакомы с принципами работы его;
Умеете устанавливать счётчики GA, Метрики и другие скрипты через GTM;
Поэтому мы не будем подробно останавливаться на этих этапах, а сразу перейдём к передаче данных о конверсиях.
Рекомендуем использовать такой скрипт передачи информации в уровень данных (по умолчанию уровень данных обозначен как dataLayer, но название может быть иным — например, если вам приходится использовать 2 разных таких объекта, так как один из них уже используется каким-либо сервисом или CRM, и трогать его запрещают разработчики) — именно поэтому мы предпочитаем писать «уровень данных», а не «dataLayer»):
С таким скриптом вам не придётся задумываться, вызывается он раньше или позже самого скрипта контейнера GTM в коде сайта. Сработает в любом случае.
Как это часто бывает с GTM, понимание лучше всего формируется через практику, поэтому рассмотрим типовой пример.
Предположим, у нас есть сайт с одной конверсионной формой: «Отправить запрос поставщику». Всего есть 3 поставщика, клиент может выбрать любого и отправить запрос именно ему, а вы хотите всё это отслеживать:
Теперь нужно настроить передачу всей информации в уровень данных. Для этого непосредственно после успешной отправки формы на сайте должен вызываться следующий скрипт:
В нашем случае значение параметра eventLabel может быть одним из трёх:
-
Поставщик_1
-
Поставщик_2
-
Поставщик_3
Это даёт нам исчерпывающую информацию по конверсионной форме.
Теперь создаём недостающие переменные в GTM (мы назвали переменные в соответствии с логикой отслеживания событий в GA, но вы можете назвать их иначе, если хотите; главное — убедитесь, чтобы в скрипте на сайте и в настройках GTM названия соответствовали):
Остальные — по аналогии:
Переменная «Event» — одна из стандартных, убеждаемся, что она включена, если нет — включаем:
Теперь GTM готов к приёму данных. Осталось настроить перенаправление информации о конверсиях из уровня данных в счётчики аналитики.
Начнём с Google Analytics. Создаём тег Universal Analytics с любым удобным названием (например, укажем, что это отправка формы), тип — событие, настройки — как на скриншоте ниже.
В двойных фигурных скобках {{}} указываются параметры, значения которых будут соответствовать их значениям из уровня данных. Например, если на сайте срабатывает такой скрипт:
То получим такое событие в GA:
Необходимо также назначить триггер для этого тега. Настроим его на пользовательское событие «form_sent», именно это мы указали в качестве значения переменной «event» в нашем ТЗ:
Осталось настроить цели в Google Analytics. Так будет выглядеть цель на отправку формы первому поставщику:
А если для вас не имеет значения, какому поставщику отправлена форма, просто уберите третий параметр (ярлык). С такими настройками, как на скриншоте ниже, цель будет срабатывать при отправке формы любому поставщику:
Теперь настроим отправку события в Яндекс Метрику:
Где XXXXXX — номер вашего счётчика Метрики (не забывайте перепроверять это значение, особенно когда переносите одни и те же теги в другие контейнеры GTM; возможно, вам будет удобнее даже создать свою переменную типа константа, присвоить ей нужное значение, назвать её {{код Метрики}} и подставить вместо XXXXXX).
Триггером для этого тега можно назначить тот же триггер, который мы назначали в случае с GA.
Обратите внимание: в отличие от GA, в Метрике предусмотрен всего один идентификатор события (в GA их 3, если не считать «Ценность события»). Как быть, если мы хотим отслеживать отправку конкретному поставщику? Ничто не мешает нам склеить все три идентификатора типа GA в один идентификатор типа Метрики. Например, при отправке формы первому поставщику Метрика получит событие с таким идентификатором:
«lead_form_1_Поставщик_1»
Так и настроим нашу цель:
Остальные цели настраиваются по аналогии.
Метрика, как и GA, воспринимает кириллицу в идентификаторах события, т.е. вариант с написанием «Поставщик_1» будет работать. Но это не избавляет вас от необходимости после настроек всегда тщательно проверять работоспособность решения. Если изначально не уверены, что кириллица вам подойдёт — проверьте сразу либо откажитесь от неё.
По такой же логике вы теперь сможете настраивать передачу данных о конверсиях и в другие инструменты. Например, тег передачи данных о конверсии в пиксель Facebook может выглядеть следующим образом (параметры, конечно, можете назвать иначе — так, как вам удобно):
Триггер можно использовать тот же, что и раньше.
Итак, мы настроили передачу информации с сайта в уровень данных, затем через GTM настроили передачу информации о конверсиях в аналитические/маркетинговые инструменты, осталось проверить, всё ли работает как надо.
Включаем функцию предварительного просмотра в GTM:
Заходим на наш сайт в том же браузере, где открыт GTM, совершаем конверсионное действие и смотрим, отобразилось ли оно в GA, в Метрике, в Facebook и в других инструментах, в которых вы ожидаете их увидеть.
Для проверки отправки события в реальном времени мы пользуемся следующими плагинами для Chrome, но вы можете использовать любые другие решения, удобные для вас (например, отчёты в реальном времени в GA):
Плагин Google Analytics Debugger для проверки Google Analytics;
Плагин WASP.inspector для проверки Яндекс Метрики;
Плагин Facebook Pixel Helper для проверки Facebook.
Чтобы проверить, правильно ли вы написали скрипт отправки информации в уровень данных, после произведения всех настроек можете скопировать его (без тегов ) в консоль браузера, нажать Enter и посмотреть на результат:
Если проверка показала, что всё работает корректно, можно публиковать контейнер GTM.
На что ещё стоит обратить внимание:
Крайне желательно, чтобы все инструменты отслеживания, в которые вы планируете отправлять данные таким способом, стояли не в коде сайта, а в GTM. Только так вы сможете надёжно контролировать порядок срабатывания скриптов (главное правило — основной скрипт отслеживания аналитического инструмента должен всегда вызываться раньше, чем скрипт передачи в него данных о событии, иначе ничего не произойдёт);
Вытекает из первого пункта: не забывайте ставить приоритеты тегов. Скорее всего, вам достаточно будет поставить более высокий приоритет тегам основных скриптов отслеживания, как на скриншоте ниже это сделано с тегом GA:
Заключение
Надеемся, данная статья убедила вас в том, что имеет смысле пересмотреть ваше отношение к аналитике, начав передавать данные о конверсиях через уровень данных, и стала для вас исчерпывающей инструкцией по настройке.
