Диагностика кода отслеживания рекламы для интернет-магазинов (2026)

Как использовать это руководство

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

После изучения этого руководства вы сможете

• Различать наличие кода, срабатывание тега, отправку запроса, получение данных платформой и право конверсии участвовать в назначении ставок.
• Проверять критические поля, такие как идентификатор заказа, доход, валюта, идентификатор продукта и идентификатор события.
• Диагностировать дублирующиеся и отсутствующие покупки, конверсии с нулевой ценностью, потерю междоменной атрибуции и ошибки конфигурации согласие.
• Выбирать подходящий метод диагностики для Shopify, WordPress, WooCommerce или собственного стека электронной коммерции.
• Создайте четкий диагностический отчет для маркетинговых, аналитических или управленческих команд.

Почему установленное отслеживание всё равно может давать недостоверные данные

Когда независимый интернет-магазин начинает размещать рекламу в Google Ads, Meta Ads, Microsoft Ads или TikTok Ads, каждая платформа запрашивает тег или пиксель отслеживания. Наличие кода в исходном коде страницы не доказывает, что отслеживание конверсий работает правильно.

• Рекламная платформа показывает тег как непроверенный, неактивный или без недавних действий.
• GA4 записывает заказы, но Google Ads не показывает никаких конверсий.
• Бэкэнд магазина содержит один заказ, а рекламная платформа сообщает о двух покупках.
• Количество конверсий выглядит разумным, но данные о доходах, валюте или продукте неверны.
• Пиксель обнаруживается на главной странице, но исчезает во время оформления заказа или на странице подтверждения заказа.
• События браузера и сервера отправляются, но дедуплицируются неправильно.
• Рекламное отслеживание не соответствует выбору согласия посетителя: рекламное хранилище по-прежнему записывается или читается, либо рекламные идентификаторы и данные пользователя продолжают отправляться после того, как маркетинговое согласие стало denied. В расширенном режиме согласия пинги согласия без cookie всё ещё могут отправляться, пока ad_storage или analytics_storage имеет состояние denied; само по себе это не означает ошибку реализации.
• Теги не возобновляются после того, как посетитель предоставляет согласие.

Полный аудит не может ограничиваться вопросом «Код установлен?». Убедитесь, что каждое реальное бизнес-действие поступает на нужную платформу с правильным названием события, параметрами, ценностью, валютой и ID заказа, а отправка из браузера и с сервера после дедупликации образует одну логическую конверсию.

1. Что именно проверяет диагностика рекламного отслеживания

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

Сообщение «Tag Fired» в GTM подтверждает только выполнение условия триггера. Оно не доказывает точность конверсии. Продолжайте проверку уровня данных, сетевого запроса, тестовых инструментов платформы и соответствующего заказа в бэкенде.

2.Сначала создайте план отслеживания событий электронной коммерции

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

В версии руководства за август 2026 года TikTok использует Purchase как стандартное событие электронной коммерции purchase, а Lead — для отправки лид-форм. CompletePayment и SubmitForm — совместимые устаревшие названия, сопоставленные с Purchase и Lead; не переименовывайте работающую устаревшую реализацию без плана миграции. Используйте Contact только для реального обращения. GA4 использует purchase и рекомендует такие параметры, как transaction_id, value, currency и массив items.

Минимальные данные, необходимые для события purchase

3. Подготовьте диагностический тест

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

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

Проверьте как минимум три сценария согласие

• Новый посетитель, который ещё не выбрал настройки cookie.
• Посетитель, который принимает все соответствующие файлы cookie.
• Посетитель, который отказывается от маркетинговых файлов cookie.

Для режима согласия Google установите состояние согласия по умолчанию до запуска соответствующих тегов, а после выбора посетителя сразу обновите его на той же странице. Проверьте ad_storage, analytics_storage, ad_user_data и ad_personalization по отдельности. Расширенный режим согласия может отправлять пинги без cookie, пока хранилище находится в состоянии denied; убедитесь, что рекламное хранилище, рекламные идентификаторы и данные пользователя не отправляются вопреки выбору посетителя.

Диагностический инструментарий

1. Google Tag Assistant и GTM Preview

Google Tag Manager Preview показывает события страницы, сработавшие и несработавшие теги, условия триггеров, переменные и состояние согласия. Он отвечает на два ключевых вопроса: что произошло на сайте и почему GTM запустил или не запустил тег?

2. GA4 DebugView

GA4 DebugView подтверждает, получил ли GA4 событие, и показывает его параметры. Это помогает отделить проблему реализации GTM от проблемы доставки или сбора данных GA4.

