DebugView GA4 помогает проверить, какие события и параметры отправляет конкретное тестовое устройство. Он полезен при приёмке новой карточки или оформления заказа, но не заменяет отчёт об источниках продаж. Инструкция относится к собственному сайту с управляемым тегом. Официальная справка проверена 27 октября 2026 года; дата не означает запуск инструмента.

Начните с одного известного сценария

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

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

Проверяйте содержание, а не только название события

В DebugView доступны последовательность последних секунд и более широкий обзор по минутам. Откройте нужное событие и просмотрите параметры. Совпадение названия purchase не доказывает правильность номера, валюты или состава товаров. Для заказа отдельные критерии описаны в материале о transaction_id. Сначала установите, какие значения действительно пришли в текущем тесте.

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

Разберите отсутствие события по слоям

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

Отдельно проверьте фильтры разработчиков и внутреннего трафика. Их назначение отличается от просмотра параметров отдельного события. Для рабочего офиса используйте самостоятельную проверку фильтра Testing. Иначе команда может искать ошибку в кнопке, когда причина находится в настройках обработки тестового потока, либо наоборот — объявить фильтр виноватым без проверки отправки.

Завершите диагностику и повторите обычный путь

Для отключения debug_mode параметр нужно удалить; установка false не означает выключение отладки. После завершения теста повторно откройте магазин в обычном сценарии и убедитесь, что временная настройка не осталась в рабочем шаблоне. Запишите способ включения и отключения, чтобы следующий специалист не искал скрытое состояние в нескольких контейнерах тегов.

Не оценивайте рекламную атрибуцию по DebugView: для неё используйте соответствующие отчёты привлечения. Финальный результат проверки — перечень реально пройденных действий с параметрами и найденными расхождениями. Если ошибка не воспроизводится, сохраните условия успешного теста и границы проверки, вместо утверждения, что весь поток покупок гарантированно корректен при любых браузерах и подключениях.