Примечание. На самом деле это не вопрос по программированию. больше из [аналитики/маркетингового тега] принципов кодирования/лучших практик. Поэтому я не совсем уверен, что этот вопрос относится к SO (может быть, одному из других сайтов обмена стеками, возможно, superuser.com?). Но я все равно отвечу здесь.
TL;DR. Вам необходимо привлечь разработчиков сайта и дать им возможность взять на себя некоторый уровень изначальной и постоянной ответственности за него.
Менеджеры тегов продают себя за возможность развертывания тегов без участия разработчиков сайта, и во многих случаях это срабатывает в краткосрочной перспективе. Но по моему опыту, такое пассивное развертывание просто не работает в долгосрочной перспективе, особенно для веб-сайтов, на которых происходят активные и регулярные изменения с течением времени.
По моему опыту, единственный способ эффективно помочь разработчикам сайта непреднамеренно нарушить отслеживание этого — это включить разработчиков сайта в развертывание и заставить их взять на себя ответственность за него на каком-то уровне, чтобы это то, что они осознают в своей собственной системе/потоке.
Иногда это так же просто, как добавить определенные классы или атрибуты в теги html на странице. Например, вы можете написать спецификацию для разработчиков сайта, чтобы добавить data-analytics='true' к любому заголовку, нижнему колонтитулу, CTA-ссылкам на данной странице и сообщить разработчикам сайта, что это то, что им нужно сохранять как часть своего рабочего процесса всякий раз, когда они вносят изменения. на сайт.
Для более сложных вещей вы можете указать, чтобы они делали что-то вроде трансляции пользовательского события, которое вы могли бы прослушать. Например, может быть, у вас есть страница подтверждения покупки, и прямо сейчас у вас есть код в DTM для запуска на основе URL-адреса или очистки страницы для получения подробной информации о покупке для отправки в теги. Вместо этого создайте спецификацию с инструкциями для разработчиков, чтобы поместить это в объект уровня данных и отправить в пользовательское событие, а затем создать для него правило на основе события.
Общая идея здесь состоит в том, чтобы создать документ спецификации для всех вещей, которые вы хотите иметь возможность отслеживать на веб-сайте, которые, как вы знаете, вы не можете надежно пассивно отслеживать, не сломав рано или поздно, и передать документ разработчикам и скажите им, что они должны сделать это частью своего процесса при внесении изменений на сайт. Бонусные баллы, если вы можете заставить их зацикливать вас всякий раз, когда будут внесены изменения и отправлены в производство, что вы можете перейти на свою версию dev/qa вашего сайта, чтобы проверить, чтобы убедиться, что ваше отслеживание все еще выглядит хорошо.
Общая общая тема здесь заключается в том, чтобы разработчики сайта не нарушили ваше отслеживание, вам нужно быть более активными в том, чтобы информировать их и держать их в курсе вашего отслеживания, и на практике это обычно означает добавление некоторых кодовой работы на их тарелке, чтобы владеть, так что это что-то в их истории, перед их лицом, чтобы увидеть и узнать. Потому что разработчику гораздо проще заметить data-analytics='true' в заголовках навигационных ссылок, которые они собираются реструктурировать, чем знать, эй, какая-то часть кода в DTM опирается на эту текущую структуру.. что-то, что не находится более непосредственно впереди своего лица в своем собственном редакторе кода/среде.
Да, на самом деле выполнить вышеперечисленное часто легче сказать, чем сделать. Но это реальность ситуации. Пассивное отслеживание вещей в диспетчере тегов редко работает для долгосрочных вещей, за исключением тегов «каждой страницы», которые практически не требуют настройки.
Я говорю вам из своего собственного опыта более 10 лет работы в индустрии цифрового маркетинга и аналитики, особенно с внедрением, я видел это снова и снова. Слишком много раз, чтобы сосчитать. Клиенты часто хотят и на самом деле выбирают более простой путь, оставляя разработчиков сайта в стороне, все требования по отслеживанию выполняются исключительно с помощью того, на что способен менеджер тегов.
Я видел настройки с сотнями правил с условиями срабатывания, основанными на очистке страницы для некоторого идентификатора или класса, или какого-то сложного селектора CSS, зависящего от 5 уровней структуры html, не меняющейся. Или какой-нибудь случайный файл cookie, который, по вашему мнению, означает именно то, что вы думаете. И вы тратите все больше и больше времени, играя в «убей крота», пытаясь перенастроить/исправить отдельные правила/селекторы по мере того, как происходит следующее случайное изменение, а затем в один прекрасный день происходит полная редизайн сайта, и это ядерная бомба. все ваши усилия по отслеживанию.
И снова и снова, в обязательном порядке, в конце концов, они спрашивают именно то, о чем вы просили здесь, пиная себя под зад за время и деньги, которые они уже потратили на это для этой «быстрой победы», потому что никто не уверен в данные, и они задаются вопросом, почему они выделяют деньги / ресурсы на отслеживание, если это просто куча мусора, сломанных, выбоин данных. И решением этой проблемы всегда была «осведомленность разработчиков сайта».
Если это поможет... одна карта, которую я иногда разыгрываю, если мне трудно убедить команду разработчиков или других сильных мира сего присоединиться к этой победе, состоит в том, чтобы указать, что одна из главных причин для отслеживания веб-сайтов - помочь компаниям. определить, стоит ли вкладывать деньги в указанный веб-сайт. Если они не могут этого определить, то, возможно, они не будут так склонны к этому, что означает, что их потребность даже в команде разработчиков сайта может также отпасть. Чтобы быть более откровенным: это то, что помогает оправдать их работу.
person
Crayon Violent
schedule
31.01.2020
