Google Tag Assistant: Preview и Debug в GTM

Изменения в Google Tag Manager лучше проверять до публикации контейнера. Даже правильно настроенный на первый взгляд тег может сработать дважды, запуститься не на том событии, получить пустую переменную или передать в Google Analytics 4 неправильный параметр. Preview Mode и Google Tag Assistant помогают увидеть такую ошибку во время тестирования, пока она ещё не влияет на реальные данные.

Проверка строится вокруг конкретного пользовательского сценария. Специалист открывает сайт через Preview, выполняет нужное действие и смотрит, какое событие появилось, какой триггер отработал, какие значения получили Variables и что попало в Data Layer. Для аналитики этого обычно достаточно, чтобы понять причину проблемы ещё до публикации новой версии контейнера.

Google Tag Assistant используется как основное окно диагностики. В нём можно просматривать события, найденные Google tag и GTM container ID, отправленные hits, изменения уровня данных и историю переходов между страницами. Если событие должно попадать в GA4, финальную проверку удобно дополнить через GA4 DebugView.

Что такое Preview, Debug и Google Tag Assistant в GTM?

Preview, Debug и Tag Assistant относятся к одному процессу проверки, но обозначают разные его части. Preview запускает предварительный просмотр текущей рабочей версии контейнера, Debug показывает технические данные о происходящих событиях, а Tag Assistant предоставляет интерфейс, в котором специалист разбирает результаты теста.

Такой подход особенно полезен перед изменением конверсий, ecommerce-событий, отслеживания форм, кликов, телефонов и других действий, от которых зависят отчёты или рекламные кампании. Ошибка в одном условии триггера способна изменить статистику сразу после публикации, поэтому диагностику проводят на конкретных сценариях.

Что такое режим Preview в Google Tag Manager?

Preview Mode запускается из рабочей области Google Tag Manager и открывает текущую версию контейнера для тестирования. Публиковать изменения перед этим не требуется. Специалист может проверить новый тег или триггер в рабочем состоянии, хотя обычные посетители сайта ещё используют опубликованную версию контейнера.

Для запуска нужно открыть нужный Workspace и выбрать Preview. После этого GTM открывает Google Tag Assistant, где указывается адрес тестируемой страницы. После подключения можно переходить по сайту, нажимать кнопки, отправлять формы и выполнять другие действия, которые должны вызывать настроенные события. Google использует именно эту последовательность в актуальной инструкции по проверке тегов.

Preview полезен ещё и тем, что показывает работу связанных настроек вместе. Если custom event появился, но нужный тег не сработал, причину можно искать в условиях Triggering. Если тег сработал, но параметр пустой, проверяют Variables и данные события. Такой разбор быстрее обычной проверки только по итоговым отчётам аналитики.

Что такое Debug Mode?

Debug Mode показывает техническую последовательность действий внутри тестовой сессии. В нём видны события загрузки страницы, пользовательские события, срабатывания тегов, передаваемые данные и другие элементы, которые участвуют в обработке текущего сценария. Обычные посетители сайта эту служебную информацию не видят.

Режим особенно полезен при настройке сложных цепочек. Например, отправка формы может сначала записать данные в Data Layer, затем создать custom event, активировать триггер и только после этого запустить GA4 Event Tag. Если цепочка прерывается, Debug помогает определить конкретный этап, на котором перестают появляться ожидаемые данные.

Debug не стоит воспринимать как отдельную замену Preview. В стандартной работе специалист запускает Preview, подключает сайт через Tag Assistant и уже внутри этой сессии получает диагностическую информацию. После окончания проверки сессию можно остановить и перейти к исправлению настройки или публикации контейнера.

Для чего нужен Google Tag Assistant?

Google Tag Assistant показывает, какие Google-теги обнаружены на странице и что происходило с ними во время тестовой сессии. Через него можно проверить наличие GTM, открыть подробную диагностику, просмотреть события и понять, какие данные были отправлены для выбранного Google tag или контейнера.

Инструмент помогает находить распространённые проблемы: отсутствующий тег, дублирование, неправильную конфигурацию, ошибочную передачу данных или ситуацию, когда нужное действие пользователя вообще не вызывает ожидаемое событие. Актуальное расширение также показывает найденные на текущей странице Google-теги в боковой панели браузера.

