Как исправить событие purchase в GA4 на Shopify (по шагам)

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

Как сегодня срабатывает событие покупки в Shopify?

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

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

• Контейнер GTM или сниппет gtag, загруженные вашей темой, не видят события чекаута, потому что пиксель и тема живут в разных контекстах.
• Всё, что вы хотите отправлять из чекаута, включая тег GA4, должно загружаться внутри самого пикселя или пересылаться из Shopify на сервер.

Это объясняет прежние симптомы. GTM в теме перестал получать покупки из-за изоляции пикселя.

Что случилось с Additional Scripts и checkout.liquid?

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

• Кастомизации через checkout.liquid были способом, которым магазины Plus внедряли трекинг в чекаут. Этот путь закрыт в пользу Checkout Extensibility.
• Additional Scripts на страницах «Спасибо» и статуса заказа были устаревшим местом для трекинга. 28 августа 2025 стало датой отключения для Plus. Для магазинов без Plus Shopify в тот же день сделал Additional Scripts доступными только для просмотра, а затем потребовал обновить страницы до 26 августа 2026. У скрипт-тегов страницы статуса заказа те же даты отключения для Plus и для магазинов без Plus. Проверяйте версию страницы и данные заказов магазина и не считайте, что одна дата подходит всем магазинам.

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

Ограничения реализации через кастомный пиксель

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

Ниже приведён гипотетический пример кастомного пикселя. Это не поддерживаемая Google настройка и не проверенное внедрение. Он показывает сопоставление событий для обновлённого чекаута со скидками на уровне позиций. Скидки на уровне заказа и цены с налогом нужно отдельно сверять с заказом: этот пример такие корректировки не покрывает. Пиксель сам загружает gtag в песочницу и не использует тег темы.

// Shopify admin → Settings → Customer events → Add custom pixel
// This code runs in Shopify's pixel sandbox: it has its own window,
// isolated from your theme. A GTM/gtag snippet on the theme is NOT
// reachable here, so load gtag inside the pixel and fire from here.

const MEASUREMENT_ID = 'G-XXXXXXXXXX';

// 1) Load gtag.js into the sandbox and configure GA4
const s = document.createElement('script');
s.src = 'https://www.googletagmanager.com/gtag/js?id=' + MEASUREMENT_ID;
s.async = true;
document.head.appendChild(s);

window.dataLayer = window.dataLayer || [];
function gtag() { dataLayer.push(arguments); }
gtag('js', new Date());
gtag('config', MEASUREMENT_ID, { send_page_view: false });

// 2) Fire the purchase exactly once, when the checkout completes
analytics.subscribe('checkout_completed', (event) => {
  const checkout = event.data.checkout;
  if (!checkout.order?.id || !checkout.currencyCode || !checkout.lineItems?.length) return;

  const items = (checkout.lineItems || []).map((line) => ({
    item_id: line.variant && (line.variant.sku || line.variant.id),
    item_name: line.title,
    item_variant: line.variant && line.variant.title,
    price: line.finalLinePrice.amount / line.quantity,
    quantity: line.quantity,
  }));

  gtag('event', 'purchase', {
    transaction_id: checkout.order.id,
    value: items.reduce((sum, item) => sum + item.price * item.quantity, 0),
    currency: checkout.currencyCode,
    tax: checkout.totalTax && checkout.totalTax.amount,
    shipping:
      checkout.shippingLine &&
      checkout.shippingLine.price &&
      checkout.shippingLine.price.amount,
    items: items,
  });
});

Если вы отправляете через Google Tag Manager, тот же блок analytics.subscribe передаёт эквивалентный объект в dataLayer, который читает контейнер, загруженный внутри пикселя. Правило не меняется: целевой тег должен выполняться в песочнице вместе с подпиской, а не в теме. Как устроен этот объект, описано в заметке про dataLayer.

Что требует массив items в GA4?

Google указывает items и transaction_id как обязательные параметры purchase. Событие, пришедшее без них, не подтверждает, что реализация ecommerce соответствует описанной схеме.

По справочнику Google по ecommerce, каждому товару нужен хотя бы один из item_id или item_name; если отправлять оба, проверять проще. price, quantity и item_variant нужны для полезных отчётов по товарам. Несколько правил, которые экономят время на отладке:

• value равен сумме price × quantity по товарам, без налога и доставки. Берите цены за единицу после скидок, а налог и доставку отправляйте в отдельных параметрах. Сверяйте с Shopify то же определение value.
• currency обязателен и должен быть трёхбуквенным кодом ISO. В мультивалютных магазинах отправляйте валюту, в которой покупатель реально платил, и следите, чтобы value был в той же валюте.
• item_id должен быть стабильным. Используйте SKU или ID варианта везде одинаково, потому что по этому ключу GA4 связывает товары между событиями.

Как GA4 дедуплицирует покупки Shopify?

