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

Яков Осипенков, 2018

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

Глава 1. Введение в Google Tag Manager

История возникновения систем управления тегами

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

В идеале теги могут преследовать различные цели, в том числе:

● сбор данных из веб-браузеров;

● взаимодействие между различными сайтами;

● интеграция стороннего контента;

● настройка файлов cookie и т.д.

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

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

1. основные теги (first-party tags) запускают cookie для сбора данных в одном домене и облегчают внутренний сбор данных;

2. сторонние теги (third-party tags) запускают cookie для сбора данных в стороннем домене, обычно на стороннем сайте или сайте поставщика (вендора). Теги инициируют сбор данных сторонними серверами.

Эволюция тегов

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

Сторонние теги (Third-Party Tags) — 90-ые

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

Все началось с простых пикселей отслеживания, которые представляли собой небольшие прозрачные изображения, невидимые посетителям сайта, которые загружались с сервера, на котором они размещены. Эти теги-изображения представляли собой пиксель 1×1, который отображался после осуществления определенного действия, например, отправки формы или совершения покупки. Запросы пиксельного изображения у сервера подсчитывались в целях отслеживания действий пользователей на сайте. Изменив его исходный HTML-код, пиксель можно было легко добавить на веб-страницу.

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

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

Тег контейнера (Tag Container) — 00-ые

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

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

Хаос данных в результате «piggybacking»

(объединения тегов)

При реализации нескольких тегов на сайте необходимо расширить диапазон сбора данных. Данная потребность была реализована в основном за счет увеличения расходов на онлайн-рекламу, а рекламные сети объединили теги рекламного сервера в цепочку увеличения охвата аудитории на нескольких сайтах-издателей. Объединение тегов в цепочку называется «piggybacking» и заключается в возможности одного сервера инициировать теги с другого сервера, которые затем по цепочке запускают теги третьего сервера и так далее. То есть теги запускают друг друга по цепочке.

Объединение тегов «piggybacking» расширил аудиторию сайтов, что привело к инновационным подходам к покупке и продаже рекламных объявлений, в том числе тендеры в реальном времени (Real Time Bidding, RTB) и обмен данными. Однако, это привело к хаосу данных, так как владельцы сайтов обычно не могут контролировать теги по цепочке. Стремительный рост маркетинговых тегов поставил на первый план проблему конфиденциальности в связи с непреднамеренными передачами данных и утечки данных третьим сторонам в связи с тем, что владелец сайта не контролирует всю цепочку тегов. Помимо этого, затраты на инициирование тегов увеличиваются, что сказывается на производительности сайта и может привести к потере данных в результате проблем с загрузкой тегов.

Источник информации: https://taginspector.com/evolution-of-marketing-tags/

Google Tag Manager / 2012 год

Рис. 1. Логотип Google Tag Manager

Осенью 2012 года на саммите eMetrics в Бостоне компания Google анонсировала выпуск своего нового продукта — Google Tag Manager. За неполные 6 лет он был установлен на 4 000 000+ сайтов, став самой популярной системой по управлению тегами.

Рис. 2. Топ-9 технологий систем управления тегами по данным similartech.com

В десятку также входят: Tealium (163,963), Adobe Dynamic Tag Management (81,046), Ensighten (37,044), Yahoo Tag Manager (15,317), QuBit OpenTag (9,611), TagMan (7,683), Mezzobit (1,214) и TagCommander (231).

Диспетчер тегов Google (менеджер тегов, тег менеджер, таг манагер, google tag, google tag manager, гугл тег), также известный как GTM (ГТМ), представляет собой бесплатный инструмент, который позволяет легко управлять тегами, размещенными на сайте или в мобильном приложении.

Теги — это небольшие фрагменты кода, как правило, на языке JavaScript, которые собирают информацию о посетителях сайта для их дальнейшего анализа.

В качестве тегов могут быть:

● Код счетчика Google Analytics;

Рис. 3. Код счетчика Google Analytics

● Код счетчика Яндекс.Метрика;

Рис. 4. Код счетчика Яндекс.Метрика

● Отслеживание конверсий AdWords с тегом событий;

Рис. 5. Код отслеживания AdWords

● Google Оптимизация;

Рис. 6. Код Google Оптимизация

● Facebook Pixel;

Рис. 7. Код пикселя Facebook

● Код ретаргетинга Вконтакте;

Рис. 8. Код ретаргетинга Вконтакте

И таких сервисов, которые собирают информацию о пользователях посредством внедрения своего кода на сайт, очень много. Например, теги системы автоматизированной закупки рекламы DoubleClick, популярной ретаргетинг-платформы AdRoll, сервиса по A/B тестированию и оптимизации конверсии Visual Website Optimizer (VWO) и т.д. В качестве дополнительного инструмента веб-аналитики для более глубокого анализа аудитории владельцы сайтов ставят comScore, KISSmetrics, Quantcast, Adobe Analytics и др.

