Вибір між прямим модулем 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.
Демонстраційна схема події view_item. Показує розподіл відповідальності, а не результат вимірювання в робочому акаунті GA4.
У прямому варіанті модуль збирає дані товару і готує виклик Google tag. У варіанті GTM Pro модуль передає об’єкт події до dataLayer, а опублікований контейнер вирішує, чи запускати тег і кому його надсилати. Для обох варіантів потрібно окремо визначити правила згоди та правильність параметрів.
dataLayer також присутній при прямому використанні gtag. Сама наявність цієї змінної в браузері не доводить, що магазин використовує контейнер GTM. Google описує обидва застосування в документації шару даних.
Найважливіша різниця: коли виникає 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. Вона містить демонстраційні приклади та поля для результату власної перевірки.
Приклад розподілу відповідальності для заповнення для власного магазину
Подія
Джерело
Отримувач
Згода і відповідальність
view_item
Прямий модуль або модуль dataLayer і тег GTM — виберіть один шлях.
Вказаний потік GA4.
Особа, яка підтримує аналітику, перевіряє сигнали CMP та умови тегу.
Вибраний статус або документ коригування відповідно до використаного рішення.
Потік, у якому зареєстровано покупку.
Особа, відповідальна за повернення, узгоджує повний і частковий обсяг та спосіб валідації.
Згоди та Measurement Protocol є частиною проєкту
У перевіреній версії GA4 Pro довірена згода для запису атрибуції та серверних фінансових операцій пов’язана з активним PD Cookie Pro, його режимом live, Consent Mode v2 і поточною ревізією згоди. Не припускайте, що заміна цього постачальника на будь-який інший банер збереже весь серверний шлях без додаткової перевірки.
GTM Pro має власні налаштування Consent Mode і конкретні інтеграції постачальників згоди. При активному PD Cookie Pro він залишає йому керування згодами. Остаточна поведінка також залежить від опублікованого контейнера. Наявність банера або поля конфігурації ще не є результатом тесту «відмова → згода → відкликання».
Серверний шлях не означає обходу згоди або автоматичного відновлення джерела сесії. API Secret належить до конфігурації сервера. Зв’язок з активністю браузера вимагає правильних ідентифікаторів і контексту; орієнтиром є документація надсилання подій Measurement Protocol.
Старіший GTM і GTM Pro — це не одна й та сама пропозиція
Старіший PD Google Tag Manager 1.2.4 служить для вбудовування контейнера. Перевірений код не містить моделі ecommerce і черги Measurement Protocol, описаних вище для версії Pro. Не сприймайте назву «GTM» як обіцянку готових подій покупки.
PD Google Tag Manager Pro додає шар даних і інструменти конфігурації. Експорт контейнера є стартовою точкою для імпорту, перегляду та публікації в GTM. Він не замінює приймання конфігурації. Поле власної адреси сервера також не створює автоматично інфраструктуру server-side GTM.
Як вибрати варіант і уникнути двох власників покупки?
Прямий модуль: розгляньте його, якщо хочете, щоб логіка браузерних подій і серверного purchase залишалася в одному рішенні, а GTM не був потрібен для інших інструментів.
GTM Pro: розгляньте його, якщо у вас уже є процес роботи з контейнером, власник GTM і потреба керувати тегами також поза GA4.
Попередження: спочатку проведіть інвентаризацію активних модулів і тегів. Не додавайте другого емітера purchase лише тому, що кількість покупок у звіті викликає сумніви.
Приймання має охоплювати по одному контрольованому проходу для товару, кошика, правильного моменту покупки і повернення, а також відмову та відкликання згоди. Розділіть доказ «подію створено», «відправлення виконано» і «подію видно в GA4». Саме dataLayer.push, рендеринг сторінки чи HTTP-відповідь транспорту ще не підтверджують повноту звіту.
Google Analytics 4 Pro – модуль GA4 для PrestaShop
Google Analytics 4 Pro — це модуль PrestaShop для впровадження тега Google і вимірювання поведінки користувачів у Google Analytics 4. Він реєструє події, пов’язані з товарами, списками товарів, кошиком, оформленням замовлення, пошуком і обліковим записом клієнта. Покупки та підтримувані повернення...
PD Google Tag Manager Pro — це розширений модуль PrestaShop для впровадження Google Tag Manager з повним DataLayer e-commerce, інтеграцією з GA4 та підтримкою Google Consent Mode v2. Модуль автоматично вбудовує код GTM у секцію head і в частину noscript після відкриття тега body, може працювати з другим контейнером GTM і також підтримує адресу server-side...
Патрик Марек — власник PrestaDev.pl і програміст, який спеціалізується на PrestaShop. Уже багато років займається створенням, розвитком і підтримкою інтернет-магазинів. Поєднує роботу над кодом магазину та модулів із налаштуванням серверного середовища, у якому працюють ці рішення.
Проєктує та розвиває модулі PrestaShop, адаптує наявні функції, а також готує інтеграції з оптовими складами та зовнішніми сервісами. Працює над імпортом і оновленням даних про товари, автоматизацією обслуговування каталогу, процесом оформлення замовлення та інструментами, що підтримують щоденну роботу власника магазину.
Його досвід також охоплює оновлення та міграції магазинів, діагностику помилок, аналіз продуктивності, а також налаштування серверів і сервісів, необхідних для роботи PrestaShop. Під час розв’язання проблем враховує залежності між модулями, темою, PHP, базою даних і налаштуваннями хостингу.
У блозі ділиться знаннями, що випливають із багаторічної програмістської практики та роботи з технічним бекендом магазинів. Посібники зосереджені на конкретних проблемах, способах їх перевірки та обмеженнях описаних рішень. Вони допомагають власникам магазинів і технічним спеціалістам підготувати зміни, оцінити їх обсяг і перевірити результат.
Коментарі (0)