Версія 1.4.2 потребує щонайменше PHP 7.2.5 через включені HTTP-бібліотеки; версія PHP також має відповідати вимогам вашої версії PrestaShop. Серверні покупки та повернення додатково потребують активного PD Cookie Pro у режимі live з Consent Mode v2, відповідної ревізії згоди, аналітичної згоди та збережених даних атрибуції клієнта й сеансу. Самого API Secret недостатньо.
Серверне purchase не надсилається для замовлень із платним подарунковим пакуванням, понад 200 товарними рядками або відсутнім артикулом/EAN, якщо вибрано такий формат item_id. Документи коригування мають містити узгоджені суми й позиції; записи з partial != 0 і типи ваучерів відхиляються. Тип 2 підтримується лише для однозначного повернення самої вартості доставки. Часткове повернення кількості товарів не є тим самим, що технічний прапорець partial.
Найважливіші характеристики та функціональність
- 15 іменованих подій e-commerce та облікового запису:
view_item, view_item_list, select_item, add_to_cart, remove_from_cart, view_cart, begin_checkout, add_shipping_info, add_payment_info, purchase, refund, search, view_search_results, sign_up і login.
- Необов’язковий
page_view: адміністратор може залишити автоматичне вимірювання переглядів сторінок у модулі або вимкнути його, якщо обробку переглядів виконує Google Tag Manager чи інше рішення.
- Покупка після налаштованого статусу: версія 1.4.2 надсилає purchase із сервера після запису в історію замовлення статусу, обраного адміністратором як підтвердження оплати, та виконання інших умов. Модуль самостійно не перевіряє розрахунок у платіжного провайдера.
- Measurement Protocol для фінансових операцій: для надсилання
purchase і refund потрібні: основний Measurement ID, API Secret, збережені дані атрибуції/сесії та актуальна аналітична згода.
- Контрольовані повернення: модуль підтримує повне повернення за вибраним статусом, а також нові коригування PrestaShop, включно з частковими коригуваннями, лише якщо раніше було зареєстровано кваліфіковану покупку.
- Журнал фінансових подій: постійний реєстр і блокування для замовлення контролюють власні покупки й повернення модуля; адміністративна панель має перегляд лише для читання з фільтрами, сортуванням і розбиттям на сторінки. Це не усуває дублікати подій, незалежно надісланих через GTM або інші модулі.
- Два ідентифікатори Measurement ID: можна налаштувати основний і додатковий другий ідентифікатор GA4 для подій, що надсилаються з тега в браузері.
- П’ять способів побудови
item_id: ID товару, ID товару з ID комбінації, розділені дефісом, ID товару з ID комбінації, розділені підкресленням, артикул або EAN.
- Каталожні дані в подіях: модуль передає, зокрема, ідентифікатор, назву, варіант, бренд, категорії, ціну, знижку, кількість, валюту та дані списку товарів, якщо вони доступні в PrestaShop.
- Купони знижок: підтримувані події браузера можуть містити назву й код застосованого правила кошика. У версії 1.4.2 серверне purchase, надіслане через Measurement Protocol, не містить кодів купонів.
- User ID для авторизованого клієнта: після ввімкнення опції модуль передає технічний ідентифікатор клієнта до GA4 за наявності згоди
analytics_storage; це не замінює контактні дані.
- Дані, що передаються користувачем: після ввімкнення опції та за наявності актуальної згоди
ad_user_data модуль може передати e-mail і доступний телефон або адресу у форматі, який вимагає Google; ідентифікаційні дані нормалізуються та хешуються за SHA-256.
- Динамічний ремаркетинг Google Ads: після ввімкнення функції та вказання ідентифікатора Google Ads тег отримує ідентифікатори товарів, тип сторінки та вартість кошика.
- DebugView і діагностика: режим налагодження записує події браузера в консоль і встановлює для них прапорець debug_mode для GA4 DebugView. Він не встановлює цей прапорець для серверних purchase і refund. Панель показує стан конфігурації та останню покупку з відповіддю HTTP 2xx; фінансові події потрібно перевіряти в журналі й звітах GA4.
- PrestaShop 1.7.x, 8.x і 9.x: це діапазон, заявлений версією 1.4.2, а не гарантія для кожної версії PHP, теми чи checkout. Код містить шляхи стандартного checkout і вибраних модулів one-page checkout; потрібно перевірити фактичний процес замовлення у вашому магазині.
Які етапи продажу вимірює модуль GA4 для PrestaShop?
| Етап у магазині |
Події, що передаються модулем |
Обсяг даних |
| Списки та картка товару |
view_item_list, select_item, view_item |
Товар, варіант, бренд, категорії, ціна, знижка та позиція у списку. |
| Кошик |
add_to_cart, remove_from_cart, view_cart |
Позиції кошика, кількості, значення, валюта та доступний купон. |
| Checkout |
begin_checkout, add_shipping_info, add_payment_info |
Склад кошика та інформація, що вибирається під час процесу оформлення замовлення. |
| Покупка та повернення |
purchase, refund |
Серверний snapshot кваліфікованої транзакції або повернення, що надсилається через Measurement Protocol. |
| Пошук і обліковий запис |
search, view_search_results, sign_up, login |
Пошуковий запит, результати пошуку або подія створення облікового запису та входу. |
Вимірювання покупок і повернень через Measurement Protocol
У поточному фінансовому режимі модуль не вважає натискання кнопки або саму сторінку підтвердження доказом оплати. Подія purchase створюється після збереження в історії замовлення одного з вибраних статусів оплати. Для повернення модуль спочатку перевіряє, чи для цього замовлення існує попередня покупка, записана як надіслана в журналі; далі враховується лише залишкова, неповернена сума. Повне повернення може запускатися вибраним статусом, а нові коригування PrestaShop обробляються незалежно, також частково.
Стан sent у журналі означає відповідь HTTP 2xx, тобто прийняття запиту endpoint’ом Measurement Protocol. Це не є підтвердженням того, що подію вже оброблено або показано у звітах Google Analytics. Модуль не відтворює історичні покупки чи повернення після оновлення та не має автоматичної черги, CRON або кнопки примусового повторення сумнівного надсилання.
GA4, Google Ads, згоди та дані користувача
Модуль може ініціювати тег GA4 для одного або двох Measurement ID. Для динамічного ремаркетингу Google Ads додатково потрібен ідентифікатор у форматі AW-…. У поточному режимі покупки за статусом оплати події purchase і refund надходять до GA4 через Measurement Protocol; у цьому режимі модуль не надсилає пряму браузерну конверсію покупки до Google Ads.
Опція даних, що передаються користувачем, вимагає активного PD Cookie Pro з Consent Mode v2 і поточної згоди ad_user_data. Додатково власник магазину повинен увімкнути збір таких даних у сервісі GA4 та в налаштуваннях тега Google; налаштування розширених конверсій у Google Ads є окремим завданням на стороні облікового запису Google. Відкликання згоди видаляє ідентифікаційні дані з конфігурації тега, а серверне надсилання фінансових операцій повторно перевіряє актуальну згоду перед надсиланням. User ID і дані від користувача також потребують активного PD Cookie Pro у режимі live, Consent Mode v2 й актуальної ревізії згоди. Відкликання analytics_storage обнуляє User ID у тегу; відкликання ad_user_data обнуляє user_data. Це не видаляє дані, вже передані Google.
Налаштування та перевірка впровадження
- Введіть основний Measurement ID GA4, а другий ідентифікатор — лише за потреби.
- Для покупок і повернень вкажіть API Secret Measurement Protocol і виберіть статуси, які справді підтверджують оплату та повне повернення замовлення в цьому магазині.
- Підберіть формат
item_id до ідентифікатора, що використовується в каталозі або товарному фіді.
- Увімкніть лише потрібні функції Google Ads, User ID і даних, що передаються користувачем, після перевірки налаштувань і згод в інструментах Google.
- Для тесту використовуйте режим налагодження та GA4 DebugView, а для фінансових операцій перевіряйте журнал модуля. Тест слід виконувати на реальному шляху покупки та з правильним статусом замовлення.
Обсяг модуля та важливі обмеження
- Модуль передає дані до налаштованих сервісів Google; він не створює та не адмініструє обліковий запис GA4, Google Ads, Merchant Center чи рекламні кампанії.
- Він не замінює налаштування згод або юридичний аналіз магазину. Власник магазину відповідає за підставу обробки даних, зміст згод і налаштування облікових записів Google.
- Блокування скриптів, відсутність згоди, відсутність збереженої атрибуції, неправильні ідентифікатори або налаштування Google можуть обмежити вимірювання. Модуль не гарантує повноту даних.
- Надсилання даних за допомогою API Secret вимагає правильної конфігурації GA4. Відповідь HTTP 2xx слід трактувати як підтвердження отримання запиту, а не як доказ видимості транзакції у звітах.
