GA4 на Shopify: приложение Google & YouTube или кастомный web pixel

У GA4 на Shopify два распространённых способа подключения: приложение Google & YouTube или кастомный web pixel в Customer Events, через который события отправляете вы сами. Оба отправляют данные ecommerce в ваш ресурс GA4. Различаются они тем, кто пишет сопоставление, кто его поддерживает и что вы можете изменить.

Гайд сравнивает их по принципу работы: что отправляет покупку, как передаётся transaction ID, как учитывается согласие и что ломается. Победителя он не выбирает, потому что правильный ответ зависит от того, какой контроль вам нужен и какое сопровождение вы готовы обеспечить. Серверная пересылка сюда не входит: это отдельный способ доставки.

Если свой пиксель уже выбран и нужно найти сбой, начните с диагностики пикселя Shopify и GTM. Она прослеживает одно событие от Customer Events до получателя. Ниже продолжается сравнение архитектур.

Что на самом деле делает приложение Google & YouTube?

Приложение Google & YouTube разработано совместно с Google как приложение канала продаж Shopify. Оно загружает теги Google в магазин и сопоставляет стандартные события Shopify с рекомендованными названиями ecommerce в GA4, так что покупка попадает в GA4 без написания кода пикселя. Вы его настраиваете; сопоставление поддерживают Shopify и Google.

Оно подписывается на стандартные события Shopify и сопоставляет их с рекомендованными названиями GA4: product_viewed с view_item, product_added_to_cart с add_to_cart, checkout_started с begin_checkout и checkout_completed с purchase; смежные события корзины, списков, доставки и поиска тоже покрыты.

Покупка передаётся как полноценное событие ecommerce в GA4: transaction_id, value, currency, tax, shipping, coupon, market_id и массив items с id, названием, брендом, вариантом, ценой, количеством и SKU. Value равен подытогу за вычетом скидок, без доставки и налогов; если в событии нет валюты, по умолчанию подставляется USD. Каждое событие также содержит shopify_event_name и event_id. Данные покупателя, такие как email и телефон, прикрепляются, только если это разрешают согласие и настройки Analytics.

Вам доступна конфигурация, а не код: вы подключаете свой ресурс GA4 или добавляете тег Google вручную, а внутри GA4 можете фильтровать события по shopify_event_name. Сопоставление, формула value и набор параметров зафиксированы. Google указывает, что поддерживаются не все функции тегов на основе кода из-за ограничений песочницы Shopify.

Покупка показывает и сильную сторону приложения, и его ограничения. Оно срабатывает от checkout_completed, поэтому не зависит от того, работает ли скрипт на странице «Спасибо», но отправляет только то, что определяет схема Google: событие возврата, собственный параметр или ваше определение value лежат за пределами его документированных возможностей.

Что на самом деле делает кастомный web pixel?

Кастомный web pixel вы пишете на JavaScript и добавляете в Customer Events в админке Shopify. Он подписывается на стандартные события Shopify и отправляет в GA4 всё, что вы ему укажете, через gtag или контейнер GTM, загруженный внутри пикселя. Названия событий, параметры, массив items, transaction_id и контроль согласия выбираете вы.

Пиксель работает в песочнице Shopify. Кастомные пиксели загружаются в lax-песочнице (iframe, ограниченный скриптами и формами) и не могут обращаться к верхнему фрейму, читать DOM или пользоваться dataLayer витрины. Взамен вы получаете структурированные данные событий и Standard API Shopify. Код, который ожидает страницу или window.dataLayer, не находит ни того ни другого, поэтому сниппеты, перенесённые из файла темы, ничего не делают.

В песочнице вы решаете всё, что за вас решает приложение: на какие события подписаться, как их назвать, как собрать items и что использовать как transaction_id и value. Подписка на покупку может выглядеть примерно так:

analytics.subscribe('checkout_completed', (event) => {
  const checkout = event.data.checkout;
  gtag('event', 'purchase', {
    transaction_id: checkout.order.id,
    value: checkout.subtotalPrice.amount,
    currency: checkout.currencyCode,
    items: checkout.lineItems.map((item) => ({
      item_id: item.variant?.sku ?? String(item.variant?.id),
      item_name: item.title,
      price: item.variant?.price?.amount,
      quantity: item.quantity,
    })),
  });
});

