Электронная коммерция в GA4 и Метрике: как проверить заказы, выручку и возвраты

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

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

1. Договоритесь, какой момент считается покупкой

Зафиксируйте бизнес-правило до проверки кода. Магазин может считать заказ оформленным после подтверждения состава и контактов, а оплаченным — после получения подтверждённого статуса оплаты. Для заказа с оплатой при получении эти моменты разделены во времени. Нажатие кнопки оплаты само по себе не подтверждает ни списание, ни успешное оформление.

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

Для учебного примера ниже выбрано более узкое условие: покупка подтверждена после успешной оплаты, о которой знает CMS. Это решение конкретного примера, а не обязательное правило всех магазинов. Проверка платёжных уведомлений остаётся отдельной задачей; здесь мы используем уже подтверждённое состояние заказа.

Страница благодарности должна отображать это состояние, а не создавать его. Повторное открытие страницы, возврат с платёжного сайта или обновление вкладки не превращают прежний заказ в новую покупку.

2. Составьте карту событий магазина

Документация GA4 по ecommerce связывает события с действиями над массивом items. В собственной схеме Метрики используются ecommerce-объекты с соответствующими действиями и товарами. Сначала сопоставьте смысл, затем поля: одинаковое действие посетителя не всегда имеет одинаковую запись в двух системах.

Действие	GA4	Собственная ecommerce-схема Метрики
Открыта карточка товара	view_item	detail
Товар добавлен в корзину	add_to_cart	add
Товар удалён из корзины	remove_from_cart	remove
Подтверждена покупка	purchase	purchase
Выполнен возврат	refund	В стандартном перечне такого действия нет

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

Отдельно отметьте промежуточные шаги, которые действительно измеряются: начало оформления, выбор доставки, передача платёжных данных. Не создавайте для Метрики название, похожее на GA4, предполагая, что оно автоматически станет стандартным ecommerce-действием. Карта должна отражать реализованную и проверенную схему.

3. Проверьте идентификаторы, товары и валюту

Для покупки нужен устойчивый идентификатор заказа. В GA4 это transaction_id, в собственной схеме Метрики — purchase.actionField.id. Используйте один согласованный ключ CMS или явное сопоставление ключей. Новый случайный ID при каждом открытии благодарности мешает распознать повтор, а одна константа для всех заказов объединяет разные покупки.

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

Цена передаётся за единицу, количество — отдельно. Денежные значения формируются числами, без знака валюты и разделителей тысяч; валюта указывается отдельным кодом, например RUB. Не смешивайте рубли и копейки или несколько валют в одной необъяснённой сумме.

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

Проверьте момент очистки корзины. Когда событие собирается из неё уже после оформления, вместо купленных товаров может уйти пустой массив или состав следующего посещения. Запись заказа должна сохранять необходимые строки независимо от корзины. При проверке полезно открыть исходные данные заказа и сформированный объект рядом: так видно, на каком этапе исчезли количество, скидка или выбранная модификация.

4. Рассчитайте контрольный заказ до просмотра отчётов

Возьмём условный заказ SG-191-A. Все суммы приведены в рублях. Для этого примера CMS хранит товарные цены без отдельно учитываемого налога; налог и доставка записаны самостоятельными суммами. Это учебная модель расчёта, а не рекомендация по налоговому учёту.

Позиция	Цена до скидки	Скидка на единицу	Цена после скидки	Количество	Товарная сумма
TEE-BLUE-M	1200	200	1000	2	2000
BAG-GRAY	500	0	500	1	500

До скидки товары стоят 1200 × 2 + 500 = 2900. Общая скидка равна 200 × 2 = 400. Товарная сумма после скидки: 2900 − 400 = 2500. В CMS отдельно записаны налог 500 и доставка 300, поэтому полная сумма оплаты составляет 2500 + 500 + 300 = 3300.

Сохраните эти четыре составляющие в протоколе. Требование «передать сумму заказа» неоднозначно: разработчик может взять 3300, аналитик ожидать 2500, а отчёт по товарам суммировать строки. Пока формула не определена, разница 800 выглядит ошибкой, хотя это ровно налог и доставка.

