Почему выручка в GA4 не совпадает с заказами Shopify

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

Почему выручка в GA4 и Shopify может отличаться?

Я отделяю различия в охвате от пропущенного или неверного сбора. Эти проверки могут объяснить разрыв, но ни одна из них не доказывает причину без подтверждающих данных.

• Атрибуция и охват. Атрибуция распределяет вклад в покупку между точками контакта. Я сначала сравниваю выручку от покупок по всем каналам, а не промежуточный итог канала или число сессий. Другое распределение вклада каналов само по себе не меняет эту сумму событий по всем каналам.
• Часовой пояс. В метаданных отчёта GA4 указан его часовой пояс отчётности; у Shopify есть отдельная настройка часового пояса магазина. При разных настройках одна временная метка может попасть на разные календарные даты. Синтетический пример ниже показывает эту границу явно.
• Настройка согласия. Базовый режим согласия блокирует теги Google после отказа. Расширенный режим может отправлять измерения без cookie. Я различаю наблюдаемое сопоставление заказов и смоделированные итоги отчёта. Это описание технического сбора, а не юридическая консультация.
• Сбор и механизмы приватности. Я проверяю, был ли запрос о покупке отправлен и получен и не помешали ли этому механизм приватности или сбой тега. Одна отсутствующая строка отчёта не позволяет отличить эти варианты.
• Сроки и доставка возвратов. Shopify записывает возврат продаж (sales reversal) как отрицательное значение на дату его обработки, которая может быть позже даты заказа. Чтобы скорректировать выручку от покупок, GA4 нужно переданное событие refund. Я проверяю и тип возврата продаж, и доставку: не каждый возврат только денег одинаково влияет на продажи Shopify.
• Конвертация валют. В магазинах с несколькими валютами значение, отправленное в GA4, может быть в валюте покупателя (presentment currency), а Shopify отчитывается в валюте магазина, либо конвертация идёт по другому курсу. Число заказов может совпадать, а выручка нет.
• Фильтры данных и пороги. Действующие фильтры исключения данных навсегда исключают входящие события из обработки и из BigQuery. Пороги данных вместо этого скрывают строки отчёта или исследования. Я проверяю, какой из механизмов работает: это не один и тот же вид пропущенных данных.

Какое расхождение выручки между GA4 и Shopify нормально?

В документации платформ, на которую я ссылаюсь, допустимого процента нет. На сравнение влияют настройка согласия, область отчёта и заказы в периоде. Я оцениваю, объяснено ли каждое различие, а не называю какой-то процент нормальным.

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

Я использую три сценария, чтобы решить, где искать дальше:

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

Затем я сверяю заказы, сравниваю корректировки и ищу подтверждения на уровне событий. Сопоставление выявляет различия; оно не объясняет автоматически, почему события нет.

Дерево диагностики

Используйте эти сценарии, чтобы выбрать проверку. В среднем столбце указаны возможные причины, которые ещё нужно проверить.

Что видно в отчётах	Возможное объяснение	Как проверить
GA4 ниже везде, процент устойчивый из месяца в месяц	Другой охват, настройка согласия или сбор	Сравните определения и данные о сборе по каждому заказу; не определяйте причину по трафику Unassigned или одной лишь стабильности разрыва
GA4 ниже только с определённой даты	Изменение конфигурации, согласия или чекаута	Сравните даты изменений; проверьте согласие, сетевую доставку и конфигурацию отладки
GA4 ниже, и разрыв растёт	Изменившийся состав заказов, охват или сбойный путь чекаута	Сверьте заказы и проверьте пути, связанные с пропавшими событиями
GA4 выше Shopify	Тестовые заказы, доставка возвратов или повторные отправки	Проверьте, какие заказы включены, возвраты и ID транзакций, прежде чем считать, что выручка в отчёте удвоена
Разрыв скачет по дням, но за месяц сходится	Граница часового пояса плюс время возвратов	Приведите обе выгрузки к одному часовому поясу и одному окну дат
Число заказов совпадает, а выручка нет	Конвертация валют или неверный параметр value	Проверьте параметры currency и value в событии purchase

Как сверить GA4 и Shopify по каждому заказу?

Итоги в панелях показывают разницу; сопоставление определяет затронутые заказы и корректировки. Вот метод, которым я пользуюсь: неизвестные причины остаются открытыми, пока данные не подтвердят их.