При проверке нужно смотреть не только на наличие GTM. Сам факт загрузки gtm.js ещё не подтверждает корректную работу аналитики. Важно пройти нужный сценарий пользователя и сопоставить событие, триггер, состояние тега, значения переменных и фактически отправленные параметры.

Нужно ли скачивать Google Tag Assistant?

Google Tag Assistant существует в двух связанных вариантах: как web-интерфейс для debug-сессий и как расширение для Chrome. Поэтому запрос google tag assistant download не всегда означает, что без установки расширения режим предварительного просмотра работать не будет. Preview из Google Tag Manager сам открывает интерфейс Tag Assistant и предлагает подключить тестируемый сайт.

Расширение удобно для постоянной работы с тегами. Оно показывает найденные Google-теги прямо в браузере и открывает расширенную диагностику через Troubleshoot tag. Google рекомендует его для сценариев с iframe, новыми окнами, несколькими вкладками и другими случаями, где обычной web-сессии может быть недостаточно.

В 2026 году стоит пользоваться актуальной объединённой версией расширения. Старые материалы могут отдельно упоминать Tag Assistant Legacy и Tag Assistant Companion, однако Google уже свёл их возможности в одно расширение Tag Assistant для Chrome. Это нужно учитывать при поиске инструкций и скриншотов.

Где скачать Google Tag Assistant?

Актуальное расширение устанавливают из Chrome Web Store. Искать сторонние сборки, архивы расширений или файлы для ручной установки не требуется. После установки Tag Assistant появляется среди расширений Chrome и может открыть боковую панель с обнаруженными на текущей странице тегами.

Перед установкой полезно проверить издателя и название расширения, особенно если переход выполняется не из официальной справки Google. Старые версии материалов могут вести на Legacy или Companion, хотя сейчас Google описывает единое расширение Tag Assistant как основной вариант для Chrome.

Для разовой проверки GTM пользователь может начать непосредственно с кнопки Preview внутри контейнера. Если же диагностика проводится регулярно, установка расширения экономит время и открывает дополнительные возможности для сайтов со сложными переходами, iframe и несколькими окнами.

Как установить Google Tag Assistant?

Чтобы установить Google Tag Assistant, откройте Chrome Web Store, найдите официальное расширение и добавьте его в браузер. После установки откройте нужный сайт и нажмите значок Tag Assistant. Справа появится панель, где можно увидеть найденные на странице Google-теги и перейти к подробной диагностике.

Если расширение должно работать только на определённых доменах, проверьте его разрешения для сайтов. Отсутствие права читать данные текущей страницы иногда становится причиной ситуации, когда тег установлен, но расширение его не видит. Для корпоративного Chrome установка расширений также может ограничиваться политиками организации.

В боковой панели доступны действия для установки или диагностики тега. Кнопка Troubleshoot tag открывает tagassistant.google.com и запускает debug session, где уже можно просматривать последовательность событий и отправляемые данные. Такой порядок описан в актуальной справке Google.

Нужно ли устанавливать Tag Assistant Companion?

Для новой установки Tag Assistant Companion не нужен. Google объединил функции Tag Assistant Legacy и Companion в одном расширении Tag Assistant. Если в старой инструкции предлагается отдельно поставить Companion для соединения сайта с окном отладки, эту часть инструкции нужно сверять с актуальным интерфейсом.

Companion всё ещё может встречаться на старых компьютерах, в статьях прошлых лет и на скриншотах специалистов. Это объясняет путаницу, когда пользователь видит разные названия инструментов для одной и той же задачи. Google указывает, что объединённое расширение заменяет прежнюю схему с двумя отдельными дополнениями.

Удалять рабочее Legacy вручную только ради обновления обычно не требуется, поскольку Google переводит его на новую версию. Для новой настройки лучше сразу ориентироваться на текущий Tag Assistant и актуальные пункты интерфейса, чтобы не искать функции, которые уже перенесли или переименовали.

Работает ли Google Tag Assistant в Safari?

Запрос google tag assistant safari чаще всего возникает у пользователей, которые хотят проверить GTM на Mac без перехода в Chrome. Web-интерфейс Tag Assistant можно использовать отдельно от браузерного расширения, поэтому обычное подключение сайта через Preview не стоит путать с установкой дополнения для конкретного браузера.