Если скидка применяется ко всему заказу, заранее определите её распределение по строкам и округление. После распределения сумма строк должна сходиться с товарным итогом CMS. Один промокод в параметрах события не объясняет, как именно изменились цены.

5. Сопоставьте суммы с полями GA4

По спецификации purchase value равен сумме price × quantity по товарам, без shipping и tax. При скидке price содержит цену единицы после скидки, а discount — размер скидки на единицу. Поэтому скидку нельзя повторно вычитать из уже уменьшенного price.

Для нашего заказа параметры purchase выглядят так. Это учебный объект параметров, а не исполняемая отправка:

{
  "transaction_id": "SG-191-A",
  "currency": "RUB",
  "value": 2500,
  "shipping": 300,
  "tax": 500,
  "items": [
    {
      "item_id": "TEE-BLUE-M",
      "item_name": "Футболка синяя M",
      "price": 1000,
      "discount": 200,
      "quantity": 2
    },
    {
      "item_id": "BAG-GRAY",
      "item_name": "Сумка серая",
      "price": 500,
      "quantity": 1
    }
  ]
}

Сверяйте каждую величину, а не только наличие события purchase. Значение value 3300 в этом примере неверно, даже если оно совпадает с банковской оплатой. Передача 1200 как price и 200 как discount тоже не заменяет требуемую цену после скидки.

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

6. Проверьте схему Метрики и совместимость с GA4

Текущая инструкция Метрики подтверждает поддержку электронной торговли GA4: при включённой электронной коммерции и корректном подключении контейнера поддерживаемые данные могут собираться из существующей реализации. Поэтому сначала выясните, что счётчик уже получает. Дополнительный объект для той же покупки способен создать повторную передачу.

В собственном формате Метрики используются currencyCode, purchase.actionField и products. Поле revenue задаёт доход; без него сумма вычисляется по товарам. В нашем договоре измерения revenue — именно товарная сумма после скидок, 2500. Налог и доставка остаются отдельными величинами в сверке CMS.

{
  "ecommerce": {
    "currencyCode": "RUB",
    "purchase": {
      "actionField": {"id": "SG-191-A", "revenue": 2500},
      "products": [
        {"id": "TEE-BLUE-M", "name": "Футболка синяя M", "price": 1000, "quantity": 2},
        {"id": "BAG-GRAY", "name": "Сумка серая", "price": 500, "quantity": 1}
      ]
    }
  }
}

Это альтернативное представление данных для собственной схемы, а не указание одновременно отправить оба примера в общий контейнер. При сборе из GA4 отдельно проверяют результат преобразования в Метрике. Совместимость не означает, что все события и показатели двух платформ идентичны.

Если действующая интеграция определяет revenue иначе, сначала зафиксируйте её формулу. Нельзя сравнивать доход, включающий доставку, с товарным value GA4 и объявлять разницу потерей выручки. Отчёт должен явно сообщать, какую сумму команда анализирует.

7. Испытайте повторные открытия и правила дедупликации

Для GA4 Google описывает дедупликацию повторных purchase одного пользователя по transaction_id для веб-потоков. ID должен быть уникальным для заказа и сохраняться при повторной передаче той же покупки. Нельзя использовать один ID для разных пользователей и заказов или передавать пустую строку. Правило веб-потоков не следует автоматически переносить на приложения.

У Метрики есть отдельная настройка удаления дублей ecommerce-покупок в разных визитах: учитывается совпадение пользователя, суммы и идентификатора покупки. Проверьте фактическое состояние опции. Одного совпадающего ID недостаточно, чтобы обещать одинаковое поведение при любых повторных отправках.

Повторите открытие подтверждения в текущей вкладке и в последующем визите того же тестового пользователя. Затем проверьте другой настоящий контрольный заказ: он должен иметь другой ID. Если изменяются сумма или ключ из-за повторного чтения корзины, исправляйте источник данных, а не рассчитывайте на фильтрацию дублей.

