Данные могут собираться на стороннем сервере сбора данных или в центре сбора данных. Теги можно подразделить на две группы в зависимости от функций:
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? Все верно, как минимум писать разработчику ТЗ с подробными инструкциями