Примечание: на самом деле это не актуальный вопрос кодирования; больше принципов / лучших практик кодирования [аналитика / маркетинговый тег] Так что я не совсем уверен, что этот вопрос относится к SO (может быть, один из других сайтов обмена стека, возможно, superuser.com?). Но я все равно отвечу здесь.
TL; DR - Вам нужно вовлечь разработчиков сайта и заставить их принять на себя некоторый уровень первоначального и постоянного владения им.
Менеджеры тегов продают себя за возможность развертывания тегов без привлечения разработчиков сайта, и во многих случаях это срабатывает в краткосрочной перспективе. Но, по моему опыту, такого рода пассивное развертывание просто не сработает в долгосрочной перспективе, особенно для веб-сайтов, на которых со временем происходят активные и регулярные изменения.
По моему опыту, единственный способ эффективно предотвратить непреднамеренное нарушение отслеживания разработчиками сайта этого - это включить разработчиков сайта в развертывание и заставить их стать владельцем этого сайта. некоторый уровень, так что это то, что они знают в своей собственной системе / потоке.
Иногда это так же просто, как добавить назначенные классы или атрибуты к тегам html на странице. Например, вы можете написать spe c для разработчиков сайта, чтобы добавить data-analytics='true' к любому заголовку, нижнему колонтитулу, ссылкам CTA на данной странице, и сообщить разработчикам сайта, что это то, что им нужно сохранить как часть их рабочий процесс всякий раз, когда они вносят изменения в сайт.
Для более сложных вещей вы можете указать c, чтобы они делали что-то вроде трансляции пользовательского события, которое вы могли бы прослушать. Например, может быть, у вас есть страница подтверждения покупки, и сейчас у вас есть код в DTM, который можно активировать на основе URL-адреса, или очистите страницу для получения сведений о покупке, добавив теги sh. Вместо этого создайте spe c с инструкциями для разработчиков, чтобы поместить его в объект уровня данных и pu sh в пользовательское событие, а затем создайте для него правило на основе событий.
Общая тема здесь - создать документ spe c для всех вещей, которые вы хотите отслеживать на веб-сайте, которые, как вы знаете, невозможно надежно пассивно отслеживать, не нарушая их раньше или позже. и передайте документ разработчикам и скажите им, что они должны сделать его частью своего потока при внесении изменений в сайт. Бонусные баллы, если вы можете получить их до oop вас, когда изменения будут внесены и запущены в производство, что вы можете go вашей версии сайта dev / qa протестировать, чтобы убедиться, что ваше отслеживание все еще выглядит хорошо.
Общая тема общая здесь предназначена для того, чтобы разработчики сайтов не могли нарушить ваше отслеживание, вам нужно быть более проактивным, чтобы делать их и держать их в курсе вашего отслеживания, и на практике, обычно это означает, что часть кода работает на их пластинке, так что это что-то в их истории, перед их лицом, чтобы увидеть и узнать о ней. Поскольку для разработчика гораздо проще заметить data-analytics='true' в ссылках навигации заголовка, которые они собираются реструктурировать, чем знать, эй, некоторый фрагмент кода в DTM опирается на эту текущую структуру ... что-то не более прямое перед их лицом в их собственном редакторе кода / среде.
Да, на самом деле выполнение вышеупомянутого часто легче сказать, чем сделать. Но это реальность ситуации. Пассивное отслеживание вещей в менеджере тегов редко работает в долгосрочной перспективе, за исключением тегов «каждая страница», которые не предъявляют особых требований к настройке или не требуют их вообще.
Я расскажу вам о своем собственном опыте более 10 лет работы в индустрии цифрового маркетинга и аналитики, особенно с внедрением, который я видел снова и снова. Слишком много раз, чтобы сосчитать. Клиенты часто хотят и фактически выбирают более простой путь выхода из сайта разработчиков из l oop, причем все требования к отслеживанию выполняются исключительно благодаря тому, на что способен менеджер тегов.
Я видел установки с сотнями правил с условиями триггера, основанными на очистке страницы для некоторого идентификатора или класса, или какого-то сложного селектора css, зависящего от 5 уровней структуры html, которая не меняется. Или какой-нибудь случайный повар ie, который вы просто предполагаете, означает, что вы думаете, что это значит. И вы тратите все больше и больше своего времени, играя в «бей-моль», пытаясь перенастроить / исправить отдельные правила / селекторы, когда произойдет следующее случайное изменение, а затем однажды наступит полная модернизация сайта, и это ядерная бомба на все ваши усилия по отслеживанию.
И снова и снова, в конце концов, в конце концов они в конечном итоге спрашивают, что именно вы спросили здесь, пинают себя в задницу за время и деньги, которые они уже потратили на это для этой "быстрой победы", потому что никто не уверен в данных, и они задаются вопросом, почему они выделяют деньги / ресурсы на отслеживание, если это просто куча tra sh, разбитых, выбоин данных. И решением этой проблемы всегда была «осведомленность разработчиков сайта».
Если это поможет ... одна карта, которую я иногда разыгрываю, если мне трудно убедить команду разработчиков или другие силы в том, чтобы запрыгнуть на эту команду, - это указать, что одна из главных причин Отслеживание веб-сайтов должно помочь компаниям определить, стоит ли вкладывать деньги в указанный веб-сайт. Если они не могут определить это, то они могут быть не настолько склонны к этому, что означает, что их потребность даже в команде разработчиков сайта также может уменьшиться. Чтобы быть более откровенным: это то, что помогает оправдать их работу.