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

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

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

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

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

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