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 ще не встановлений, його підключають за інструкцією з 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(), де параметри передаються безпосередньо в об'єкті події.

Не можна використовувати змінні з назвами ecommerce або 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 до правильного вебпотоку. Помилка 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 і налагодити передачу даних про покупки.