gtag purchase – событие покупки в GA4 для интернет-магазина

Интернет-магазин может получать заказы, но показывать в Google Analytics 4 нулевую выручку или неполные сведения о продажах. Обычно причина связана с настройкой события purchase: данные о покупке не отправляются, передаются с ошибками или несколько раз попадают в аналитику.

С помощью gtag purchase можно передать в GA4 номер заказа, стоимость товаров, валюту, количество проданных единиц и другие параметры транзакции. Эти сведения используются для анализа продаж, оценки рекламных кампаний и изучения поведения покупателей.

Разберём настройку purchase через gtag.js и Google Tag Manager, структуру передаваемых данных, способы проверки и ошибки, из-за которых показатели интернет-магазина расходятся с отчётами аналитики.

Что такое событие purchase в Google Analytics 4?

Событие purchase в Google Analytics 4 фиксирует покупку товара или услуги. Оно относится к рекомендованным событиям электронной торговли и используется для сбора информации о завершённых заказах. В отличие от автоматически собираемых событий, передачу покупок обычно нужно настроить самостоятельно или через интеграцию торговой платформы.

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

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

Какие данные о покупке собирает GA4?

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

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

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

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

Чем purchase отличается от других событий электронной торговли?

В электронной торговле GA4 используется несколько рекомендованных событий. Каждое соответствует определённому действию посетителя: от просмотра товара до оформления заказа и возврата денежных средств.

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

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

Когда должно срабатывать событие purchase?

Момент отправки purchase зависит от того, как интернет-магазин обрабатывает заказы. В одних магазинах покупка подтверждается сразу после успешной онлайн-оплаты, в других заказ оформляется до получения денежных средств.

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

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

Передача события после подтверждения заказа

Для интернет-магазина с онлайн-оплатой логично отправлять purchase после подтверждения успешного платежа. Источником информации должен быть проверенный статус транзакции, полученный от платёжной системы или серверной части магазина.

Нажатие кнопки «Оплатить» ещё не подтверждает получение денег. Покупатель может закрыть платёжную форму, получить отказ банка или прервать операцию до её завершения.

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

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

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

Отслеживание покупки на странице благодарности

Страница благодарности, или thank-you page, часто используется для передачи события покупки. После успешного оформления пользователь переходит на отдельный адрес, где видит номер заказа, его состав и подтверждение операции.

На этой странице сайт может сформировать объект с данными транзакции и отправить purchase. Такой способ удобен, если страница получает достоверную информацию о завершённом заказе и не показывает данные чужих транзакций.

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

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

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

Как избежать повторной отправки purchase при обновлении страницы?

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

Веб-потоки GA4 используют параметр transaction_id для дедупликации покупок с одинаковым идентификатором. Поэтому каждому заказу нужен собственный постоянный идентификатор, который не меняется при повторных посещениях.

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

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

Особенно опасен пустой идентификатор транзакции. В GA4 повторные покупки с transaction_id: «» могут восприниматься как дубли. В результате отчёты будут содержать меньше покупок, чем реально оформлено заказов.

Какие параметры нужны для события purchase?

Событие purchase содержит параметры двух уровней. Первый описывает заказ целиком: его номер, денежную стоимость, валюту, доставку и налоги. Второй содержит характеристики отдельных товаров внутри массива items.

Имена параметров должны соответствовать схеме Google Analytics 4. Произвольные названия вроде order_price, product_title или transaction_Id не заменяют стандартные поля value, item_name и transaction_id.

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

transaction_id необходим для корректной идентификации покупки. Для полноценного учёта дохода следует передавать value и соответствующую валюту currency, а сведения о товарах размещать в items.

Параметры транзакции

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

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

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

transaction_id – уникальный идентификатор покупки

Параметр transaction_id содержит идентификатор конкретной транзакции. Обычно для него используют номер заказа из CMS, ERP или другой системы, которая отвечает за оформление покупок.