GA4 дедуплицирует покупки с одинаковым transaction_id в веб-потоках. Google описывает это для транзакций одного пользователя; для разных пользовательских контекстов и потоков приложений гарантии нет. Важны два правила:

1. Отправляйте покупку ровно по одному пути. Нативный канал продаж GA4 в Shopify и кастомный пиксель могут оба отправить заказ в разных пользовательских контекстах. Совпадающий transaction ID сам по себе не доказывает, что дедупликация сработала. Выберите один путь и проверьте полученное событие.
2. Никогда не отправляйте пустой transaction_id. GA4 дедуплицирует все покупки с пустым transaction ID вместе, поэтому пустое значение не помогает и к тому же схлопывает настоящие заказы в один. Всегда отправляйте реальный ID заказа.

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

Порядок проверки

Проверять внутри песочницы нужно иначе, чем обычную страницу: привычный способ (открыть GTM Preview или Tag Assistant) здесь в основном не работает. Я проверяю в следующем порядке.

1. DebugView, на реальном заказе. Переведите тестовое устройство в режим отладки и пройдите настоящий чекаут. Следите, как purchase появляется в DebugView, и проверьте его параметры: есть ли transaction_id и не пустой ли он, верен ли value, правильна ли currency, есть ли в items товары.
2. Realtime как быстрая проверка. Покупка должна появиться в отчёте Realtime почти сразу. Realtime подтверждает, что событие приходит, даже когда DebugView подключается с трудом.
3. Учитывайте ограничения инструментов. Tag Assistant и GTM Preview не могут подключиться к песочнице пикселя так, как они подключаются к странице. Если события там нет, это нормально: это не доказательство, что пиксель не сработал. Судите об успехе по DebugView и Realtime.
4. Каждый способ оплаты, а не один. Проверьте обычную оплату картой, Shop Pay, экспресс-чекаут или кошельки и допродажи после покупки. Shopify отправляет checkout_completed один раз: обычно на странице «Спасибо», а в сценариях post-purchase на первой странице предложения допродажи. Если эта страница не загрузилась, событие не отправляется.
5. Сверяйте после обработки. Сравните покупки GA4 с заказами Shopify по transaction ID после того, как отчёты обработаны. Google сообщает, что обработка может занимать 24–48 часов. Сверка показывает долю заказов, учтённых аналитикой; она не доказывает, что браузерный сбор зафиксировал каждый заказ, независимо от согласия или неудачной загрузки страницы.

Типичные сбои

• Двойные пиксели. Нативный канал продаж GA4 и кастомный пиксель могут отправлять дублирующие покупки. Оставьте один путь отправки покупки и проверьте ID и пользовательский контекст, прежде чем делать вывод, что выручка удвоилась.
• Пропущенные экспресс-пути. Покупка привязана к сценарию, который Shop Pay или экспресс-чекаут пропускают, поэтому заказы через кошельки не отправляют purchase и теряются при сверке. Это тот же класс сбоев, что описан в материале сломался трекинг чекаута Shopify.
• Блокировка из-за согласия. Если на сайте есть баннер согласия, хранилище аналитики может быть отклонено, и тогда пикселю не разрешено отправлять данные для таких посетителей. Это следствие выбора посетителя. Обходить его кодом нельзя. Речь о технической реализации, это не юридическая консультация; о механизме см. Consent Mode v2.
• Устаревший тег в Additional Scripts. Покупка настроена в месте, где скрипты больше не выполняются. Прежде чем менять настройку, проверьте версию страницы магазина и не отправляет ли событие уже пиксель или приложение на замену.
• Пустой или несовпадающий transaction_id. Пустой ID схлопывает заказы; ID, который отличается между путями, полностью ломает дедупликацию. Смотрите связанный разбор GA4 не видит покупки.

Ограничения

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

Песочница ограничивает и отладку, поэтому проверка опирается на DebugView, Realtime и сверку, а не на привычные инструменты проверки самой страницы. Пиксель исправляет только отправку покупки: события воронки до неё, вроде add-to-cart, он сам по себе не восстановит, если их сломала та же миграция чекаута.

Альтернативы

Есть три общих способа отправить покупку Shopify, и они не исключают друг друга.

• Нативная интеграция Shopify. Google поддерживает настройку через приложение Google & YouTube. Перед его добавлением проверьте, нет ли уже кастомного тега покупки, чтобы два пути не отправляли один и тот же заказ.
• Кастомный пиксель с GTM или gtag (гипотетический пример выше). Код ваш, но Google эту настройку не поддерживает. Успешная отправка одного события не доказывает, что работают остальные функции тегов Google.
• Серверный вариант. Серверная настройка может пересылать вебхуки заказов Shopify, а события из браузера дают контекст сессии и согласия. В вебхуках нет cookie браузера. Настройке нужны хостинг, мониторинг и продуманная схема согласия; требование согласия она не снимает.

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