При этом официальное расширение Google Tag Assistant предназначено для Chrome. Отдельную актуальную Safari-версию расширения Google в документации не предлагает. Если требуется только стандартная debug session, можно начать с Preview и web-интерфейса. Для сложной диагностики удобнее использовать Chrome с официальным дополнением.

Выбор браузера особенно заметен при проверке iframe, всплывающих окон и нескольких открытых страниц. Здесь расширение даёт функции, которых может не хватать в обычной сессии. Если проблема воспроизводится только в Safari, сам пользовательский сценарий всё равно стоит проверить именно в Safari, даже если техническую диагностику дополнительно проводят через Chrome.

Есть ли расширение Google Tag Assistant для Safari?

Отдельного официального расширения Google Tag Assistant для Safari в актуальной документации нет. Основное браузерное расширение выпускается для Google Chrome. Поэтому устанавливать непроверенные сторонние дополнения только ради похожего названия не стоит.

Для стандартного тестирования можно открыть Google Tag Manager, запустить Preview и подключить URL через web-интерфейс Tag Assistant. Если сайт соединяется корректно, этого достаточно для большинства проверок событий, триггеров и тегов. Расширение становится особенно полезным при более сложных сценариях.

Если задача связана именно с поведением сайта в Safari, проверку пользовательской части нельзя полностью заменять Chrome. Например, форма или consent banner могут работать в браузерах по-разному. В таком случае техническую настройку GTM проверяют через доступные инструменты, а сам сценарий дополнительно воспроизводят в Safari.

Какие функции могут отличаться без Chrome-расширения?

Google рекомендует установить Chrome-расширение для диагностики Google tag внутри iframe. Оно также помогает отлаживать pop-up windows и новые вкладки, открывать debug-окно в обычной вкладке браузера и работать с несколькими окнами в пределах одной сессии.

Без этих функций базовая проверка не обязательно перестаёт работать. Разница проявляется тогда, когда тег загружается в нестандартном контексте или пользовательский путь выходит за пределы обычной последовательности страниц. Поэтому сначала стоит определить, какой именно сценарий требуется проверить.

Если обычная страница открывается, события появляются и нужный контейнер определяется, переходить в другой браузер только ради формальности не требуется. Когда соединение обрывается на iframe или после открытия нового окна, Chrome с актуальным расширением становится более подходящим вариантом для диагностики.

Как пользоваться Google Tag Assistant в GTM?

Для проверки изменений нужен конкретный сценарий. Например, если настраивается отправка формы, недостаточно открыть главную страницу и убедиться, что контейнер загрузился. Нужно пройти путь до формы, заполнить поля, выполнить отправку и найти соответствующее событие в Tag Assistant.

Дальше проверка идёт от события к данным. Сначала выбирают событие, затем смотрят состояние нужного тега, условия его запуска, Variables и Data Layer. Если тег отправляет данные в GA4, дополнительно проверяют название события и параметры. Для ecommerce-сценария отдельно смотрят items, value, currency и другие передаваемые значения.

Рабочую цепочку можно представить так:

Действие пользователя → событие → триггер → тег → hit → система аналитики.

Если итоговый hit отсутствует, нужно двигаться по этой цепочке назад и находить первый этап, где ожидаемые данные перестали появляться.

Как запустить Preview Mode из Google Tag Manager?

Откройте контейнер GTM, в котором находятся тестируемые изменения, и перейдите в рабочую область. Нажмите Preview. Google Tag Manager откроет Tag Assistant в новой вкладке, после чего потребуется ввести URL страницы и выбрать Connect.

После подключения откроется тестируемый сайт. Выполните действие, которое должно вызвать нужный тег: перейдите на страницу, нажмите кнопку, отправьте форму или завершите тестовую покупку. Затем вернитесь в окно Tag Assistant и найдите соответствующее событие в последовательности сессии.

Перед анализом проверьте Container ID. На сайте одновременно могут работать несколько Google tag или контейнеров, а информация в интерфейсе фильтруется по выбранному идентификатору. Если смотреть другой контейнер, нужный hit может отсутствовать, хотя само событие на странице произошло.

Как подключить сайт к Tag Assistant?

URL для подключения должен начинаться с https:// или http://. После ввода адреса Tag Assistant открывает страницу в режиме диагностики и добавляет debug signal. В актуальной документации Google для такой сессии указан параметр _dbg, который помогает передавать признак отладки в связанные инструменты, включая GA4 DebugView.