Например, при заказе с номером ORDER-10452 в событие передаётся значение transaction_id: 'ORDER-10452'. При повторном открытии того же заказа идентификатор остаётся прежним.

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

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

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

value и currency – стоимость и валюта

Параметр value содержит денежную стоимость товаров, приобретённых в рамках транзакции. Согласно рекомендации Google, его рассчитывают как сумму произведений цены каждого товара на количество.

Если покупатель заказал один товар за 990 грн и два товара по 250 грн, значение составит 1490. Налог и доставка в этот расчёт не включаются, поскольку для них предусмотрены отдельные параметры.

В currency передаётся трёхбуквенный код валюты по ISO 4217. Для украинской гривны используется UAH, для доллара США – USD, для евро – EUR.

Корректная запись выглядит так:

value: 1490.00,
currency: 'UAH'

Число нельзя заменять строкой '1490 грн', поскольку такой формат не соответствует требуемому типу данных. Также не следует использовать запятую вместо десятичной точки внутри числового литерала JavaScript.

Для магазинов с несколькими валютами необходимо передавать валюту фактической операции и соответствующую ей стоимость. Нельзя отправлять сумму в гривнах с кодом USD, даже если основная валюта ресурса GA4 установлена в долларах.

tax, shipping и coupon – дополнительные параметры

Параметр tax предназначен для суммы налога по транзакции, а shipping содержит стоимость доставки. Оба значения передаются отдельно от value, чтобы Google Analytics могла корректно обрабатывать финансовые составляющие заказа.

Если доставка бесплатная, можно передать shipping: 0. Когда налог рассчитывается и учитывается отдельно, его значение также следует получить из реальных данных заказа.

Параметр coupon содержит название или код промокода, использованного при покупке. Например, при применении скидочного кода SALE10 интернет-магазин может передать coupon: 'SALE10'.

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

Купон уровня транзакции и купон отдельного товара – разные параметры. Если акция применяется только к конкретной позиции, сведения о ней можно разместить непосредственно внутри соответствующего элемента items.

Массив items и сведения о товарах

Массив items содержит перечень товаров, участвующих в покупке. Каждый элемент массива описывает одну товарную позицию с её идентификатором, названием, ценой и количеством.

Например, если покупатель заказал две одинаковые футболки, их можно представить одним объектом с quantity: 2. Если в заказе присутствуют товары с разными артикулами, каждый из них получает отдельный объект.

Такая структура используется в отчётах по товарам, категориям и другим характеристикам ассортимента. Без корректного items событие может содержать стоимость покупки, но сведения о проданных позициях будут отсутствовать.

item_id, item_name, price и quantity

item_id представляет идентификатор товара, обычно артикул или SKU. Желательно использовать стабильное значение из каталога, чтобы одна позиция не появлялась в аналитике под несколькими идентификаторами.

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

Параметр price указывает стоимость одной единицы товара, а quantity – количество приобретённых единиц. Для quantity используется числовой тип, поэтому запись quantity: 2 предпочтительнее строкового значения '2'.

Пример одного элемента массива:

{
  item_id: 'SKU-205',
  item_name: 'Товар Б',
  price: 250.00,
  quantity: 2
}

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

При наличии скидки нужно следить за согласованностью цены, количества и суммы заказа. Если цена товара уже уменьшена, нельзя повторно вычитать скидку при расчёте value.

Дополнительные характеристики товара

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

Например, item_brand может содержать производителя, item_category – категорию каталога, а item_variant – конкретный цвет или размер товара.

Для товара со скидкой можно передать discount, указав величину скидки на единицу товара. Значения price и discount должны быть согласованы с фактической стоимостью покупки.

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

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

Как настроить gtag purchase на сайте?

Прямая настройка gtag purchase подходит интернет-магазинам, в которых Google tag установлен через gtag.js, а разработчик может управлять отправкой событий в JavaScript.

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

