Продавцы, которые ведут платный трафик на Shopify, постоянно задают один и тот же вопрос: что на самом деле должен проверять аудит трекинга? Большинство ответов перечисляют инструменты (поставьте этот пиксель, взгляните на ту панель) и не говорят, что именно доказывает такая проверка и что остаётся без ответа, когда вы закончили.
Полезный чек-лист строится вокруг проверок, а не инструментов. В нём четыре части: вопрос, который стоит задать; источник, где вы ищете ответ; способ проверить этот источник; и то, чего обычно не хватает, то есть что вы всё ещё не знаете после проверки. Ради этой четвёртой колонки такой чек-лист и нужен: пройденная строка сужает проблему, но не закрывает её.
Колонки читаются так. Первые две говорят, что вы проверяете и где. Третья описывает конкретное действие: какой отчёт выгрузить, какой инструмент открыть, какое поле проверить. Четвёртая содержит реальный вывод. С чек-листом из трёх колонок можно ставить галочки и не замечать оставшиеся вопросы. Всё ниже делается только на чтение, в том же порядке, что и в моей методологии: просмотр существующих записей и сохранённых подтверждений тестов. Если строке нужны новые данные, пометьте её как непроверенную. Новый тест чекаута или взаимодействия с согласием выполняется отдельным шагом за пределами этого чек-листа и только с явного разрешения.
Какой объём работ и какие доступы нужны аудиту трекинга Shopify на самом деле?
Прежде чем сравнивать одну платформу с другой, нужно согласовать, что разрешено проверять и в течение какого срока. Если пропустить этот шаг, в заключение попадёт система, которая не входила в согласованный объём работ.
Сравнительная таблица: прокрутите вбок, чтобы увидеть все столбцы
| Вопрос | Какой источник проверяется | Как это проверяется | Что остаётся неизвестным после этой проверки |
|---|---|---|---|
| Объём работ действительно ограничен одним магазином, одной проблемой и согласованным набором систем? | Письменная заметка об объёме работ, согласованная до выдачи доступа | Системы, названные в заметке, сравниваются с теми, которые реально проверяются | Не находится ли причина в системе за пределами согласованного объёма: эта проверка подтверждает только то, что попало в поле зрения |
| Доступ только на чтение и хватает ли его для проверки? | Роль viewer в GA4, Google Ads только на чтение, Meta Events Manager, учётная запись сотрудника Shopify | Войти с выданной ролью и прочитать уровень доступа, который показывает сама платформа | Не окажется ли доступ недостаточным, когда сверка уже идёт |
| Какое окно заказов реально доступно для проверки? | Выгрузка заказов Shopify (Admin или Orders API) за согласованный период | Количество заказов и диапазон дат в выгрузке сверяются напрямую с админкой Shopify | Сохранялась ли та же картина до окна выгрузки: базовый период в 30 дней не обещает полной истории |
| Какие пиксели и теги установлены на самом деле? | Shopify admin → Settings → Customer events, плюс любой используемый контейнер GTM | Каждая запись в Customer events открывается и сверяется с тем, что описал продавец | Почему каждая запись там стоит и кто ею владеет: проверка подтверждает, что есть, но не кто это добавил и нужно ли это ещё |
Приходит ли событие purchase из источника, который ещё работает?
Shopify не раз менял, где может работать тег покупки, поэтому аудит, который проверяет старое место подключения, не находит проблем: искать там уже нечего. Пиксель в песочнице, снятое с использования поле Additional Scripts и непроверенные пути экспресс-чекаута описаны на опорной странице про трекинг Shopify; строки ниже показывают, что из этого относится к вам.
Сравнительная таблица: прокрутите вбок, чтобы увидеть все столбцы
| Вопрос | Какой источник проверяется | Как это проверяется | Что остаётся неизвестным после этой проверки |
|---|---|---|---|
| Доходит ли событие purchase до GA4 из реального заказа? | Существующие подтверждения в GA4 DebugView от ранее разрешённого тестового заказа | Просмотреть сохранённые параметры события purchase и сопоставить их с этим тестовым заказом; если подтверждение не сохранилось, пометить проверку как непроверенную | Срабатывает ли то же событие на каждом пути оплаты, включая Shop Pay и другие экспресс-чекауты; подтверждение покрывает только проверенный заказ |
| Работает ли тег покупки там, где Shopify ему реально позволяет работать? | Shopify admin → Settings → Customer events (пиксели приложений и custom pixels) | Каждый активный пиксель открывается, а события, на которые он подписан, сверяются с тем, что отдаёт Web Pixels API Shopify | Правильно ли настроен пиксель из списка: наличие не подтверждает корректность |
| Не остался ли тег покупки в выведенном из использования поле? | Checkout settings → Additional Scripts | Поле открывается напрямую; Shopify сделал его доступным только для просмотра в магазинах без Plus, а скрипты из него не переносятся на обновлённые страницы «Спасибо» и статуса заказа, так что всё, что в нём осталось, не работает в магазине, который уже обновился | Как долго тег молчал до проверки: ничто не оповещает продавца, когда скрипт в этом поле перестаёт срабатывать |
| Есть ли серверная копия того же заказа? | Серверный контейнер или журнал доставки Conversions API, с сопоставлением по заказу | Ссылка на заказ в серверном событии сравнивается с браузерным событием для того же заказа | Покрывает ли серверный путь заказы, которые пропускает браузерный; этого не выяснить без проверки более широкой выборки |
Считается ли одна покупка один раз на каждой платформе?
Если платформа сообщает больше заказов, чем отгрузил Shopify, это сначала вопрос дедупликации и только потом вопрос объёма. Каждая платформа дедуплицирует по своему идентификатору, поэтому проверять нужно по каждой платформе, а не делать вывод по итогу, который случайно выглядит правдоподобно.
Сравнительная таблица: прокрутите вбок, чтобы увидеть все столбцы
| Вопрос | Какой источник проверяется | Как это проверяется | Что остаётся неизвестным после этой проверки |
|---|---|---|---|
| Считает ли GA4 одну покупку на заказ? | Параметр transaction_id в событии purchase | Значение сравнивается с реальным ID заказа, в DebugView и в выгрузке на следующий день | Не даёт ли какой-то конкретный путь оплаты пустое или повторяющееся значение, на которое не попал один тестовый заказ |
| Учитываются ли браузерное и серверное события Meta одной покупки как одна конверсия? | Инструмент Test Events и вкладка Diagnostics в Meta Events Manager | Подтверждается, что одинаковые event_id и название события есть и в браузерной, и в серверной копии одной покупки, полученных в пределах заявленного окна дедупликации Meta | Совпадают ли event_id так же на каждом заказе, а не только на проверенной выборке |
| Активен ли только один путь покупки на заказ? | Каналы продаж Shopify плюс конфигурация custom pixel или GTM | Осмотром подтверждается, что нативный канал продаж Shopify и любой custom pixel не отправляют одну и ту же покупку одновременно | Если активны оба: устраняет ли дедупликация GA4 по transaction_id все повторы или часть остаётся |
| Совпадает ли сверенное число заказов с реестром заказов Shopify? | Выгрузка заказов Shopify, соединённая с выгрузкой purchase из GA4 по transaction_id; Meta и Google Ads не дают построчного фида по заказам, поэтому их сравнивают суммарно | Заказы сопоставляются строка за строкой по общему идентификатору, а не сравниваются итогами | Почему конкретный заказ пропущен или повторён: соединение показывает, какие строки не совпали, но не механизм |
Что объясняют согласие и отчётность, а что нет?
Не всякое расхождение между платформой и заказами Shopify говорит о дефекте. Выбор согласия, смоделированный трафик и платформы, которые отчитываются только суммарно, дают разницу, которая изнутри панели выглядит как баг. Это про техническую реализацию, а не юридическую консультацию.
Сравнительная таблица: прокрутите вбок, чтобы увидеть все столбцы
| Вопрос | Какой источник проверяется | Как это проверяется | Что остаётся неизвестным после этой проверки |
|---|---|---|---|
| Блокирует ли баннер согласия теги или разрешает их так, как настроено? | Сигналы Consent Mode v2 (ad_storage, analytics_storage) | Просмотреть существующие записи запросов для каждого выбора согласия, сравнивая запросы без cookie и с полным набором данных; если записей нет, пометить как непроверенное | Точно ли собственное моделирование Google восстанавливает отклонённый трафик: это происходит внутри систем Google, а не в том, что здесь видно |
| Укладывается ли доля Unassigned в диапазон, согласующийся с настройкой согласия этого магазина? | Отчёт GA4 Traffic acquisition, строка Unassigned | Процент читается прямо из отчёта за проверяемый период | Фиксированной цифры, при которой Unassigned считается слишком высоким для любого магазина, не существует: проверка сообщает число, а не оценку |
| Отражает ли Event Match Quality в Meta то, что этот магазин реально отправляет? | Overview в Meta Events Manager, оценка EMQ и разбивка по параметрам | Оценка и все перечисленные отсутствующие или некорректные параметры читаются для проверяемого пикселя или набора данных | EMQ оценивает полноту данных, а не эффективность рекламы: низкая оценка не значит, что сама кампания проваливается |
| Сообщает ли Google Ads конверсии за то же окно, за которое Shopify показывает заказы? | Отчёт по конверсиям Google Ads и заказы Shopify, тот же диапазон дат | Суммарные количества конверсий сравниваются за окно, потому что Google Ads не отдаёт построчного фида по заказам | Какие именно заказы стоят за разрывом: суммарное сравнение может сказать, что разница есть, но не какие это заказы |
Вывод и следующий шаг
По такому чек-листу возможны два обоснованных вывода, и оба допустимы.
В проверенном объёме дефектов не найдено. Выполненные проверки не нашли сбоев в просмотренных системах, заказах и периоде. Запишите рядом с этим результатом все непроверенные строки и оставшиеся ограничения. Это не подтверждает все пути оплаты, историческое покрытие или атрибуцию и не доказывает, что каждая сообщённая цифра верна.
Нужна дальнейшая диагностика. В одной или нескольких строках четвёртая колонка указывает на разрыв, который не объясняется согласием, моделированием или суммарной отчётностью: повторяющийся transaction_id, замолчавший пиксель, серверное событие без парного браузерного. Это сигнал, что конкретную причину можно найти, а не заключение, что она уже найдена.
Так или иначе, итоговый документ, который я бы сохранил, выглядит как в разобранном примере этого диагностического метода: что проверено, что это доказало и что нет, на вымышленном магазине, в том же формате, что и для настоящего.
Перед сезонным пиком мой чек-лист готовности трекинга к BFCM 2026 ставит эти проверки в расписание, с заморозкой тегов и проверкой после пика.
Если какая-то строка показала то, чего вы не можете объяснить, следующий шаг такой: описать результат проверки, а не покупать что-то. Напишите мне и укажите URL магазина, какая строка не прошла и что вы увидели. Если для определения причины или объёма работ нужна более глубокая проверка без изменения настроек, для этого есть Health Check. Это не шаг по умолчанию, а шаг на случай, когда возможностей самопроверки не хватает.