Назначьте единственный ответственный механизм формирования покупки. Одновременная отправка браузером, модулем CMS и серверной интеграцией требует согласованной схемы, а не предположения, что аналитика всё объединит. Журнал должен различать попытку передачи и подтверждённый результат проверки.

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

8. Проверьте частичный и полный возврат отдельно

Пусть по SG-191-A возвращена одна футболка. CMS подтверждает возврат товарной суммы 1000 и относящегося к ней налога 200; доставка не возвращается. Покупателю возвращено 1200. В GA4 используется событие refund с прежним transaction_id и возвращаемыми товарами:

{
  "transaction_id": "SG-191-A",
  "currency": "RUB",
  "value": 1000,
  "tax": 200,
  "shipping": 0,
  "items": [
    {"item_id": "TEE-BLUE-M", "price": 1000, "quantity": 1}
  ]
}

Товарная сумма за вычетом возврата равна 2500 − 1000 = 1500. Денежный остаток оплаты — 3300 − 1200 = 2100. Проверка сходится и по составляющим: 1500 товаров + 300 оставшегося налога + 300 доставки = 2100.

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

В стандартном перечне ecommerce-действий Метрики refund не описан. Не подменяйте его отрицательной покупкой или remove: последнее относится к удалению из корзины. Возвраты ведут в CMS и отдельной согласованной аналитической схеме. До её проверки нельзя считать, что обычный ecommerce-доход Метрики автоматически уменьшился после возврата.

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

9. Проследите событие от магазина до диагностики

В GA4 используйте DebugView для своего тестового устройства. Найдите purchase, откройте параметры и сравните ID, валюту, value и items с сохранённым заказом. Зелёный статус тега не подтверждает правильность товарной суммы.

Для проверки электронной коммерции Метрики сверяют включённую опцию и имя контейнера, затем используют параметр _ym_debug=2 и вкладку Ecommerce отладчика. Для предыдущей версии кода предусмотрена проверка через консоль с _ym_debug=1. Важно увидеть конкретное действие и его данные.

Наличие объекта в dataLayer подтверждает лишь один этап. Дальше проверяются обработка счётчиком и появление данных в отчёте. Учитывайте согласие, блокировки и фильтры, не обходя выбор посетителя. Данные могут обрабатываться с задержкой; ожидание не исправит неправильный ID или сумму.

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

10. Составьте набор контрольных сценариев

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

• Обычная покупка одного товара: правильные ID, валюта и одна единица.
• SG-191-A: две позиции, три единицы, скидка, отдельные налог и доставка.
• Неуспешная оплата: в выбранной модели оплаченных покупок purchase отсутствует.
• Повторное открытие подтверждения: прежний заказ не становится новым.
• Частичный возврат: возвращается одна единица, остальные остаются в покупке.
• Возврат остатка: суммарно возвращённое не превышает исходные количества и суммы.

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

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

11. Сверяйте с CMS по заказам и одинаковым определениям

Для первой сверки берут короткий период и конкретные ID. В Метрике отчёт «Содержимое заказов» связывает покупку с товарами и доходом. В GA4 выбирают соответствующие измерения и метрики, учитывая различие событий и единиц товара.

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

Признак расхождения	Что проверить первым
Заказа нет	Условие purchase, возврат на сайт, обработку события и фильтры
Заказ повторяется	Источники отправки, устойчивость ID и условия дедупликации
Разница составляет 800	Не сравниваются ли 2500 товаров и 3300 полной оплаты
После возврата цифры различаются	Передан ли refund в GA4 и предусмотрен ли отдельный учёт в Метрике
Сумма верна, товары неверны	Артикулы, количества и уровень товарной детализации

Не объявляйте совпадение с CMS до копейки универсальным требованием к браузерному сбору: часть посещений может не измеряться. Но каждое расхождение контрольного сценария должно иметь конкретное объяснение. Общая фраза «у аналитики всегда погрешность» не объясняет двойную покупку или неправильную валюту.

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

12. Зафиксируйте критерии приёмки

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

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

Для внешнего контроля HTTP-доступности магазина рассмотрите SiteGuard. Заказы, выручку и возвраты сверяйте отдельно с данными CMS и аналитики.