Перед внедрением необходимо проверить, каким способом уже подключена аналитика. Если электронная торговля работает через GTM или готовый модуль CMS, дополнительный вызов gtag('event', 'purchase') может привести к повторным событиям.

Подготовка Google tag и идентификатора GA4

Для начала нужен ресурс Google Analytics 4 и веб-поток данных, связанный с интернет-магазином. В настройках потока находится идентификатор измерения, который обычно имеет формат G-XXXXXXXXXX.

Если Google tag ещё не установлен, его подключают по инструкции из GA4. Пример стандартной загрузки:

<script async src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXXXXX"></script>
<script>
  window.dataLayer = window.dataLayer || [];

  function gtag() {
    dataLayer.push(arguments);
  }

  gtag('js', new Date());
  gtag('config', 'G-XXXXXXXXXX');
</script>

Здесь G-XXXXXXXXXX необходимо заменить реальным идентификатором веб-потока. Такой код настраивает Google tag, но сам по себе ещё не отправляет сведения о покупках.

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

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

Пример кода gtag('event', 'purchase')

После установки Google tag можно отправить событие покупки с помощью команды gtag('event', 'purchase', {...}). Второй аргумент содержит стандартное название события, а третий – объект с параметрами транзакции.

Рассмотрим заказ, в котором покупатель приобрёл один товар за 990 грн и два товара по 250 грн. Стоимость товаров составляет 1490 грн, а доставка оплачивается отдельно.

gtag('event', 'purchase', {
  transaction_id: 'ORDER-10452',
  value: 1490.00,
  currency: 'UAH',
  shipping: 80.00,
  items: [
    {
      item_id: 'SKU-101',
      item_name: 'Товар А',
      price: 990.00,
      quantity: 1
    },
    {
      item_id: 'SKU-205',
      item_name: 'Товар Б',
      price: 250.00,
      quantity: 2
    }
  ]
});

В этом примере transaction_id содержит номер покупки, value – стоимость товаров, currency – валюту операции. Массив items передаёт две товарные позиции, одна из которых приобретена в количестве двух единиц.

Стоимость доставки 80 грн указана отдельно и не добавлена к value. Благодаря этому финансовые параметры соответствуют стандартной структуре события покупки.

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

Как подставлять реальные данные заказа?

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

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

Например, сервер может подготовить JSON с номером заказа, валютой и списком приобретённых позиций. Клиентская часть получает эти сведения и передаёт их в gtag() после проверки необходимого статуса.

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

Не следует передавать в обычные параметры GA4 имя покупателя, электронную почту, номер телефона или адрес доставки. Информация о заказе должна ограничиваться допустимыми аналитическими данными.

Как реализовать отправку purchase после оплаты?

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

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

Пример логики для клиентской отправки события выглядит следующим образом:

1. Покупатель завершает оформление заказа и переходит к оплате.
2. Платёжная система подтверждает результат серверной части магазина.
3. Сервер обновляет статус заказа и сохраняет сведения о транзакции.
4. Клиентская часть получает проверенный статус и данные покупки.
5. Приложение отправляет purchase, если выбранные условия выполнены.

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

Не стоит запускать purchase при каждом изменении состояния компонента или повторном выполнении обработчика. Условия отправки должны быть привязаны к конкретной транзакции и учитывать возможность повторного открытия заказа.

Настройка события purchase через Google Tag Manager

Google Tag Manager позволяет управлять передачей событий без размещения отдельного вызова gtag.js для каждой аналитической операции в коде страницы. Сайт передаёт данные в dataLayer, а GTM использует их для запуска тега GA4.

Такой вариант удобен, если в интернет-магазине уже установлены теги Google Analytics и рекламных систем через контейнер GTM. Разработчик отвечает за корректные данные заказа, а специалист по аналитике настраивает их отправку в интерфейсе менеджера тегов.

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

Передача данных покупки через dataLayer.push()

dataLayer представляет собой уровень данных, через который сайт передаёт информацию в Google Tag Manager. Для электронной торговли GA4 принято использовать объект ecommerce, содержащий сведения о транзакции и товарах.

