Замовлення є, а GA4 їх не бачить? Вимірювання продажів у PrestaShop

Замовлення є в PrestaShop, оплату прийнято, а Google Analytics 4 не показує покупку. Перш ніж визнати кампанію неефективною, перевірте, чи магазин передає до GA4 правильні події і коли саме це робить. Самого коду відстеження на сторінці недостатньо для вимірювання продажів. Значення мають також спосіб завершення замовлення, ідентифікатори транзакцій, згоди клієнта та суми, що надсилаються до звітів.

Чому в GA4 видно відвідування, але не видно продажів?

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

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

Що вимірювати між входом на товар і покупкою?

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

Такі події передбачені документацією e-commerce GA4 і підтримуються Google Analytics 4 Pro. Звіт або дослідження шляху ви готуєте в Google Analytics. Велике падіння між етапами є підказкою для перевірки магазину: воно може бути наслідком як поведінки клієнтів, так і відсутньої події в нестандартному checkout.

Клієнт не повернувся з оплати. Чи потрапить покупка до GA4?

Якщо вимірювання запускається лише на сторінці підтвердження, клієнт має її відкрити. Закриття вкладки після оплати може перервати цей сценарій, навіть якщо замовлення існує в магазині. Тому спосіб надсилання покупки потрібно адаптувати до реального перебігу оплати.

Google Analytics 4 Pro для PrestaShop надає три режими:

1. Сторінка підтвердження замовлення. Подія готується після переходу клієнта на підтвердження. За налаштованого API Secret модуль може додатково надіслати покупку із сервера.
2. Зміна статусу замовлення. Модуль надсилає покупку через Measurement Protocol після переходу на один із вибраних статусів. Цей механізм не вимагає повторного відкриття сторінки клієнтом; він потребує налаштування API та раніше збереженого ідентифікатора клієнта GA4.
3. Натискання кнопки підтвердження замовлення. Це варіант, залежний від роботи форми покупки. Саме натискання не підтверджує отримання грошей, тому потрібно також перевірити сценарій невдалої оплати.

Якщо ви хочете вимірювати оплачені замовлення, виберіть статуси, що відповідають прийняттю оплати. Для післяплати встановіть окреме правило: прийняття замовлення і подальше погашення заборгованості — це різні моменти.

Чи вирішує Measurement Protocol проблему adblock-ів?

Measurement Protocol дає змогу надсилати події із сервера магазину безпосередньо до Google Analytics. Він може зменшити залежність вимірювання покупки від скрипта в браузері. Google представляє його як доповнення до стандартного збору даних.

У Google Analytics 4 Pro серверне надсилання також вимагає ідентифікатора client_id, збереженого при замовленні. Модуль отримує його з cookie _ga. Якщо такого ідентифікатора немає, код пропускає надсилання через API. Додатково резервне надсилання в режимі сторінки підтвердження все одно вимагає відкриття цієї сторінки. Тому для проблеми з відсутністю повернення з оплати значення має режим зміни статусу. Жоден із цих механізмів не дає підстав обіцяти вимірювання кожного замовлення.

Чому сума в GA4 відрізняється від суми замовлення?

Перевірте, що саме ви порівнюєте. Згідно зі специфікацією події purchase, параметр value має відповідати сумі цін товарів, помножених на їх кількість, без податку і доставки. Поля tax і shipping є окремими. Під час передавання значень також потрібна валюта, наприклад PLN.

Приклад: два товари по 100 zł нетто дають value = 200. Сума, сплачена клієнтом, буде вищою, якщо додано ПДВ і доставку. Порівняння цих 200 zł з повною сумою брутто замовлення саме по собі не доводить втрати доходу.

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

Звідки беруться подвійні покупки і невраховані повернення?

Перевірте, чи purchase не надсилають одночасно модуль, Google Tag Manager і додатковий код у темі. GA4 для вебпотоку використовує transaction_id, щоб усувати повтори покупок того самого користувача. Кожна транзакція повинна мати власний, непорожній ідентифікатор, збережений при повторному надсиланні тієї самої покупки.

У режимі підтвердження та серверного надсилання Google Analytics 4 Pro використовує референс замовлення як transaction_id. Попри це, після поєднання кількох інтеграцій перевірте фактичні події: інші ідентифікатори тієї самої покупки можуть спотворити результат.

Модуль також підтримує refund після зміни замовлення на вибраний статус повернення. Це надсилання вимагає API Secret і збереженого client_id та охоплює повну вартість і позиції замовлення. У разі часткового повернення, наприклад однієї з трьох одиниць, потрібна окрема обробка правильних сум і кількостей. Призначення статусу повернення в цьому модулі не розраховує автоматично будь-яке часткове коригування.

Що зі згодами і Consent Mode v2?

Consent Mode передає тегам Google інформацію про згоди користувача. Він потребує взаємодії з банером або іншим механізмом збору рішень. Документація Google розрізняє базовий і розширений режими, у яких надсилання даних до згоди та після відмови працює по-різному.

Модуль GA4 не замінює налаштування згод. У його інтеграції з PD Cookie Pro реалізовано підтримку рекламних сигналів ad_user_data і ad_personalization для серверного надсилання. Однак поведінку всього вимірювання потрібно перевірити з банером, що працює в конкретному магазині. Увімкнення API Secret не означає згоди користувача на аналітику або рекламу.

Як перевірити вимірювання на одному замовленні?

1. Перевірте місце призначення даних. Ідентифікатор G-… у модулі має відповідати вебпотоку, який ви переглядаєте в GA4. Також визначте, які інші інтеграції надсилають події.
2. Пройдіть шлях покупки. Відкрийте товар, додайте його до кошика і почніть оформлення замовлення. Модуль має режим налагодження подій браузера; параметри можна переглядати в DebugView. Перевірку проводьте за наданої згоди на аналітику, а поведінку після відмови перевірте окремо.
3. Перевірте покупку. Порівняйте transaction_id, value, currency і items із замовленням. Врахуйте товари з варіантом і знижкою.
4. Перевірте вибраний момент надсилання. У режимі статусу змініть його на налаштований статус покупки. Окремо пройдіть оплату без повернення до магазину і невдалу оплату.
5. Перевірте повторення і повернення. Оновіть підтвердження, проконтролюйте кількість транзакцій і перевірте повне повернення. Результат серверних подій підтвердьте окремо в GA4: перемикач налагодження в модулі стосується тега в браузері.

Стандартним звітам потрібен час на обробку даних. Google зазначає, що це може тривати 24–48 годин. Відсутність покупки у звіті одразу після тесту ще не свідчить про помилку.

GA4 у PrestaShop: часті запитання

Чи обов’язковий Google Tag Manager?

Ні. Google Analytics 4 Pro завантажує тег Google і надсилає події через gtag.js. Якщо магазин уже використовує GTM, визначте межі обох впроваджень, щоб вони не надсилали ті самі покупки незалежно одне від одного.

Чи всі замовлення мають збігатися один до одного?

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

З чого почати, якщо звіти порожні?

З перевірки ідентифікатора GA4 і однієї покупки. Визначте, чи подія створюється, чи містить товари та значення і чи потрапляє до правильного потоку. Лише потім порівнюйте зведені звіти кампаній.

Google Analytics 4 Pro дає змогу впровадити події e-commerce у PrestaShop і підібрати спосіб реєстрації покупок відповідно до роботи магазину. Почніть із цієї конфігурації та однієї перевіреної транзакції: тоді буде легше визначити, чи низький результат кампанії пов’язаний із продажами, чи з прогалинами у вимірюванні.