1. Выберите закрытый период. Я беру завершённый месяц и записываю время выгрузки. Более поздние корректировки я проверяю отдельно и не считаю, что месяц больше никогда не изменится.
2. Выгрузите данные Shopify. Из CSV заказов я сохраняю имя или ID заказа, время создания, итог, валюту и финансовый статус. Несколько позиций заказа могут давать несколько строк; я не считаю один заказ дважды. Я согласовываю, какие заказы включать, и получаю датированные возвраты продаж отдельно, потому что текущий итог заказа не равен отчёту о продажах за период.
3. Выгрузите данные GA4. Я использую строки отчёта по ID транзакций или полученные события в BigQuery, включая покупки и возвраты. Перед сравнением я проверяю настройки и полноту экспорта; в стриминге бывают пропуски.
4. Приведите обе стороны к одному виду. Я выравниваю часовой пояс, окно дат, валюту и компоненты продаж и согласовываю, как учитываются возвраты. Каждую корректировку я документирую и не считаю, что нормализация объясняет весь разрыв.
5. Сопоставьте по согласованному ключу. Я соединяю идентификатор заказа с transaction_id из GA4 по проверенному сопоставлению там, где форматы различаются. Несопоставленные и неоднозначные строки я держу отдельно.
6. Классифицируйте различия. Я разделяю заказы, которые есть только в Shopify, записи, которые есть только в GA4, и сопоставленные записи с разными суммами. Это наблюдения, а время, охват, тесты, пропущенная доставка и валюта остаются кандидатами для проверки, а не автоматическими диагнозами.
7. Разберите группы расхождений. Я группирую различия по доступным данным о чекауте или оплате. Общая характеристика подсказывает, где тестировать; причину в коде она не доказывает. Отсутствующие данные я помечаю как неизвестные.

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

-- Purchase transaction_ids sent more than once in one day (GA4 BigQuery export)
SELECT
  (SELECT value.string_value FROM UNNEST(event_params)
   WHERE key = 'transaction_id') AS transaction_id,
  COUNT(*) AS purchase_events
FROM `project.analytics_XXXXXX.events_20260701`
WHERE event_name = 'purchase'
GROUP BY transaction_id
HAVING purchase_events > 1
ORDER BY purchase_events DESC;

Разобранный пример (гипотетический)

Это один полностью синтетический период, а не результат клиента. Я сравниваю сентябрь 2026 в гипотетическом магазине Shopify (America/New_York, USD) и в ресурсе GA4 (UTC, USD). Все суммы, метки заказов и курсы обмена ниже выдуманы для этого примера.

В исходных выгрузках у каждой системы своя граница сентября. Shopify показывает Total sales $400,60; GA4 показывает Purchase revenue $318,29. Разница, Shopify минус GA4, равна $82,31. Я использую purchase revenue по всем каналам, а не промежуточный итог атрибутированного канала. Total sales в Shopify включает возвраты продаж и другие компоненты продаж; Purchase revenue в GA4 вычитает переданные возвраты.

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

Колонки таблицы показывают вклад каждой строки в исходные сентябрьские итоги. Все суммы в долларах США; заказ C был оплачен в EUR до конвертации. Разрыв считается как Shopify минус GA4. Названия строк остаются видимыми при прокрутке таблицы.

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

• Валюта, +$2,00. Для C гипотетический сохранённый в Shopify эквивалент равен EUR 100,00 × 1,10 = $110,00. Гипотетический эквивалент в отчётности GA4 равен EUR 100,00 × 1,08 = $108,00. Это курсы тестового набора, а не курсы, заявленные для сентября. GA4 конвертирует локальные валюты в валюту отчётности; я использую сохранённые значения и не исхожу из того, что обе системы выбрали один курс.
• Согласие, +$50,40. Заказ D завершён, но гипотетическая настройка базового согласия заблокировала теги аналитики после отказа, и наблюдаемой покупки не осталось. Сбор при базовом и расширенном согласии различается. В этом примере используются наблюдаемые транзакции без добавлений по модели; он не утверждает, что каждый заказ с отказом отсутствует в каждом отчёте GA4. Это описание технической реализации, а не юридическая консультация.
• Граница часового пояса, +$60,25. Заказ E оформлен 30 сентября в 23:30 по America/New_York, то есть 1 октября в 03:30 UTC. Его покупка в GA4 есть в октябре; это не пропавшее событие. Согласованное окно по времени магазина идёт с 1 сентября 04:00 UTC до 1 октября 04:00 UTC, конец не включается. Других событий тестового набора, пересекающих любую из границ, нет. Я заново отбираю события по временным меткам в этом окне; смена подписи в панели событие не переносит.
• Включение тестов, −$9,99. F здесь гипотетический тестовый заказ Shopify Payments в тестовом режиме. Продажи Shopify его исключают, но в этом тестовом наборе фильтр тестовых заказов не сработал, и покупка дошла до GA4. Отчёты Shopify о продажах исключают тестовые заказы, а экспорт заказов их включает. Я убираю F из сравнения и разбираюсь с фильтром тестов.
• Возврат, −$20,35. Завершённый сентябрьский возврат продаж по позиции B уменьшает продажи Shopify. В тестовом наборе возврат в GA4 не отправлялся, поэтому GA4 сохраняет исходные $80,20. Для измерения возвратов в GA4 нужно событие refund, привязанное к транзакции. Я учитываю недостающие $20,35 и записываю передачу возвратов как задачу для диагностики; это не автоматически безвредное структурное расхождение.