Согласие подключаете вы. Пиксель может читать init.customerPrivacy и подписываться на visitorConsentCollected, а затем ограничивать то, что отправляет. Shopify и так запускает пиксели в регионах с обязательным согласием только после того, как посетитель дал согласие на нужные цели, и воспроизводит более ранние события; ваши правила дополнительно ограничивают отправку.

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

Что будет, если запустить оба сразу?

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

Правило у GA4 точное: он схлопывает события покупки с одинаковым transaction_id в веб-потоках, а пустой transaction_id заставляет GA4 дедуплицировать несвязанные покупки вместе. Это помогает, только когда оба пути отправляют один и тот же непустой идентификатор. Но выбирают его они независимо: приложение выводит свой из заказа, а ваш пиксель берёт то, что выбрали вы, поэтому несовпадение случается часто, и GA4 видит два заказа. Решение: оставьте один путь покупки, сначала выключите один путь, потом включите другой и убедитесь в DebugView, что один тестовый заказ даёт одну покупку.

Сравнение вариантов

Таблица сравнивает их по критериям, от которых зависит работа большинства настроек. Это описание компромиссов, а не рейтинг.

Критерий	Приложение Google & YouTube	Кастомный web pixel (gtag или GTM)
Источник событий	Стандартные события Shopify, сопоставленные приложением	Ваши подписки на стандартные события Shopify
Покрытие покупок и возвратов	Документированное сопоставление доходит до purchase; корректировка возвратов вне его настраиваемых возможностей	Вы отправляете purchase и любые события возврата; покрытие определяете вы
Дедупликация	Приложение само генерирует transaction_id и event_id	Вы выбираете transaction_id и event_id
Обработка согласия	Работает как пиксель под управлением Customer Privacy API Shopify и учитывает заявленные им цели	Вы сами читаете объект приватности и ограничиваете события
Владение данными	Сопоставление принадлежит Shopify и Google; данные попадают в ваш ресурс GA4	Логика принадлежит вам; данные попадают в ваш ресурс GA4
Зависимость и привязка к вендору	Зависит от приложения и канала Shopify, через который оно работает	Зависит от песочницы Shopify и схемы событий
Нагрузка на сопровождение	Вендор поддерживает сопоставление по мере изменений платформы	Вы сопровождаете каждое изменение схемы и параметров
Кому подходит	Магазинам, которым нужен ecommerce в GA4 с минимумом кода	Магазинам, которым нужны параметры, события или ограничения, которых в приложении нет

Таблица решений

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

Если ваша ситуация …	Выбирайте …
Вам нужны стандартные события ecommerce в GA4, и никто не пишет код пикселя	Приложение Google & YouTube
Вам нужно событие, параметр или поле items, которых приложение не отправляет	Кастомный web pixel
Нужно точно контролировать, что и когда срабатывает под вашим баннером согласия	Кастомный web pixel с собственным ограничением
Вы уходите с Additional Scripts или checkout.liquid и хотите поддерживаемый путь	Приложение Google & YouTube
У вас уже работает кастомный пиксель, и нужно только убрать старый скрипт	Оставьте пиксель и убедитесь, что второй путь покупки не активен
Вы хотите, чтобы сопоставление событий поддерживали за вас по мере изменений чекаута в Shopify	Приложение Google & YouTube
Потери из-за заблокированных или обрезанных запросов, а не из-за сопоставления	Ни один сам по себе: см. серверный трекинг

Когда какой вариант не подходит

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

Не берите приложение Google & YouTube, когда:

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

Не берите кастомный web pixel, когда:

• Им никто не будет заниматься: каждое изменение схемы Shopify превращается в сбой, который ждёт, когда его заметят.
• Вам нужна конфигурация, которую поддерживает Google. Google указывает, что теги Google в кастомном пикселе не поддерживаются и что его поддержка их не чинит.
• Вы полагаетесь на Tag Assistant или GTM Preview: они отлаживают теги на странице, а не внутри песочницы пикселя.
• Вам хватает стандартного сопоставления ecommerce: вы возьмёте на себя сопровождение без выгоды.

Не ждите, что любой из них исправит:

• Сигнал, потерянный из-за блокировщиков рекламы, закрытых вкладок или отказа от согласия. Это потери при передаче данных. Для них нужна серверная доставка, а не другой тег в браузере.
• Постоянный разрыв между GA4 и Shopify. Эти две системы считают по-разному; здесь поможет метод сверки, а не пиксель получше.