Перед новым ecommerce-событием рекомендуется очищать предыдущий объект, чтобы параметры прошлых действий не смешивались с текущей покупкой.

window.dataLayer = window.dataLayer || [];

dataLayer.push({ ecommerce: null });

dataLayer.push({
  event: 'purchase',
  ecommerce: {
    transaction_id: 'ORDER-10452',
    value: 1490.00,
    currency: 'UAH',
    shipping: 80.00,
    items: [
      {
        item_id: 'SKU-101',
        item_name: 'Товар А',
        price: 990.00,
        quantity: 1
      },
      {
        item_id: 'SKU-205',
        item_name: 'Товар Б',
        price: 250.00,
        quantity: 2
      }
    ]
  }
});

Первый вызов сбрасывает предыдущие данные электронной торговли. Второй добавляет событие purchase с параметрами заказа, которые затем считываются тегом Google Analytics.

В этой схеме event определяет название события GTM, а ecommerce содержит данные покупки. Такая вложенность отличается от прямого вызова gtag(), где параметры передаются непосредственно в объекте события.

Нельзя использовать переменные с названиями eсommerce или transaction_Id, ошибочно заменяя символы или изменяя регистр. Для JavaScript и GTM такие названия могут оказаться совершенно другими полями.

Создание триггера Custom Event в GTM

После передачи данных в Data Layer нужно настроить триггер, который будет реагировать на событие покупки. В Google Tag Manager для этого применяется тип Custom Event, или «Специальное событие».

Откройте раздел «Триггеры», создайте новый триггер и выберите соответствующий тип. В поле имени события укажите purchase точно так же, как оно записано в dataLayer.push().

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

После сохранения триггера проверьте его в режиме предварительного просмотра. При совершении тестовой покупки в списке событий GTM должен появиться purchase, а внутри объекта Data Layer – данные соответствующей транзакции.

Если событие отсутствует, необходимо проверить выполнение JavaScript и момент вызова dataLayer.push(). Создание триггера само по себе не формирует сведения о покупке и не добавляет их на сайт.

Настройка тега GA4 Event

Для отправки события в Google Analytics 4 создайте новый тег типа Google Analytics: GA4 Event. Укажите используемый Google tag и задайте точное имя события purchase.

Затем привяжите созданный триггер Custom Event. Когда GTM получит событие purchase из уровня данных, он сможет выполнить тег и отправить параметры в выбранный ресурс GA4.

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

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

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

Send Ecommerce data и переменные Data Layer

В настройках тега GA4 Event можно включить опцию Send Ecommerce data и выбрать Data Layer в качестве источника. В этом случае GTM использует сведения электронной торговли из стандартного объекта ecommerce.

Другой вариант – самостоятельно создать переменные уровня данных и сопоставить их с параметрами GA4. Например, переменная ecommerce.transaction_id передаёт номер заказа, а ecommerce.items – массив товаров.

Для ручного сопоставления используются соответствующие имена параметров события:

Эти способы следует рассматривать как альтернативные варианты настройки. Не нужно одновременно использовать автоматическое считывание одних и тех же ecommerce-параметров и их повторное ручное сопоставление без технической необходимости.

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

Как проверить событие purchase в GA4?

Правильная настройка электронной торговли требует проверки нескольких этапов передачи данных. Сначала необходимо убедиться, что интернет-магазин формирует событие, затем проверить его отправку и получение Google Analytics.

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

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

Проверка события через Tag Assistant

Google Tag Assistant помогает проверить подключение Google tag и передачу событий. Если сайт использует GTM, предварительный просмотр дополнительно показывает работу триггеров и тегов.

Откройте Tag Assistant, подключитесь к интернет-магазину и выполните тестовую покупку. В интерфейсе отладки найдите событие purchase и проверьте, какие действия выполнились после его появления.

Особое внимание уделите следующим данным:

• Тег GA4 отправляется в нужный ресурс, а его идентификатор соответствует веб-потоку магазина.
• Триггер purchase срабатывает после подтверждения покупки, а не во время обычного просмотра страницы.
• Значение transaction_id совпадает с номером тестового заказа, созданного в CMS.
• Параметры value, currency и items содержат ожидаемые значения и правильные типы данных.
• Один заказ не запускает несколько независимых тегов с одинаковым событием покупки.

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

Tag Assistant также помогает находить ошибки Consent Mode. Неправильное состояние согласия может влиять на загрузку тегов и сбор аналитических данных.

Проверка покупки в GA4 DebugView

DebugView показывает события, полученные Google Analytics в режиме отладки. Для проверки откройте настройки ресурса GA4, перейдите в DebugView и выберите устройство, с которого выполняется тест.

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

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

Некоторые сведения электронной торговли, особенно параметры массива товаров, удобнее дополнительно проверять в Tag Assistant и сетевых запросах браузера. Интерфейс DebugView не всегда показывает структуру items в виде привычного JavaScript-массива.

При диагностике полезно сравнивать три источника: объект заказа на сайте, отправленный запрос и данные, отображаемые аналитикой. Такой подход помогает определить, на каком этапе возникла ошибка.

Проверка массива товаров и финансовых параметров

Для начала сравните значение value с суммой стоимости всех товаров в заказе. Если товар стоимостью 250 грн куплен в количестве двух единиц, его вклад в общую сумму составляет 500 грн.

Затем проверьте количество объектов внутри items. Если заказ содержит несколько разных товаров, каждый должен присутствовать в массиве с правильным идентификатором и количеством.

Особое внимание уделите типам данных и структуре вложенности. Вместо массива объектов иногда передаётся строка JSON или массив, внутри которого находится ещё один массив.

Даже если браузер не показывает ошибок JavaScript, Google Analytics может получить неполные параметры. Поэтому проверять нужно именно структуру фактически отправленных данных, а не только факт выполнения тега.

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

Где посмотреть покупки и доход в отчётах GA4?

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

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

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

Для оперативной проверки лучше использовать Tag Assistant, DebugView и доступные отчёты реального времени. При обычной обработке данных GA4 некоторые показатели могут обновляться в течение следующих суток и дольше.

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

Ведущий SEO-специалист — Геннадий

Я не считаю настройку purchase завершённой только потому, что событие появилось в GA4. Обязательно проверяю, передались ли идентификатор заказа, валюта, сумма и состав товаров. Затем сравниваю данные тестовой покупки с заказом в интернет-магазине. Если событие есть, но сумма равна нулю или товары отсутствуют, аналитика продаж настроена неправильно. Такая ошибка особенно опасна при оценке эффективности рекламы: можно видеть количество покупок, но принимать решения на основе некорректной выручки.

Почему purchase не работает или передаёт неправильные данные?

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

Причины различаются в зависимости от способа внедрения. При прямой настройке gtag.js ошибки чаще связаны с JavaScript и условиями отправки. При использовании GTM дополнительно нужно проверять триггеры, переменные и настройки передачи электронной торговли.

Начинать диагностику лучше с одного конкретного заказа. Если известны его идентификатор, состав, сумма и время оформления, определить источник ошибки значительно проще.

Событие purchase есть, но нет суммы или товаров

Такая ситуация возникает, когда тег отправляет само событие purchase, но не передаёт необходимые параметры. Например, в GTM может быть создан GA4 Event с правильным названием, однако объект ecommerce не считывается.

Для проверки откройте Tag Assistant и найдите данные транзакции. Убедитесь, что value содержит числовое значение, currency соответствует валюте операции, а items передаётся как массив объектов.

Если параметры отсутствуют в исходном Data Layer, проблему нужно исправлять на стороне интернет-магазина. Если значения присутствуют в Data Layer, но не попадают в запрос GA4, проверьте конфигурацию тега.

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