3. Панель Chrome DevTools Network

Панель Network показывает запросы, которые браузер действительно отправляет. Вы можете фильтровать по домену платформы, типу запроса, имени файла, идентификатору тега или идентификатору измерения. Это ключевой инструмент для ответа: «Отправлял ли браузер данные?»

4. Инструменты тестирования для конкретных платформ

Используйте Test Events и диагностика в Meta Events Manager; Pixel Helper, Test Events и диагностика для TikTok; UET Tag Helper для Microsoft Advertising; и Shopify Pixel Helper для пользовательских пикселей Shopify.

4. Полный процесс диагностики рекламного отслеживания

Шаг 1. Проведите инвентаризацию всех реализаций отслеживания

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

• GTM устанавливается один раз в теме и снова через плагин.
• Официальное приложение Meta для Shopify устанавливает пиксель, но также присутствует отдельный пользовательский Meta pixel.
• Плагин WordPress отправляет Purchase, а GTM снова отправляет тот же Purchase.
• Нативное действие покупки Google Ads и импортное действие покупки GA4 установлены в качестве основных целей.
• Meta Pixel и Conversions API отправляют одну и ту же покупку без рабочей дедупликации.
• Приложение TikTok, GTM и код темы по отдельности устанавливают один и тот же пиксель.

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

Ищите каждый ID в исходном коде страницы, списке тегов GTM, плагинах WordPress, областях пользовательского кода темы, Shopify Customer Events, приложениях Shopify, Cloudflare Zaraz, серверном GTM и любых пользовательских интеграциях бэкенда.

Шаг 2. Убедитесь, что базовый тег загружается правильно

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

• Подтвердите, что Preview подключен к правильному домену.
• Подтвердите, что ожидаемый контейнер GTM появляется при загрузке страницы.
• Убедитесь, что ID контейнера соответствует активному аккаунту и среде.
• Убедитесь, что базовый Google tag загружается на всех необходимых страницах.
• Проверьте, остаётся ли страница успешной оплаты в том же сеансе отладки.
• Проверьте, прерывается ли сеанс после перенаправления или перехода между доменами.
• Проверьте Consent Initialization и любое состояние согласия, которое блокирует тег.

Одновременно откройте Chrome DevTools и найдите в панели Network ID контейнера GTM, ID измерения GA4, ID конверсии Google Ads, ID Meta pixel, ID пикселя TikTok или ID тега Microsoft UET. Поиск фактического ID надёжнее одного фиксированного endpoint, поскольку пути запросов могут меняться.

Если запросы отсутствуют, сначала проверьте следующее

• Код отсутствует или настроенный идентификатор неверен.
• Контейнер GTM не опубликован или загружена неверная среда.
• Настройки согласие не позволяют запустить тег.
• Политика безопасности контента блокирует внешний скрипт или конечную точку.
• Блокатор рекламы или настройка конфиденциальности браузера блокирует запрос.
• Ошибка JavaScript возникает перед выполнением кода отслеживания.
• Кэш или CDN по-прежнему обслуживает старую версию кода сайта.

Шаг 3. Проверьте уровень данных или событие клиента

Уровень данных связывает действия в интернет-магазине с рекламными тегами. Google Tag Manager и gtag.js считывают события и переменные из этого структурированного уровня. Используйте предсказуемые структурированные данные, а не заставляйте теги извлекать значения из несвязанных элементов страницы.

Упрощённое событие purchase в стиле GA4 может выглядеть так:

<script>
window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
  event: "purchase",
  ecommerce: {
    transaction_id: "ORD-10086",
    value: 129.90,
    currency: "USD",
    tax: 8.20,
    shipping: 0,
    items: [
      {
        item_id: "SKU-001",
        item_name: "Portable Coffee Grinder",
        price: 64.95,
        quantity: 2
      }
    ]
  }
});
</script>

Для электронной коммерции GA4 ценность на уровне события обычно должна равняться сумме price × quantity для массива items и не включать доставку или налог, если документированное определение отчётности и целевая платформа явно не требуют иного.

Используйте следующую команду в Chrome Console для первоначальной проверки:

window.dataLayer

Для отображения только событий purchase:

window.dataLayer?.filter(item => item.event === "purchase")

Подтвердите эти шесть пунктов

1. Событие происходит в нужный момент: Purchase должно создаваться только после фактического завершения заказа, а не после нажатия Pay now или Submit order.

2 Идентификатор заказа уникален: один и тот же заказ должен сохранять один и тот же идентификатор после обновления, в то время как разные заказы никогда не должны иметь один и тот же идентификатор.