Последние очень распространены на иностранных рынках. Даже если не брать их в счет, для российского интернет-сегмента собирается немаленькое количество. Из примеров выше их уже как минимум 6. Не забываем и про продукты в виде чатов, коллтрекингов, форм обратного звонка, сервисов мультиканальной/омниканальной аналитики. У каждого из них свой JavaScript код, который необходимо добавить на сайт на те страницы, на которых вы хотите отслеживать действия пользователей. А чем больше таких сторонних служб (сервисов), тем выше вероятность замедления работы сайта.

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

● самому ошибиться с внедрением различных кодов в силу незнания правил и разметки веб-страниц;

● получить от программиста перечень пунктов, которые были ему непонятны из ТЗ. В этом случае начнется игра в «настольный теннис»: я сделал все согласно ТЗ, но не работает. Присылайте новое ТЗ;

● сорвать все сроки и дедлайны из-за долгой обратной связи. Вытекает из предыдущего пункта.

Такой вариант внедрения можно представить в виде последовательности шагов:

Рис. 9. Внесение изменений в код сайта без использования Google Tag Manager

1. подготавливается ТЗ из некоторого количества пунктов;

2. список передается разработчику, который просматривает его;

3. если у него нет вопросов, то он внедряет эти пункты. В противном случае мы возвращаемся на шаг 1;

4. код устанавливается на сайт. Если по каким-то причинам это было сделано некорректно, все этапы придется начинать сначала (подготавливать ТЗ, назначать тикеты программисту, писать письма, отправлять фрагменты кода и т.д.).

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

Рис. 10. Внесение изменений через Google Tag Manager

1. устанавливается код Google Tag Manager один раз;

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

3. производится отладка всех процессов и публикуется рабочая версия тегов.

Когда Google выпускал свой продукт больше 5 лет назад, он хотел решить ряд задач, в числе которых:

● ускорение загрузки страниц и работоспособности сайтов путем объединения тегов в одном удобном инструменте;

● экономия времени разработчиков, маркетологов и веб-аналитиков;

● избегания дублирования и ошибок в работе тегов;

● снижение необходимости изменения исходного кода сайта при обновлении или добавлении тегов;

● завоевание доли рынка благодаря бесплатности GTM (да, без этого никуда).

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

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

● фиксация транзакций;

● настройка User ID;

● добавление пользовательских параметров и показателей;

● внедрение уровня данных;

● прочие задачи.

Останавливаться на функциях, описанных выше, мы не будем. Все они подробно разобраны в моей другой книге, которая называется Google Analytics для googлят: Практическое руководство по веб-аналитике.

Таким образом, из преимуществ Google Tag Manager можно выделить:

● бесплатный инструмент — лидер рынка;

● экономит время — не нужно искать разработчиков, которые внедрят изменения на сайт и нет необходимости ждать последующих правок, если первоначальные были сделаны с ошибками;

● снижает зависимость от разработчиков;

● позволяет управлять тегами в едином пространстве — не придется писать дополнительный код или вносить изменения в код отслеживания, вся работа выполняется через веб-интерфейс;

● средства предотвращения ошибок — режим предварительного просмотра (чтобы вы могли видеть предлагаемые изменения перед их внедрением);

● работает быстро благодаря асинхронной загрузке тегов — одновременная (параллельная) загрузка тегов, в результате которой более медленные загружающиеся теги никак не повлияют на скорость выполнения других, более быстрых тегов.

Термины и определения, встречающиеся в работе с GTM

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

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

1. пространство, в котором мы работаем и совершаем какие-либо действия с остальными элементами (тегами, триггерами, переменными);

Рис. 11. Контейнер GTM

.

2. специальный код (скрипт), который размещается на всех страницах сайта и который активирует все остальные теги этого сайта в соответствии с правилами, заданными в интерфейсе. Он состоит из двух частей — один из них размещается в раздел <head>, а второй после открывающего тега <body>.

Рис. 12. Диспетчер тегов Google

Таким образом, контейнер — это глобальный тег (самого верхнего уровня), который позволяет работать GTM с вашим сайтом.

Тег в Google Tag Manager — это фрагмент JavaScript кода, который собирает данные о посетителях на сайте и в приложении, а затем пересылает их на сторонние сервисы — Google Analytics, Google AdWords, Facebook, Яндекс.Метрика и т.д.

Рис. 13. Google Analytics — Global site tag (gtag.js)

В GTM есть n-ое количество шаблонов тегов, которые облегчают их установку на сайте. Они разделены на подгруппы:

Конец ознакомительного фрагмента.