Рис. 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;