1. Ценность должна быть числом: используйте 129.90, а не “$129.90”, “USD 129.90” или строку с разделителем тысяч.

4 Валюта соответствует заказу: В мультивалютных магазинах сравнивайте отображаемую валюту, расчетную валюту и валюту, отправленную на платформу.

1. Массив items заполнен: ID товаров, цены, количества и скидки должны совпадать с заказом в бэкенде.
2. Старые значения не сохраняются: одностраничные приложения, выдвижные корзины и оформления заказа AJAX могут случайно повторно использовать данные предыдущего события.

Шаг 4: Проверьте триггеры и переменные GTM

Завершите настоящее тестовое путешествие в GTM Preview, выберите событие purchase и проверьте Tags Fired, Tags Not Fired, Variables, Data Layer и согласие.

Триггер слишком широкий

Правило вроде “Page URL contains thank-you” может сработать снова при обновлении, добавлении в закладки или повторном посещении страницы подтверждения. Для покупок предпочтительнее настоящее событие завершения заказа и уникальный ID заказа.

Триггер слишком ограничителен

Фактический URL может быть /en/checkout/success, а триггер разрешает только /checkout/success. Языковые папки, строки запроса и альтернативные пути оформления заказа могут нарушить слишком строгое правило.

Названия пользовательских событий не совпадают

Уровень данных отправляет event: “checkout_completed”, а GTM ожидает purchase. Названия событий должны совпадать точно, включая регистр и подчёркивания.

Тег срабатывает до поступления данных

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

AJAX или одностраничное приложение не создаёт традиционную загрузку страницы

Выдвижные корзины, модальные оформления заказа и приложения React или Vue могут не создавать обычный просмотр страницы. Запускайте отслеживание по бизнес-событиям, а не только по загрузке страниц или изменению URL.

Шаг 5: Используйте Network для подтверждения отправки запроса

Откройте Chrome DevTools -> Network, включите Preserve log и повторите полный тест. Отфильтруйте по ID или домену платформы. Откройте соответствующий запрос и проверьте Headers и Payload.

• Проверьте платформу назначения и идентификатор тега или пикселя.
• Проверьте имя события, стоимость, валюту и идентификатор заказа.
• Подтвердите наличие идентификаторов продукта, количества и массива items.
• Подтвердите, что события браузера и сервера имеют общие идентификаторы дедупликации для конкретной платформы: Meta и TikTok требуют соответствующего имени или типа события плюс event_id, в то время как покупки GA4 и Google Ads используют transaction_id.
• Проверьте, был ли запрос отменен, заблокирован или возвращен с ошибкой.
• Проверьте, произошел ли запрос до или после перенаправления страницы.

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

GTM сообщает, что тег сработал, но Network не показывает запрос

• Состояние согласие и встроенные проверки согласие.
• Блокировка рекламы или настройки конфиденциальности браузера.
• Ограничения политики безопасности контента.
• Неисправный шаблон тега или ошибка выполнения JavaScript.
• Запрос отменён из-за немедленной навигации.
• Ограничения Pixel Sandbox в Shopify.

Шаг 6. Подтвердите получение события каждой рекламной платформой

GA4

Откройте DebugView, выберите тестовое устройство и подтвердите, что последовательность событий разумна:

page_view
view_item
add_to_cart
begin_checkout
purchase

Откройте purchase и проверьте transaction_id, ценность, валюту и items.

Google Ads

Откройте Goals -> Conversions -> Summary и проверьте статус отслеживания нужного действия. Для Unverified, Tag inactive или Needs attention запустите Tag Assistant из действия-конверсии. Обновление статуса аккаунта после исправления может занять время, поэтому используйте Tag Assistant и фактический запрос как немедленный уровень проверки.

Meta Ads

В Events Manager выберите правильный источник данных и проверьте Overview, Test Events, диагностика, Event Deduplication и Event Match Quality. Test Events подтверждает доставку из браузера и с сервера; диагностика выявляет дублирующиеся события, неверные параметры и проблемы качества данных.

TikTok Ads

Используйте TikTok Pixel Helper для проверки тегов браузера, событий и параметров; Менеджер событий -> Test Events для получения в режиме реального времени; и Менеджер событий -> диагностика для постоянных ошибок реализации.

Microsoft Advertising

Используйте UET Tag Helper для проверки ID тега UET, события загрузки страницы, пользовательских событий, переменного дохода, валюты и условий цели конверсии. Статус UET в Microsoft Advertising может обновляться с задержкой. Если также используется Microsoft Advertising Conversions API, проверьте его event_id и убедитесь, что доставка из браузера и с сервера не создаёт дублирующую отчётность. Для переменного дохода сохраняйте revenue_value и currency точно по требованиям системы назначения.