Подключение считается успешным, когда тестируемая страница открылась, а Tag Assistant начал получать информацию о событиях и тегах. После этого можно переходить между страницами одного домена и выполнять нужный сценарий. События будут добавляться в текущую debug session.

Если добавленный параметр меняет поведение сайта, в настройках подключения можно отключить Include debug signal in the URL и повторить попытку. Такой вариант полезен для проектов, где GET-параметры обрабатываются маршрутизацией, защитой, редиректами или собственной логикой приложения.

Как читать интерфейс Tag Assistant?

После подключения не нужно открывать каждую вкладку подряд. Сначала определите нужное действие пользователя и найдите соответствующий момент в хронологии событий. Затем выберите правильный Google tag или GTM container ID и переходите к деталям выбранного события.

Удобнее сравнивать ожидаемый сценарий с фактическим. Если после отправки формы ожидается generate_lead, сначала убедитесь, что событие вообще появилось. Затем проверьте тег, его параметры и переданный hit. Такой порядок быстрее случайного просмотра десятков системных событий.

В актуальном интерфейсе события группируются по страницам, а Output показывает hits для выбранного идентификатора. Если обнаружено несколько тегов или контейнеров, между ними можно переключаться.

Summary

Summary даёт общий обзор текущей debug-сессии. Здесь удобно начинать проверку после выполнения пользовательского действия, особенно если на странице работает несколько тегов. Сводка помогает понять, какие события и отправки данных появились в выбранной части сессии.

Не стоит делать вывод только по наличию строки с названием тега. Для конверсии важнее связать её с правильным действием и проверить параметры. Если один и тот же hit появился дважды после одного клика, это уже повод искать дублирующий тег, второй триггер или повторную отправку события.

При переходе между страницами сессия сохраняет историю, поэтому можно разбирать путь пользователя последовательно. Это удобно для корзины, многошаговой формы, авторизации и других сценариев, где целевое событие зависит от нескольких предыдущих действий.

Список событий

Слева отображается последовательность событий, которые Tag Assistant получил во время сессии. В GTM часто встречаются системные стадии Page View, DOM Ready и Window Loaded, после которых появляются клики, custom event и другие события конкретного сайта.

Событие нужно выбирать по смыслу действия, а не только по позиции в списке. Если пользователь нажал кнопку, но ожидаемый event отсутствует, проблема может находиться ещё до настройки тега: обработчик не отправил событие, Data Layer не получил данные или триггер слушает другой тип действия.

На динамических сайтах список событий особенно полезен для SPA. Переход внутри интерфейса может не создавать обычную перезагрузку страницы, поэтому нужно смотреть, какое событие реально появляется при смене экрана и на чём настроен соответствующий триггер.

Tags Fired и Tags Not Fired

Tags Fired показывает теги, которые выполнили условия запуска на выбранном событии. Если нужный GA4 Event Tag находится в этой группе, следующим шагом становится проверка его параметров и фактической отправки данных. Само наличие в Fired ещё не гарантирует правильность всей настройки.

Tags Not Fired содержит теги, которые были доступны контейнеру, но не выполнили условия текущего Triggering. Это полезный блок, когда ожидаемый тег не сработал. Можно открыть его детали и сравнить реальные значения переменных с условиями, заданными в триггере.

Не каждый тег из Not Fired означает ошибку. Тег покупки не обязан запускаться на Page View, а тег отправки формы не должен срабатывать при обычном клике по меню. Оценивать состояние нужно только относительно ожидаемой логики конкретного события.

Variables

Variables показывают значения переменных на выбранном этапе сессии. Здесь удобно проверять Page URL, Click Text, Click Classes, идентификаторы элементов, пользовательские переменные и значения, которые были получены из Data Layer.

Если условие триггера выглядит правильным, но тег остаётся в Tags Not Fired, сравните ожидаемое значение с фактическим. Например, триггер ждёт /thank-you/, а переменная содержит полный URL с параметрами или другой завершающий слэш. Для GTM такое различие может быть критичным.

Переменные также помогают находить ошибки после изменения сайта. Разработчик может переименовать CSS-класс кнопки или изменить DOM, из-за чего старый Click Trigger перестанет выполнять условие. Preview показывает это сразу во время тестового клика.

Data Layer

