--- type: "blog" id: 32 url: "https://prestadev.pl/uk/blog/news/ga4-modul-ci-google-tag-manager-prestashop" markdown_url: "https://prestadev.pl/uk/markdown/blog/32.md" title: "GA4 через модуль чи Google Tag Manager? Як вибрати інтеграцію PrestaShop" description: "Порівняйте джерела подій, момент надсилання покупки та вимоги щодо згод у GA4 Pro і GTM Pro. Завантажте матрицю для планування вимірювання." language: "uk" published: "2026-09-26 20:07:36" updated: "2026-09-27 19:18:22" author: "Patryk Marek" category: "News" --- # GA4 через модуль чи Google Tag Manager? Як вибрати інтеграцію PrestaShop Порівняння конкретних версій GA4 Pro, GTM Pro і старішого завантажувача GTM: джерела подій, момент покупки, згоди та відповідальність за налаштування. Вибір між прямим модулем GA4 і Google Tag Manager почніть із визначення, хто створює події, коли вважає замовлення покупкою і хто підтримує конфігурацію. Сам ідентифікатор `G-…` або `GTM-…` не відповідає на ці запитання. Порівнюємо конкретні версії: PD Google Analytics 4 Pro 1.4.2, PD Google Tag Manager Pro 2.3.4 і старіший PD Google Tag Manager 1.2.4. ![Два шляхи події: модуль викликає Google tag або dataLayer запускає тег у контейнері GTM.](https://prestadev.pl/themes/warehouse/assets/img/pdseo-20260926-ga4-gtm-zdarzenie-view-item.png) Демонстраційна схема події view\_item. Показує розподіл відповідальності, а не результат вимірювання в робочому акаунті GA4. У прямому варіанті модуль збирає дані товару і готує виклик Google tag. У варіанті GTM Pro модуль передає об’єкт події до `dataLayer`, а опублікований контейнер вирішує, чи запускати тег і кому його надсилати. Для обох варіантів потрібно окремо визначити правила згоди та правильність параметрів. `dataLayer` також присутній при прямому використанні `gtag`. Сама наявність цієї змінної в браузері не доводить, що магазин використовує контейнер GTM. Google описує обидва застосування в [документації шару даних](https://developers.google.com/tag-platform/tag-manager/datalayer). ## Найважливіша різниця: коли виникає purchase? | Область | GA4 Pro 1.4.2 | GTM Pro 2.3.4 | | --- | --- | --- | | Події браузера | Модуль готує виклики Google tag, зокрема перегляд товару і початок checkout. | Модуль створює події в dataLayer. У контейнері потрібно налаштувати й опублікувати відповідні теги, правила та змінні. | | Покупка | Серверний шлях Measurement Protocol перевіряє налаштований статус оплати та історію кваліфікованої оплати. | Подія purchase може походити зі сторінки підтвердження, з dataLayer або з окремої автоматизації. Сам модуль не визначає єдиний момент покупки без конфігурації Measurement Protocol і завдання CRON. Запис рендерингу підтвердження впливає на рішення про повторну спробу. | | Повернення | Передбачено операції згідно з налаштованим статусом або документом коригування, з контролем попередньої покупки та повернень. | Документ коригування може поповнювати чергу refund; відправлення залежить від контексту, згоди й активної автоматизації. | Тому не порівнюйте кількість `purchase` без визначення їхнього значення. Створене замовлення, показане на сторінці підтвердження і кваліфіковане як оплачене — це три різні моменти. При банківському переказі, що очікує на оплату, різниця може бути особливо помітною. ## Матриця подій перед запуском вимірювання Для кожної події запишіть джерело, отримувача, умову згоди та відповідальну особу. [Завантажте редаговану матрицю CSV](https://prestadev.pl/themes/warehouse/assets/img/pdseo-20260926-ga4-gtm-macierz.csv). Вона містить демонстраційні приклади та поля для результату власної перевірки. | Подія | Джерело | Отримувач | Згода і відповідальність | | --- | --- | --- | --- | | view\_item | Прямий модуль або модуль dataLayer і тег GTM — виберіть один шлях. | Вказаний потік GA4. | Особа, яка підтримує аналітику, перевіряє сигнали CMP та умови тегу. | | purchase | Визначений бізнес-момент і один власник емісії. | Той самий узгоджений потік. | Власник інтеграції перевіряє контекст клієнта, згоди, ідентифікатор транзакції та повторні спроби. | | refund | Вибраний статус або документ коригування відповідно до використаного рішення. | Потік, у якому зареєстровано покупку. | Особа, відповідальна за повернення, узгоджує повний і частковий обсяг та спосіб валідації. | ## Згоди та Measurement Protocol є частиною проєкту У перевіреній версії GA4 Pro довірена згода для запису атрибуції та серверних фінансових операцій пов’язана з активним PD Cookie Pro, його режимом live, Consent Mode v2 і поточною ревізією згоди. Не припускайте, що заміна цього постачальника на будь-який інший банер збереже весь серверний шлях без додаткової перевірки. GTM Pro має власні налаштування Consent Mode і конкретні інтеграції постачальників згоди. При активному PD Cookie Pro він залишає йому керування згодами. Остаточна поведінка також залежить від опублікованого контейнера. Наявність банера або поля конфігурації ще не є результатом тесту «відмова → згода → відкликання». Серверний шлях не означає обходу згоди або автоматичного відновлення джерела сесії. API Secret належить до конфігурації сервера. Зв’язок з активністю браузера вимагає правильних ідентифікаторів і контексту; орієнтиром є [документація надсилання подій Measurement Protocol](https://developers.google.com/analytics/devguides/collection/protocol/ga4/sending-events). ## Старіший GTM і GTM Pro — це не одна й та сама пропозиція Старіший [PD Google Tag Manager](https://prestadev.pl/pl/google-tag-manager-dla-prestashop.html) 1.2.4 служить для вбудовування контейнера. Перевірений код не містить моделі ecommerce і черги Measurement Protocol, описаних вище для версії Pro. Не сприймайте назву «GTM» як обіцянку готових подій покупки. [PD Google Tag Manager Pro](https://prestadev.pl/pl/google-tag-manager-pro-modul-dla-prestashop.html) додає шар даних і інструменти конфігурації. Експорт контейнера є стартовою точкою для імпорту, перегляду та публікації в GTM. Він не замінює приймання конфігурації. Поле власної адреси сервера також не створює автоматично інфраструктуру server-side GTM. ## Як вибрати варіант і уникнути двох власників покупки? - **Прямий модуль:** розгляньте його, якщо хочете, щоб логіка браузерних подій і серверного purchase залишалася в одному рішенні, а GTM не був потрібен для інших інструментів. - **GTM Pro:** розгляньте його, якщо у вас уже є процес роботи з контейнером, власник GTM і потреба керувати тегами також поза GA4. - **Попередження:** спочатку проведіть інвентаризацію активних модулів і тегів. Не додавайте другого емітера purchase лише тому, що кількість покупок у звіті викликає сумніви. Приймання має охоплювати по одному контрольованому проходу для товару, кошика, правильного моменту покупки і повернення, а також відмову та відкликання згоди. Розділіть доказ «подію створено», «відправлення виконано» і «подію видно в GA4». Саме `dataLayer.push`, рендеринг сторінки чи HTTP-відповідь транспорту ще не підтверджують повноту звіту. Якщо покупка вже присутня, але має неправильний хост або канал, перейдіть до посібника [про діагностику вимірювання продажів у GA4](https://prestadev.pl/pl/blog/baza-wiedzy/ga4-prestashop-brak-zakupow-pomiar-sprzedazy). Якщо ви лише обираєте рішення, підготуйте матрицю й опишіть поточні модулі в [запиті щодо підбору інтеграції](https://prestadev.pl/pl/kontakt).