5. Диагностика дублирующихся Conversions и Event Deduplication

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

Google Ads дедупликация

Google Ads рекомендует передавать уникальный ID транзакции для каждой покупки. Если страницу подтверждения обновить и тот же заказ снова отправится в то же действие-конверсию, Google Ads сможет определить дубликат по совпадающему ID транзакции. ID транзакции не дедуплицирует автоматически разные действия-конверсии Purchase.

• Разные заказы не должны иметь одинаковый ID транзакции.
• Идентификатор транзакции не должен быть пустым.
• Не используйте адрес электронной почты клиента или номер телефона в качестве идентификатора заказа.
• Теги браузера и бэкэнд-загрузки должны использовать один и тот же идентификатор заказа для одной и той же транзакции.

Дедупликация Meta Pixel и Conversions API

Когда один Purchase отправляется через Meta Pixel и Conversions API, браузерное и серверное события должны содержать одинаковые event_name и event_id. Разные заказы должны использовать разные значения event_id. Иначе один заказ может быть учтён как два события.

• Используют ли события браузера и сервера тот же event_name?
• Обе версии одного заказа используют один event_id?
• Получает ли каждый заказ отдельный идентификатор события?
• Создаёт ли повторная попытка сервера новый ID события и случайно второе событие?
• Отправляют ли приложение Shopify и пользовательская реализация CAPI одну и ту же покупку?

Дедупликация TikTok Pixel и Events API

Когда TikTok Pixel и Events API отправляют одно событие, обе стороны должны использовать одинаковое название или тип события и один event_id, чтобы TikTok распознал пару и сохранил одно логическое событие.

Обновления страницы подтверждения заказа

Запуск Purchase только по просмотру страницы подтверждения рискован. Обновление, добавление в закладки или повторное открытие страницы может снова запустить событие. Используйте уникальный ID заказа и, по возможности, настоящее событие завершения заказа, а не обычную загрузку страницы.

6. Проверьте Goals конверсий, междоменное оформление заказа и атрибуцию

Primary против вторичных конверсий

В Google Ads основные действия-конверсии обычно отображаются в столбце Conversions и могут использоваться для назначения ставок, если кампания использует соответствующую цель. Действия Secondary в основном предназначены для наблюдения и обычно появляются в All conversions. Однако вторичное действие может применяться для ставок, если оно включено в пользовательскую цель, которую активно использует кампания.

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

Сравнение Every и One

Действия Purchase обычно должны учитывать каждую транзакцию. Формы Lead часто используют One, поскольку повторные отправки после одного клика по объявлению могут не означать несколько ценных лидов. Для продаж используйте уникальный ID транзакции, чтобы исключать дублирующиеся заказы.

Дублирующиеся основные цели покупки

В аккаунте могут одновременно находиться собственное Google Ads Purchase, импортированное GA4 Purchase и Purchase, созданное приложением Shopify. Если все три действия основные и используются кампанией, столбец Conversions может содержать несколько сигналов покупки для одного заказа.

Усовершенствованный Conversions

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

Междоменное оформление заказа и платёжные перенаправления

Некоторые магазины переводят посетителей с основного домена на отдельный домен оформления заказа, стороннего платёжного провайдера, систему бронирования, сервис форм, поддомен или региональный сайт. Неверная междоменная настройка может вызвать:

• Разделение одного сеанса клиента на несколько сеансов.
• Исчезновение исходного рекламного источника.
• Платёжный провайдер становится источником перехода в отчёте.
• Потерю ID клика до оформления заказа.
• События на витрине есть, но после успешной оплаты отсутствуют.

Используйте междоменное измерение GA4 только между доменами, которые вы контролируете и где можно развернуть один тег GA4. Для сторонних платёжных доменов, где тег установить нельзя, проверьте List unwanted referrals, чтобы провайдер не заменил исходный источник; это не заменяет междоменное измерение. Тестируйте весь путь перенаправления с целевой страницы, а не открывайте страницу успеха напрямую.

7. диагностика отслеживания для Shopify

Пиксели Shopify Customer Events работают в изолированных средах. Пиксели приложений используют Strict sandbox, а пользовательские пиксели — Lax sandbox; их возможности различаются. Оба типа должны опираться на Shopify Customer Events и Web Pixels API, а не на традиционное извлечение данных через DOM.

1.Не полагайтесь только на Google Tag Assistant

Google Tag Assistant несовместим с пользовательскими пикселями GTM в Shopify. Используйте Shopify Pixel Helper, чтобы убедиться, что события клиента поступают в sandbox, затем проверьте полученный запрос Network и Test Events или диагностику целевой платформы.