Data Layer хранит данные, которые страница передаёт в Google Tag Manager через dataLayer.push() и связанные механизмы. При настройке событий здесь проверяют название event, идентификаторы, параметры ecommerce, значения формы и другие данные, которые должны использовать теги.

Для purchase мало увидеть само название события. Нужно проверить структуру items, сумму value, currency, transaction ID и другие параметры, предусмотренные конкретной настройкой. Пустое или неправильное значение может попасть в аналитику даже тогда, когда тег формально сработал.

При поиске ошибки сравнивайте Data Layer с Variables. Если данные присутствуют в слое, но переменная GTM возвращает undefined, проблема часто связана с неправильным именем ключа, вложенностью объекта или моментом, в который значение считывается.

Output и отправленные hits

Output помогает увидеть hits, которые Tag Assistant связал с выбранным Google tag или контейнером. Это следующий этап после проверки Tags Fired: тег мог запуститься, но требуется понять, что именно он отправил и к какому идентификатору относится отправка.

Когда на сайте работают разные продукты Google, внимательно выбирайте нужный ID. Например, один контейнер может отправлять данные в несколько destinations. Интерфейс Tag Assistant фильтрует hits для выбранного тега или контейнера, поэтому смена идентификатора меняет отображаемую информацию.

Для практической проверки удобно сопоставить три уровня: событие появилось, тег сработал, hit содержит ожидаемые параметры. Если все три этапа совпадают с настройкой, вероятность ошибки значительно ниже, чем при проверке только сообщения о сработавшем теге.

Как проверить тег в Google Tag Assistant?

Проверка начинается с заранее определённого результата. Перед запуском Preview нужно знать, какой тег должен сработать, после какого события и какие параметры он должен получить. Тогда в Tag Assistant можно сравнивать конкретные ожидания с реальными данными, а не просто просматривать длинный список событий.

Например, для формы ожидается событие generate_lead, один запуск соответствующего GA4-тега и передача параметра с типом формы. После отправки проверяется наличие event, состояние тега и его значения. Если тег появляется два раза, настройка уже требует исправления, даже если оба hits успешно уходят.

Для повторяемых задач удобно придерживаться одного порядка:

Таблица подходит как базовый чек для формы, кнопки, звонка, регистрации или ecommerce-события. Для каждого проекта к ней добавляют параметры, которые имеют значение именно для его аналитики.

Проверка срабатывания тега

Выберите событие, на котором тег должен запуститься, и откройте список тегов. Если нужный элемент находится в Tags Fired, проверьте его настройки и параметры. Если он остался в Tags Not Fired, откройте условия Triggering и сравните их со значениями Variables на этом событии.

Дальше откройте Data Layer и убедитесь, что страница передала ожидаемые данные. Когда источник значения находится в уровне данных, этот шаг быстро отделяет ошибку сайта от ошибки настройки GTM. Если ключ отсутствует уже в Data Layer, изменение переменной контейнера проблему не исправит.

После этого проверьте отправку в Output или связанной системе аналитики. Такой порядок отделяет четыре разных ситуации: событие не создано, триггер не выполнен, тег не отправил hit или принимающая система не обработала данные ожидаемым образом.

Ведущий SEO-специалист — Геннадий

Я не публикую изменения в GTM сразу после настройки тега. Сначала прохожу нужный пользовательский сценарий в Preview Mode: проверяю событие, условия триггера, Tags Fired, значения Variables и данные в Data Layer. Если это конверсия для GA4, дополнительно смотрю её в DebugView. Такой порядок помогает найти ошибку до того, как некорректные данные попадут в рабочие отчёты.

Как проверить клики, формы и конверсии?

Для клика сначала нажмите нужный элемент на тестируемой странице, затем найдите соответствующее событие в Tag Assistant. Проверьте Click Text, Click Classes, Click URL или другие переменные, на которых построен триггер. После этого убедитесь, что целевой тег сработал только на нужном элементе.

Для формы важно проверить реальную успешную отправку, а не любой клик по кнопке Submit. Сайт может вернуть ошибку валидации, а слишком простой click trigger уже отправит конверсию. Более надёжный сценарий привязывает событие к подтверждённой отправке формы или событию приложения.

Для покупки последовательность включает ещё один уровень проверки. После тестового заказа найдите purchase, проверьте transaction ID, стоимость, валюту и товары. Затем убедитесь, что один заказ вызывает один hit. Повторная отправка при обновлении страницы способна заметно завысить доход и количество транзакций.