После исправления выполните новую тестовую покупку. Не используйте старый идентификатор заказа, поскольку дедупликация транзакций может усложнить проверку результата.

В отчётах отображается (not set)

Значение (not set) в GA4 обычно означает, что для выбранного измерения не удалось определить соответствующие данные. В электронной торговле такая ситуация может возникнуть, если событие передано без названия товара или с неправильной структурой параметров.

Например, item_name может отсутствовать внутри элементов items, хотя название товара хранится в другом поле сайта. Для GA4 пользовательское название этого поля не заменяет стандартный параметр.

Проверьте, что массив содержит объекты товаров, а параметры item_id, item_name, price и quantity размещены внутри соответствующих объектов.

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

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

Ошибка двойной вложенности массива items

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

Неправильный вариант:

items: [
  [
    {
      item_id: 'SKU-101',
      item_name: 'Товар А',
      price: 990.00,
      quantity: 1
    }
  ]
]

Правильный вариант:

items: [
  {
    item_id: 'SKU-101',
    item_name: 'Товар А',
    price: 990.00,
    quantity: 1
  }
]

В первом случае элементом массива становится ещё один массив. GA4 ожидает массив объектов товаров, поэтому такая вложенность может нарушить обработку сведений о покупках.

Подобная ошибка встречается при сборке массива несколькими JavaScript-функциями. Например, одна функция уже возвращает список товаров, а другая дополнительно оборачивает результат в квадратные скобки.

Для проверки достаточно открыть исходный объект в консоли браузера и посмотреть его структуру. Каждый элемент items должен быть объектом конкретной товарной позиции.

Покупки дублируются в Google Analytics 4

Повторный учёт покупок может возникать при одновременной отправке события через gtag.js, GTM и готовую интеграцию интернет-магазина. В результате одна транзакция запускает несколько независимых механизмов передачи.

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

В веб-потоках Google Analytics 4 использует transaction_id для дедупликации покупок с одинаковым идентификатором. Но если один и тот же заказ каждый раз получает новый номер, система может воспринимать события как разные транзакции.

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

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

purchase не появляется в DebugView

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

Затем проверьте, подключён ли Google tag к правильному веб-потоку. Ошибка в Measurement ID приводит к отправке данных в другой ресурс или к отсутствию ожидаемого результата.

Также следует проверить выполнение JavaScript, наличие ошибок в консоли и работу блокировщиков аналитики. Некоторые расширения браузера препятствуют загрузке тегов или отправке запросов.

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

Отдельно нужно проверить настройки согласия на обработку аналитических данных. В зависимости от конфигурации Consent Mode и выбранного режима работы тегов отказ пользователя может ограничивать сбор информации.

Выручка GA4 не совпадает с данными интернет-магазина

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

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

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

На расхождения также влияют:

• Разные часовые пояса отчётов GA4 и системы управления заказами.
• Применение скидок после предварительного расчёта стоимости корзины.
• Передача неверной валюты или суммы, рассчитанной до изменения заказа.
• Блокировка аналитики браузером либо ограничения, связанные с согласием.
• Отсутствие корректной обработки возвратов и отменённых покупок.
• Задержка обработки данных в стандартных отчётах Google Analytics.

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

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

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

Как учитывать возвраты и отмены заказов?

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

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

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

Событие refund в GA4

Для возвратов Google Analytics 4 использует рекомендованное событие refund. Оно связывается с исходной покупкой через transaction_id, что помогает учитывать изменение финансового результата.

Пример полного возврата стоимости товаров:

gtag('event', 'refund', {
  transaction_id: 'ORDER-10452',
  currency: 'UAH',
  value: 1490.00
});

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

Пример частичного возврата:

gtag('event', 'refund', {
  transaction_id: 'ORDER-10452',
  currency: 'UAH',
  value: 250.00,
  items: [
    {
      item_id: 'SKU-205',
      item_name: 'Товар Б',
      price: 250.00,
      quantity: 1
    }
  ]
});