Shopify Pixel Helper
-> dataLayer пользовательского пикселя
-> Тег GTM
-> Запрос Network
-> Test Events рекламной платформы

2. Не извлекайте данные DOM внутри sandbox

Web Pixels Shopify работают в sandbox. Реализации, читающие или изменяющие DOM витрины, могут работать нестабильно. Используйте данные Shopify Customer Events и Web Pixels API, а не извлекайте цены, кнопки или сведения о заказе с помощью CSS-селекторов.

• Триггер клика, который слушает непосредственно кнопку темы.
• Переменная элемента DOM, извлекающая отображаемую цену товара.
• Прямое использование document.querySelector.
• Использование URL sandbox-среды, как если бы это был URL витрины магазина.
• Предположение, что расширенное измерение GA4 автоматически обнаружит каждое взаимодействие в sandbox.

3. Проверьте, ждет ли пиксель согласие

Откройте Настройки Shopify -> События клиентов -> Пользовательские пиксели и начните тест. Если Pixel Helper сообщает “Pixel is awaiting согласие”, проверьте:

• Разрешения на конфиденциальность клиента, назначенные пользовательскому пикселю.
• Конфигурация баннера cookie для активного рынка.
• Предоставил ли посетитель согласие Analytics или Marketing в granted.
• Интегрирована ли платформа управления согласие с Customer Privacy API Shopify.

4 правильно использовать checkout_completed

Shopify checkout_completed обычно срабатывает один раз на оформление заказа и часто наблюдается на странице Thank You. При post-purchase upsell оно может сработать на первой странице допродажи, а не повторно на Thank You. Оно также может не сработать, если ожидаемая страница не загрузилась.

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

8. Распространённые проблемы диагностики WordPress и WooCommerce

Самая распространённая проблема WordPress не в невозможности установить отслеживание, а в установке одного отслеживания в слишком многих местах. Проверьте по порядку:

• Плагины установки GTM.
• GA4 или плагины для конверсии рекламы.
• Отдельные плагины Meta, TikTok или Microsoft Advertising.
• Области пользовательского кода в header и footer темы.
• Код конструктора страниц.
• Пользовательские настройки страницы Thank You WooCommerce.
• CDN, кэширование, комбинирование сценариев и настройки задержки JavaScript.

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

Дополнительные проверки плагинов производительности и кэширования

• Задерживают ли они загрузку GTM или пикселей?
• Изменяют ли объединённые скрипты порядок выполнения?
• Страница подтверждения заказа, содержащая данные заказа, кэшируется?
• Обновление согласие происходит после того, как рекламные теги уже запущены?
• Блокируются ли сторонние запросы отслеживания или неверно ли они проходят через прокси?
• Возникает ли проблема только после выхода администратора из системы?

9. Матрица устранения неполадок

10. Критерии приёмки надёжной реализации

Успешная тестовая покупка должна соответствовать всем следующим условиям:

• Purchase срабатывает только после фактического завершения заказа.
• Тестовый заказ One после дедупликации образует одну логическую конверсию.
• ID заказа совпадает с бэкендом магазина.
• Ценность конверсии соответствует согласованному определению, а валюта указана правильно.
• Идентификаторы продукции, цены и количества являются точными.
• GTM Preview показывает полное событие и заполненные переменные.
• Соответствующий запрос существует в Network.
• Платформа назначения распознает событие в своем тестовом инструменте.
• Браузерные и серверные события дедуплицированы.
• Принятые и отвергнутые состояния согласие создают предполагаемое поведение.
• Настройки Google Ads Primary, Secondary и Count корректны.
• Междоменное оформление заказа сохраняет исходный источник.
• Обновление страницы подтверждения не создаёт ещё одну независимую конверсию.

Итоговый стандарт приёмки
Реальный бизнес-заказ One -> одна логическая рекламная конверсия после дедупликации -> правильные ID заказа, ценность, валюта и данные товаров -> проверка на платформе -> сверка с бэкендом магазина.

11. Шаблон отчёта о диагностике рекламного отслеживания

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

1. Сайт и среда

2. Инвентаризация установок отслеживания

3. Тестовый заказ

4. Результаты диагностики

5. Проблема и исправление

6. Регрессионное тестирование

Полная цепочка подтверждений

Бизнес-действие
-> Событие клиента / Data Layer
-> Триггер GTM
-> Рекламный тег
-> Запрос Network
-> Тестовое событие платформы
-> Цель конверсии
-> Сверка с бэкендом

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