Как проверить событие дополнительно в GA4 DebugView?

GA4 DebugView используется после проверки события в GTM. Если Tag Assistant показывает корректный запуск тега и нужные параметры, откройте DebugView в соответствующем ресурсе Google Analytics 4 и найдите то же событие в потоке отладочных данных.

Так можно подтвердить, что данные дошли до GA4, а не остановились после выполнения тега. Проверяйте название события и важные параметры. Если в GTM всё выглядит правильно, но DebugView ничего не получает, имеет смысл проверить Measurement ID, consent, сетевые запросы и выбранный ресурс GA4.

Не нужно заменять DebugView проверкой только отчёта Realtime. Отладочный режим удобнее для тестовой настройки и позволяет разбирать последовательность событий. После успешной проверки контейнер можно опубликовать и уже затем контролировать рабочие данные обычными отчётами.

Почему Google Tag Assistant не подключается к сайту?

Проблемы соединения не всегда связаны с ошибкой самого GTM. Tag Assistant должен открыть страницу, обнаружить Google tag и сохранить связь с тестовой сессией. Этому могут мешать редиректы, блокировщики рекламы, ограничения браузера, iframe, настройки consent или особенности маршрутизации сайта.

Начинать диагностику лучше с самого простого: открыть тестируемую страницу без Preview и убедиться, что она доступна без авторизации, ошибки или бесконечного редиректа. Затем проверить исходный код или Network и подтвердить загрузку нужного контейнера. После этого имеет смысл переходить к настройкам браузера.

Google отдельно перечисляет отсутствие тега, позднюю загрузку скрипта, AMP, iframe, multiple redirects, ad blockers, разрешения расширения и consent management среди причин неудачного подключения.

Tag Assistant пишет, что Google Tag Manager не найден

Сначала проверьте Container ID. На тестовом и рабочем домене могут использоваться разные контейнеры, а разработчик мог оставить старый идентификатор в шаблоне. Найти GTM можно через исходный HTML или Network, отфильтровав запросы по gtm.js и идентификатору контейнера.

Если код есть, посмотрите момент его загрузки. Некоторые сайты запускают GTM только после согласия пользователя или после выполнения дополнительного JavaScript. Tag Assistant может попытаться соединиться раньше, чем тег станет доступен. В такой ситуации Google предлагает повторить подключение через Retry.

Отдельный случай – iframe. Когда Google tag загружается внутри iframe, для полноценной диагностики Google рекомендует Chrome-расширение Tag Assistant. Если без расширения основной документ определяется, а нужный тег внутри встроенного контента отсутствует, причина может находиться именно здесь.

Сайт открывается, но Debug не подключается

Сначала временно отключите ad blocker для тестируемого домена. Блокировщики способны останавливать загрузку Google tag или сетевые запросы, поэтому Tag Assistant не получает данные. Если используется Chrome-расширение, проверьте его разрешение читать и изменять данные на текущем сайте.

Дальше посмотрите редиректы. Цепочка из нескольких перенаправлений иногда мешает сохранить debug session между исходным URL и конечной страницей. Проблему также может создавать Content Security Policy, если правила CSP запрещают загрузку необходимых Google-ресурсов или соединения с ними.

Consent Management Platform проверяется отдельно. Если CMP до согласия полностью блокирует Google-теги, поведение должно соответствовать выбранной модели Consent Mode. При диагностике важно понимать, ожидается ли запуск конкретного тега до согласия или он должен появиться только после изменения consent state.

Что делать, если debug-параметр ломает страницу?

При соединении Tag Assistant может добавить к URL параметр _dbg. Большинство сайтов обрабатывает его нормально, но на проектах с жёсткой маршрутизацией, нестандартными правилами редиректов или собственной обработкой query string параметр иногда меняет поведение страницы.

В таком случае измените настройки подключаемого домена и отключите Include debug signal in the URL. Затем откройте страницу повторно и проверьте соединение. Google прямо указывает этот вариант среди способов исправления проблем с debug session.

После успешного подключения обязательно воспроизведите исходный сценарий заново. Старые события из предыдущей попытки не стоит использовать для финальной проверки, поскольку условия запуска могли отличаться. Чистая сессия делает результат понятнее и уменьшает риск перепутать два разных теста.