Количества заказов тоже сходятся: в Shopify пять нетестовых заказов (A–E). В исходном сентябрьском срезе GA4 четыре покупки (A, B, C и тестовый F). Если исключить F, остаётся три; если добавить E по согласованному окну времени, получается четыре наблюдаемые покупки по нетестовым заказам. Заказ D объясняет один оставшийся ненаблюдаемый заказ. Возврат считается отдельной денежной корректировкой, а не шестым заказом.

Сверка по шагам: $318,29 − $9,99 + $60,25 + $2,00 − $20,35 = $350,20. Если учесть $50,40 по D, получается $400,60, ровно итог Shopify. Это корректировки сверки, а не правки GA4 и не указание отправлять покупку, по которой согласие отклонено. Исходные $82,31 объяснены полностью: $2,00 + $50,40 + $60,25 − $9,99 − $20,35 = $82,31.

Я бы разобрался с фильтром тестовых заказов и недостающей доставкой возвратов. Различия по валюте и окну дат я задокументировал бы, а границу согласия по D сохранил. Совпадение итогов после объяснённых корректировок не доказывает, что каждый путь чекаута работает; оно говорит лишь, что в этом тестовом наборе нет необъяснённого остатка.

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

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

• DebugView и сетевые данные. При включённом режиме отладки я смотрю параметры purchase в DebugView. Механизмы приватности или отказ в согласии могут помешать событиям стать видимыми. Одна отсутствующая строка не доказывает ни того, что код не сработал, ни того, что запрос был получен; я проверяю согласие, конфигурацию отладки и сетевые запросы браузера.
• Несколько путей чекаута. Я тестирую реальные пути оплаты картой, кошельком, экспресс-чекаут и пути после покупки, которые входят в объём работ, вместо того чтобы считать, что один успешный чекаут доказывает все остальные.
• Проверки ID транзакций. Я проверяю один уникальный непустой ID на заказ. GA4 дедуплицирует покупки одного пользователя с общим ID в веб-потоках, но не в потоках приложений. Повторно использованные или пустые ID могут скрыть разные покупки; разные ID для одного заказа могут помешать дедупликации.
• Данные BigQuery. Я сравниваю полученные сырые события с записями о заказах. Они не могут показать непринятое событие или гарантировать полноту сбора; я проверяю также лимиты и настройки экспорта.

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

Эти возможные ошибки реализации я бы проверял по данным. Итоговой суммы для вывода недостаточно.

• Неполная доставка. Покупка из нужного сценария чекаута не поступает на платформу. Я тестирую триггер и запрос на этом пути.
• Повторные отправки. Два пути сбора отправляют один заказ с разными или отсутствующими ID. Покупки одного пользователя в вебе с общим ID в отчётах дедуплицируются; два тега сами по себе не доказывают удвоенную выручку. Какие пути сбора проверять, описано в гайде по событию purchase.
• Неоднозначные ключи. Идентификаторам заказов нужно проверенное сопоставление. Несопоставившаяся строка сама по себе не доказывает дефект дедупликации.
• Недоставленные возвраты. У возврата продаж в Shopify нет соответствующего refund в GA4. Прежде чем отнести разницу к этой причине, я проверяю тип, сумму и период.
• Неверное значение или валюта. Я сравниваю полученные параметры с ожидаемыми суммами и компонентами заказов.

Ограничения сверки

Бесплатный инструмент Shopify orders vs GA4 purchases сравнивает ваши CSV-выгрузки локально и отмечает для проверки отсутствующие и повторяющиеся ID, а также расхождения в суммах.

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

Если базовое согласие или блокировщик не дали событию дойти до GA4, набор полученных событий его восстановить не может. Чтобы назвать эту причину, мне нужны данные о сборе или согласии по каждому заказу; одного отсутствия недостаточно. Расширенное согласие может отправлять измерения без cookie, поэтому отказ не означает отсутствие данных во всех случаях. Я соблюдаю ограничения согласия и не отправляю пропавшие заказы, чтобы подогнать сопоставление.

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

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

Серверный трекинг (server-side tagging) переносит обработку событий на инфраструктуру, которую вы контролируете. В потоке от браузера к серверу запрос всё равно должно отправить устройство. Я определил бы объём серверной работы отдельно, проверив доставку и согласие; перенос обработки сам по себе не доказывает, что заблокированные события восстановлены. Про повторяющийся симптом смотрите расхождение выручки GA4 и Shopify, про метод сопоставления: сверку заказов.