В этом случае покупателю возвращается стоимость одной единицы товара. Сумма возврата соответствует позиции, указанной внутри items.

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

Когда нужна серверная передача purchase?

Клиентская отправка через браузер подходит многим интернет-магазинам, но её результат зависит от выполнения JavaScript и доступности страницы. Если покупатель закрывает вкладку до завершения передачи, событие может не попасть в аналитику.

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

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

Measurement Protocol и серверные события GA4

Google Analytics Measurement Protocol позволяет передавать события на серверы аналитики через HTTP-запросы. Для веб-потока используется endpoint /mp/collect, а в запросе указываются идентификатор измерения и секрет API.

В теле запроса передаются идентификатор клиента и массив событий. Для покупки необходимо сформировать purchase со стандартными параметрами транзакции.

Упрощённый пример структуры JSON:

{
  "client_id": "1234567890.1234567890",
  "events": [
    {
      "name": "purchase",
      "params": {
        "transaction_id": "ORDER-10452",
        "value": 1490.00,
        "currency": "UAH",
        "items": [
          {
            "item_id": "SKU-101",
            "item_name": "Товар А",
            "price": 990.00,
            "quantity": 1
          },
          {
            "item_id": "SKU-205",
            "item_name": "Товар Б",
            "price": 250.00,
            "quantity": 2
          }
        ]
      }
    }
  ]
}

Здесь показано только тело запроса, без полного кода серверной отправки. Для реальной реализации необходимы корректные идентификаторы, настройки Measurement Protocol и проверка соблюдения требований Google.

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

Для связи серверной покупки с браузерным посещением необходимо корректно получать и сохранять client_id. При необходимости используются сведения о сеансе, включая session_id, с учётом требований Measurement Protocol.

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

Как избежать дублирования браузерных и серверных покупок?

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

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

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

Нельзя рассчитывать, что произвольный event_id автоматически устранит все повторные покупки. Для стандартного события purchase главным идентификатором дедупликации в веб-потоке остаётся transaction_id.

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

Чек-лист правильной настройки purchase

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

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

Для проверки используйте следующий список:

1. Google tag подключён к нужному ресурсу. Идентификатор веб-потока соответствует интернет-магазину, а лишние конфигурации отсутствуют.
2. Событие отправляется в правильный момент. Статус заказа соответствует принятому правилу регистрации покупки.
3. transaction_id содержит уникальный номер. Значение не пустое и сохраняется при повторном открытии заказа.
4. value рассчитывается корректно. Сумма учитывает фактические цены и количество товаров без добавления налога и доставки.
5. currency соответствует операции. Используется действительный трёхбуквенный код валюты.
6. Массив items содержит приобретённые позиции. Для товаров передаются идентификаторы, названия, цены и количество.
7. Числовые параметры имеют правильный тип. Стоимость и количество не передаются как текст с символами валюты.
8. Отсутствуют лишние отправки. Одна покупка не запускает несколько независимых интеграций без согласованной дедупликации.
9. Tag Assistant подтверждает работу тегов. Нужный триггер срабатывает, а параметры поступают из правильного источника.
10. Событие проверено в DebugView. Тестовая транзакция поступает в нужный ресурс GA4.
11. Возвраты обрабатываются отдельно. При необходимости используется событие refund с исходным идентификатором транзакции.
12. Настройки приватности проверены. Сбор данных учитывает согласие пользователя и ограничения Google Analytics.

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

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

Правильно настроенное событие purchase помогает видеть реальные результаты продаж в Google Analytics 4 и сравнивать их с данными интернет-магазина. Для этого нужно согласовать момент отправки, передавать корректные параметры и регулярно проверять события после изменений сайта.

Если в GA4 отсутствует выручка, теряются товары или дублируются транзакции, специалисты Seo-Gen помогут проверить настройку электронной торговли, найти ошибки в gtag.js или GTM и наладить передачу данных о покупках.