Почему тег находится в Tags Not Fired?

Первый вариант – выбранное событие просто не должно запускать этот тег. Например, тег формы ожидает custom event form_success, а специалист смотрит состояние на обычном Click. Нужно выбрать событие, для которого настроен соответствующий trigger.

Если событие правильное, откройте Variables и сравните реальные значения с условиями триггера. Причиной может быть другой Page Path, изменившийся CSS-класс, пустая Data Layer Variable, регистр символов или несовпадение названия custom event. Особенно часто такие ошибки появляются после изменений фронтенда.

Также проверьте исключающие условия и consent. Тег может соответствовать основному триггеру, но блокироваться исключением, настройками согласия или последовательностью других тегов. Исправлять проблему стоит только после определения конкретного невыполненного условия, а не заменять сложный триггер на All Pages.

Как работать с несколькими вкладками и контейнерами?

Сложные пользовательские сценарии редко ограничиваются одной страницей. Форма может открываться в новом окне, оплата – переходить на отдельный домен, а приложение – использовать несколько Google tag одновременно. В таких случаях особенно важно понимать, к какой странице, вкладке и Container ID относится выбранное событие.

Tag Assistant сохраняет историю текущей сессии и группирует события по страницам. Это помогает вернуться к предыдущему шагу и посмотреть, какие данные были переданы перед переходом. При этом каждый hit нужно анализировать в контексте выбранного контейнера, иначе можно принять данные соседней конфигурации за результат нужного тега.

Chrome-расширение добавляет дополнительные возможности для нескольких окон и новых вкладок. Google указывает эту поддержку как одну из причин установить расширение при сложной диагностике.

Отладка нескольких страниц и вкладок

При переходах внутри одного сценария не закрывайте debug session после каждой страницы. Выполните весь путь пользователя от начала до целевого действия, а затем разберите последовательность событий. Так легче увидеть, где именно пропал параметр, изменился consent state или появился лишний hit.

Для нового окна или pop-up убедитесь, что Tag Assistant продолжает получать события после его открытия. Если обычная web-сессия теряет часть данных, используйте актуальное Chrome-расширение. Оно рассчитано в том числе на диагностику новых окон и нескольких браузерных окон в одной сессии.

Когда тест завершён, повторите его после исправления настройки с чистого начала. Не сравнивайте новое событие с данными, которые остались от другой версии контейнера в старой сессии. Такой подход особенно важен при поиске дублей и ошибок последовательности.

Как переключаться между GTM-контейнерами?

Если на странице обнаружено несколько Google tag или контейнеров, Tag Assistant предлагает выбрать нужный идентификатор. После выбора Output и связанные данные отображаются для конкретного ID. Поэтому перед анализом всегда сверяйте его с контейнером, в котором выполнялись изменения.

Несколько контейнеров встречаются после миграций, при работе отдельных команд или на сайтах со старой аналитикой. Это не всегда ошибка, но одинаковые события могут отправляться из разных мест. При подозрении на дубли нужно проверить каждый обнаруженный контейнер и установить источник повторной отправки.

Отдельно проверьте, нет ли одновременно GTM-настройки и прямого gtag.js, отправляющих одну и ту же конверсию. В таком случае Tag Assistant помогает увидеть несколько связанных отправок и понять, какая реализация должна остаться после очистки конфигурации.

Как передать Debug-сессию другому специалисту?

Не каждую ошибку удобно описывать скриншотами. Если разработчик или аналитик должен увидеть точную последовательность событий, Tag Assistant позволяет передать доступ к диагностике или экспортировать историю сессии. Это особенно удобно, когда проблема воспроизводится только при конкретном наборе действий.

При передаче данных нужно учитывать конфиденциальность. В debug history могут попасть значения, которые сайт отправляет через теги и Data Layer. Google предупреждает, что при наличии PII такие данные попадут и в экспортируемый файл сессии.

Перед экспортом лучше проводить тест с техническими или тестовыми данными. Реальные номера телефонов, email, имена и другие персональные сведения не должны передаваться в аналитику и не должны использоваться для демонстрационной debug session.

Как поделиться ссылкой на отладку?

Запустите debug session и выполните действия, на которых воспроизводится проблема. Затем откройте меню дополнительных действий в Tag Assistant, выберите Share и проверьте настройки доступа. После этого можно скопировать ссылку и передать её специалисту, который будет анализировать конфигурацию.