Как я проверяю это на реальных внедрениях

Я считаю события по каждому заказу. Один путь покупки должен давать одну покупку на заказ, видимую в DebugView с совпадающим transaction_id и сверяемую с выгрузкой заказов Shopify. Всё остальное (согласие, items, валюту) я проверяю на том же заказе.

1. Определите, какой путь отвечает за покупку. В Settings → Customer events перечислены зарегистрированные пиксели. Найдите каждый, который может отправить покупку; такой должен быть ровно один.
2. Проследите тестовый заказ в DebugView. Переведите устройство в режим отладки, пройдите чекаут целиком и убедитесь, что purchase приходит с transaction_id, value, currency и items. Проверьте больше одного пути чекаута, прежде чем считать тег неработающим.
3. Сверьте ключ с заказом. transaction_id, который получил GA4, должен быть непустым, уникальным для этого заказа и одинаковым на каждом пути, который его отправляет.
4. Сверьте данные рекламных платформ. Там, где участвует Meta, Test Events в Events Manager должен показать одну конверсию на заказ, а не по одной на каждый путь в браузере.
5. Сверьте на следующий день. Сравните покупки GA4 по transaction_id с выгрузкой заказов Shopify за закрытый период тем же методом сверки заказов, который используется в аудите трекинга.
6. Проверьте и отказ, и принятие согласия. При отказе убедитесь, что теги остаются заблокированными; затем дайте согласие и убедитесь, что события идут; см. Consent Mode v2.

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

Большинство сбоев типичны: это второй путь покупки, который оставили работать, пустой transaction_id, value, определённый по-разному с каждой стороны, или код в песочнице, который рассчитывал читать страницу.

• Два пути покупки, два ID. Приложение и пиксель оба срабатывают и отправляют разные значения transaction_id, поэтому GA4 считает заказ дважды.
• Пустой transaction_id. GA4 дедуплицирует вместе все покупки с ним, поэтому несвязанные заказы объединяются в одну покупку.
• Value, рассчитанный по другим правилам. Приложение отправляет подытог за вычетом скидок, без доставки и налогов; написанный вручную пиксель, который отправляет итог брутто, не совпадёт ни с отчётностью GA4, ни с нетто-суммой Shopify.
• Код в песочнице, который рассчитывал читать страницу. Сниппеты, перенесённые из файла темы, молча ничего не делают, потому что в песочнице нет DOM и общего dataLayer.
• Отладка не тем инструментом. Контейнер GTM в пикселе может выглядеть сломанным в GTM Preview или Tag Assistant: они отлаживают теги на странице, а не внутри песочницы пикселя.
• Нет контроля согласия в кастомном пикселе. События продолжают уходить для посетителей, которые отказались: это проблема соответствия требованиям, а не предпочтение.
• Тег всё ещё в Additional Scripts. После перехода на Checkout Extensibility старое поле перестаёт выполняться, и покупка не отправляется, хотя ошибка не показывается.

Ограничения

Ни один вариант не устраняет потери при передаче. Оба зависят от того, что пиксель Shopify работает в браузере, поэтому заказы, потерянные из-за блокировщиков, закрытых вкладок или отказа от согласия, остаются потерянными, пока отправка не будет перенесена на сервер. Кроме того, в обоих случаях GA4 считает иначе, чем Shopify: GA4 атрибутирует сессии, а Shopify записывает заказы, и выбор пикселя эту арифметику не меняет.

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

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

Если ваша проблема не в вопросе «какой пиксель», может потребоваться другой способ доставки. Серверная доставка отправляет покупку из вебхука заказа Shopify, а не из браузера, и это надёжный ответ на сигнал, потерянный из-за блокировщиков; см. гайд по серверному трекингу. Импорт офлайн-конверсий покрывает заказы, которых браузер вообще не видел.

Если вы чините сломанную покупку, а не выбираете архитектуру, порядок действий описан в гайде Как исправить событие purchase в GA4 на Shopify. Если симптом в пропавших покупках, растущем разрыве или сломанном чекауте, начните с материалов GA4 не видит покупки, выручка в GA4 не совпадает с Shopify и сломался трекинг чекаута Shopify. Основные понятия: event_id, Consent Mode v2 и first-party трекинг.