Події електронної торгівлі

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

Простими словами

Без цих подій аналітика бачить відкриті сторінки, але не розуміє, що на них відбувається. З ними видно, скільки людей дивилися товар, скільки поклали в кошик і скільки оплатили. У GA4 Google описує рекомендований набір подій; якщо дотримуватися його назв, стандартні звіти й воронки працюватимуть без додаткового налаштування.

Рекомендований набір подій GA4

За порядком шляху покупця (документація Google):

Для акцій є `view_promotion` і `select_promotion`.

Що обов'язково передавати

За документацією Google:

• у `purchase` і `refund` — `transaction_id` (унікальний номер замовлення);
• у подіях із сумою — `currency` разом із `value`;
• у `purchase` значення `value` має дорівнювати сумі «ціна × кількість» за всіма товарами;
• кожен товар у масиві `items` повинен мати `item_id` або `item_name` (Google радить обидва); якщо кількість не вказано, береться 1;
• в `items` може бути до 200 елементів;
• передавайте всі параметри, дані яких у вас є.

Старі назви `ecommerce_purchase` і `ecommerce_refund` замінено на `purchase` і `refund`.

Приклад (умовні цифри)

Покупець купив чайник за 1 800 грн і два фільтри по 250 грн. Правильна подія `purchase`: `currency = UAH`, `value = 2 300`, `transaction_id = «A-10452»`, у `items` — два рядки (чайник кількістю 1, фільтр кількістю 2). Якщо `value` вказати 1 800, дохід у звітах буде заниженим, а якщо подію надіслати двічі з тим самим номером замовлення, завищеним.

Як перевірити дані

1. Увімкніть DebugView. Він показує події в реальному часі, але потребує режиму налагодження (Tag Assistant або параметр `debug_mode`). Якщо користувач не дав згоди на аналітичні cookie, події не з'являться (довідка Google Analytics).
2. Пройдіть шлях покупця вручну на телефоні й комп'ютері і порівняйте послідовність подій із таблицею вище.
3. Зробіть тестове замовлення і звірте номер, суму, валюту й товари з вашою обліковою системою.
4. Через кілька днів порівняйте кількість покупок і дохід у GA4 з CRM. Невелика розбіжність нормальна (відмови від cookie, скасування); велика — привід шукати помилку.
5. Після кожного оновлення шаблону сайту повторюйте швидку перевірку: події ламаються саме тоді.

Для стандартних звітів кількість параметрів і подій обмежена; для важливих подій назва має бути не довшою за 40 символів (довідка Google Analytics).

Типові помилки

• Дубль `purchase` при оновленні сторінки подяки.
• Відсутня валюта або `value` без урахування кількості.
• Події надсилаються до того, як користувач дав згоду, або не надсилаються взагалі через банер.
• Різні назви подій на різних сторінках (`add_to_cart` і `addToCart`).
• Немає `refund`: повернення не віднімаються від доходу.

FAQ

Які події обов'язкові для магазину? Мінімум: `view_item`, `add_to_cart`, `begin_checkout`, `purchase`. Решта додає деталізацію воронки.

Як перевірити, що `purchase` не дублюється? Зробіть тестове замовлення, оновіть сторінку подяки й подивіться в DebugView, чи з'явилася друга подія з тим самим `transaction_id`.

Чи можна надсилати події з сервера? Так, див. Серверне відстеження.

Пов'язані терміни

• GA4 для магазину
• Аналіз воронки
• Серверна аналітика (server-side tracking)
• Google Consent Mode v2
• Мікроконверсії: що це і навіщо їх рахувати

Джерела

• Google, Measure ecommerce (GA4) — developers.google.com/analytics/devguides/collection/ga4/ecommerce
• Google Analytics Help, DebugView — support.google.com/analytics/answer/7201382
• Google Analytics Help, Event collection limits — support.google.com/analytics/answer/9267744