Ссылка удобна, когда второму человеку нужно самостоятельно продолжить проверку сайта. Перед передачей уточните тестовый URL, ожидаемое событие и шаг, на котором возникает ошибка. Без этого даже подробная диагностическая информация может потребовать повторного воспроизведения всего сценария.

После завершения работы доступ лучше использовать только для конкретной задачи. Если проблема связана с закрытым staging-сайтом или пользовательским кабинетом, заранее проверьте, сможет ли второй специалист открыть нужную страницу со своей стороны.

Как экспортировать и импортировать Debug-сессию?

Для экспорта откройте меню Tag Assistant и выберите Export session. Полученный файл содержит историю проведённой проверки. Его можно передать специалисту, который импортирует сессию через Import session и увидит зафиксированные события в режиме просмотра.

Импортированная сессия доступна только для чтения. В ней нельзя продолжить переходы по сайту и получить новые hits. Если требуется воспроизводить действия самостоятельно, лучше передать debug access, а экспорт использовать для разбора уже произошедшего сценария.

Файл не стоит редактировать вручную. Google предупреждает, что изменение его имени или содержимого может повредить данные. Перед отправкой также убедитесь, что во время теста через теги не передавалась информация, которую нельзя передавать третьим лицам.

Чек-лист проверки GTM перед публикацией

Перед публикацией новой версии контейнера полезно пройти одинаковую последовательность проверок. Чек-лист уменьшает вероятность пропустить дубль, ошибочную переменную или тег, который срабатывает только в одном из нескольких сценариев. Для критичных конверсий проверять лучше и desktop, и мобильный вариант сайта.

Сначала пройдите основной сценарий, затем пограничные варианты. Для формы это может быть успешная отправка и ошибка валидации, для покупки – один завершённый заказ без повторного purchase после обновления страницы. Если тег зависит от consent, отдельно проверьте состояния до и после выбора пользователя.

Перед публикацией должны выполняться следующие условия:

1. Tag Assistant подключается к нужному домену, а в сессии выбран правильный GTM container ID.
2. Базовые события загрузки страницы появляются в ожидаемой последовательности без очевидных ошибок.
3. Целевое действие создаёт нужный event, а его название соответствует настройке аналитики.
4. Нужный тег находится в Tags Fired только на тех событиях, где он действительно должен запускаться.
5. Tags Not Fired проверены для целевого события, если среди них находится ожидаемый тег.
6. Variables содержат значения, которые соответствуют условиям настроенных триггеров.
7. Data Layer передаёт необходимые параметры и не содержит ошибочных или пустых обязательных значений.
8. Один пользовательский сценарий не создаёт лишних повторных срабатываний одного и того же тега.
9. Output показывает ожидаемый hit и правильный Google tag, Measurement ID или другой идентификатор назначения.
10. Конверсионные события GA4 дополнительно проверены через DebugView, если они используются в аналитике.
11. Consent Mode и связанная логика проверены для тех состояний согласия, которые возможны на сайте.
12. После успешного повторного теста изменения можно отправлять через Submit и публиковать новую версию контейнера.

После исправлений весь сценарий стоит пройти ещё раз с начала. Проверка отдельного проблемного события не всегда показывает побочный эффект на других тегах. Особенно это касается изменений общих переменных, consent-настроек и триггеров, используемых сразу несколькими событиями.

Preview Mode и Google Tag Assistant дают достаточно данных, чтобы проверить большинство настроек GTM до публикации. Рабочая последовательность проста: воспроизвести пользовательское действие, найти событие, проверить Triggering, Tags Fired, Variables, Data Layer и отправленный hit, а для GA4 дополнительно посмотреть DebugView.

Если Tag Assistant показывает ошибку, лучше искать конкретный разрыв в этой цепочке, а не менять настройки наугад. Такой подход помогает отделить проблему сайта от ошибки GTM и быстрее найти дубли, неправильные параметры или несработавшие триггеры.

Если на сайте требуется настроить или перепроверить Google Tag Manager, события GA4 и конверсии, передайте специалистам Seo-Gen список нужных действий пользователей и доступ к тестовой среде. Мы проверим сценарии через Preview и Debug, исправим найденные ошибки и подготовим контейнер к публикации.