Google Tag Manager для googлят: Руководство по управлению тегами

● импорт-экспорт контейнеров (формат файла .json);

● связывание внешних аккаунтов (например, DoubleClick Bid Manager с контейнером GTM);

● очередь подтверждения (здесь принимаются запросы на установление связи с аккаунтом DoubleClick Campaign Manager и подтверждение перемещение тегов);

● среды (подробнее в материалах ниже).

Рис. 171. Настройки на уровне контейнера

Импорт-экспорт контейнеров

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

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

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

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

В качестве примера я буду переносить контейнер с настроенными тегами Google Analytics и Яндекс.Метрика. Чтобы экспортировать (выгрузить) контейнер, перейдите в «Администрирование» и выберите «Экспортировать контейнер».

Рис. 172. Администрирование – Экспортировать контейнер GTM

Далее выбираем версию или рабочую область. В рабочей области может .содержаться несколько версий. Например, одна для тегов аналитики, другая для целей и событий, в третьей версии присутствуют изменения по электронной торговле и т.д. При выборе рабочей области экспортируются настройки всех версий. Если же вы хотите скопировать настройки только из конкретной версии, выберите только ее. В нашем случае это последняя 4 версия, которая называется Google Analytics и Яндекс.Метрика.

Рис. 173. Выбираем версию контейнера

В следующем окне нам доступен предварительный просмотр содержимого контейнера. Если все верно, нажимаем «Экспортировать».

Рис. 174. Экспорт контейнера

На компьютер загрузится файл в формате JSON (формат обмена данными на JavaScript).

Рис. 175. Загрузка файла .JSON на компьютер

Что дальше делать с этим файлом? Есть два варианта:

1. сразу же импортировать в новый контейнер;

2. сравнить данные с новым контейнером.

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

Один из наиболее распространенных сервисов сравнения файлов jsondiff.com. Просто указываете два пути к файлам на компьютере и нажимаете «Compare». Все остальное программа сделает за вас, и где надо, подсветить код.

Рис. 176. JSON Diff

Утилита полезна не только при импорте-экспорте контейнеров в Google Tag Manager, но и тогда, когда требуется сравнить изменения в одном файле относительно другого. На изображении выше было найдено 26 различий, которые JSON Diff подсветил, а выделенная область синим указывает лишь на то, что два контейнера имеют разные accountID.

Познакомившись немного с инструментов diff, переходим к импорту нашего контейнера. Для этого переходим в контейнер, в который хотим загрузить новые настройки. Раздел «Администрирование» – «Импортировать контейнер».

Рис. 177. Администрирование – Импортировать контейнер GTM

Загружаем файл, который мы экспортировали, и выбираем рабочую область. Рекомендация: если у вас уже есть настройки в текущем контейнере, лучше создавать новую рабочую область. Если контейнер пустой, но можно в «Существующая».

Рис. 178. Импорт контейнера

Выбираем вариант импорта:

● перезаписать – все старые настройки заменятся на новые;

● объединить – данные двух контейнеров будут объединены. При этом могут возникнуть ошибки. Чтобы это исправить, перезапишите, либо переименуйте конфликтующие теги, триггеры или переменные.

Рис. 179. Подробные изменения в контейнере

В предварительном просмотре Google Tag Manager визуально сообщит нам о том, какие теги, триггеры и переменные будут созданы, изменены или удалены. Можно посмотреть подробных список изменений, нажав на «Показать подробные изменения». Если все сделали правильно, остается только «Подтвердить».

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

P. S. В интернете есть большое количество готовых JSON-файлов для Google Tag Manager. Например, компания LunaMetrics на своем сайте lunametrics.com/labs/recipes/публикует различные решения с подробным описанием. Analytics Mania в своем блоге также собрала «рецепты» от разных команд и веб-аналитиков, в числе которых: Simo Ahava, David Vallejo, Pat Grady, Daniel Carlbom и другие.

Среды

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

Рис. 180. Пример версий

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

Рис. 181. Версии

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

Рис. 182. Задание среды для публикации

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

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

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

Рассмотрим пример, в котором у нас есть две версии сайта:

1. тестовый вариант, над которым разработчики ведут работы (недоступен широкой публике);

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

Рис. 183. Пример версий сайтов

Обе версии являются копиями одного и того же сайта, и оба используют один и тот же контейнер Google Tag Manager. Но вы не будете публиковать версию тестового варианта, поскольку она сырая и над ней ведутся работы по устранению ошибок.

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

Рис. 184. Две среды разработки: конечная и промежуточная

В приведенном выше примере у нас есть две среды: конечная (live, 3) и тестовая (промежуточная, 4). Конечная среда будет содержать теги, которые мы хотим запустить на сайте, а промежуточная среда будет включать в себя дополнительные теги, которые либо проходят тестирование, либо не готовы к публикации в финальной версии.

Чтобы получить доступ к средам, перейдите в раздел «Администрирование» и откройте «Среды» на уровне контейнера.

Рис. 185. Администрирование – Среды