+42%
WooCommerce + GA4: як не втрачати 40% замовлень
Серверна відправка purchase через Measurement Protocol з повною атрибуцією: client_id, session_id, gclid
🛒
+40%
Відновлених конверсій
+40%
відновлених конверсій
100%
атрибуція
Кому це підходить
Цей кейс для вас, якщо...
🛒
WooCommerce магазин
WooCommerce магазин з Google Ads, де кількість purchase у GA4 не збігається з реальними замовленнями
🔧
GA4 через плагін або GTM
AdBlock, Safari ITP, Brave блокують GA4 трекер — і ви втрачаєте дані про покупки
📊
Дані потрапляють у (not set)
Атрибуція зламана: source/medium показує (not set), gclid не передається, ROAS неточний
🔒
ROAS у Google Ads неточний
Smart Bidding в Google Ads оптимізується на неповних даних — і ви переплачуєте за кліки
Впізнали себе? Читайте далі — цей кейс покаже рішення.
Контекст
Про проєкт
Інтернет-магазин на WordPress + WooCommerce
Інтернет-магазин на WordPress + WooCommerce. GA4 інтегровано через GTM і плагіни — стандартна конфігурація для більшості WordPress-сайтів.
🔥
Виклик
Аналітика втрачає до 40% замовлень: AdBlock, iOS Safari, Brave блокують трекери. Події відправляються тільки з фронту — клієнт залишає сторінку до спрацювання. Дані потрапляють у (not set), атрибуція зламана.
🎯
Цілі
01
Відновити фіксацію всіх purchase-подій у GA4
02
Зберегти повну атрибуцію: source, medium, campaign, gclid
03
Підвищити точність ROAS у Google Ads
Чому це складно
Що тут може піти не так
І чому більшість підрядників це запорюють
Плагіни = тільки фронтенд
Стандартні GA4-плагіни для WooCommerce відправляють purchase-подію з JavaScript на фронтенді. AdBlock, Safari ITP, Brave, Firefox ETP блокують цей запит. Результат — до 40% замовлень просто не фіксуються.
Як я вирішила:
PHP-обробник на woocommerce_thankyou з серверною відправкою
Атрибуція губиться між сторінками
client_id, session_id, gclid потрібно зберегти від першого візиту до purchase. Якщо JS не встиг зчитати їх або користувач перейшов через redirect — атрибуція зламана. GA4 покаже (not set), Google Ads не побачить конверсію.
Як я вирішила:
JS зчитує client_id/session_id через gtag("get",...), зберігає в cookie, передає на сервер
Валідація server-side purchase
Server-side Measurement Protocol не має DebugView за замовчуванням. Якщо payload невалідний — подія просто мовчки відкидається. Без логування і валідації можна тижнями не помічати проблему.
Як я вирішила:
Повне логування + GA4 DebugView + валідація прив'язки до сесії
Процес
Що було зроблено
ЕТАП 01
PHP-обробник на woocommerce_thankyou
Створено власний PHP-обробник, який спрацьовує на хук woocommerce_thankyou і збирає всі дані замовлення: transaction_id, items, brand, value.
ЕТАП 02
JS для client_id та session_id
JS-файл зчитує client_id та session_id з GA4 через gtag("get",...). Зберігає в cookie і передає на сервер разом з формою замовлення.
ЕТАП 03
Server-side відправка в GA4
Сервер відправляє purchase-подію на google-analytics.com/mp/collect з повною передачею: client_id, session_id, source/medium/campaign, gclid/gbraid.
ЕТАП 04
Логування і валідація
Повне логування всіх відправок. Перевірка через GA4 DebugView. Валідація що purchase прив'язується до правильної сесії і воронки.
Мій підхід
Що я зробила інакше
1
PHP-обробник замість JS-плагіна
Створила власний PHP-обробник на хук woocommerce_thankyou. Сервер відправляє purchase напряму на google-analytics.com/mp/collect — жоден AdBlock не може заблокувати серверний запит.
2
Повна атрибуція через cookie bridge
JS зчитує client_id і session_id з GA4, зберігає в first-party cookie. При замовленні PHP бере ці значення і передає в Measurement Protocol разом з gclid/gbraid. Результат — 100% атрибуція.
3
Логування і валідація кожної відправки
Кожен server-side purchase логується: transaction_id, client_id, session_id, відповідь GA4. Перевірка через DebugView що purchase прив'язується до правильної сесії і воронки.
Результати
Цифри, що говорять самі за себе
+40%
Відновлених конверсій
100%
Атрибуція збережена
↑
ROAS у Google Ads
Трансформація
До та після
Purchase-події
Втрата до 40%
100%
Server-side MP
Атрибуція
(not set)
100%
client_id + gclid
Відправка
JS frontend
PHP server-side
Measurement Protocol
Валідація
Не існує
Повна
Логування + DebugView
Що це означає для бізнесу
+40%
замовлень, які раніше не фіксувалися в GA4
100%
атрибуція збережена: source, medium, gclid
Простіше кажучи: Google Ads нарешті бачить всі покупки і може правильно оптимізувати ставки. Той самий бюджет — більше конверсій.
Безкоштовний ресурс
Гайд: Server-side GA4 для WooCommerce — без плагінів
Як відправляти purchase з PHP через Measurement Protocol з повною атрибуцією. Покрокова інструкція з прикладами коду.
- PDF, 3 сторінки — архітектура + код
- PHP-шаблон для woocommerce_thankyou
- Без реєстрації, без спаму
PDF
WooCommerce Server-side GA4 Guide
Питання
Часті питання
Чому GA4 плагін для WooCommerce втрачає замовлення?
Стандартні GA4-плагіни відправляють purchase-подію з JavaScript на фронтенді. AdBlock, Safari ITP, Brave, Firefox ETP блокують цей запит — до 40% замовлень просто не фіксуються. Рішення — серверна відправка через Measurement Protocol.
Як налаштувати server-side purchase для WooCommerce через Measurement Protocol?
Потрібен PHP-обробник на хук woocommerce_thankyou, який збирає transaction_id, items, value і відправляє на google-analytics.com/mp/collect. Для атрибуції JS зберігає client_id і session_id в cookie, а PHP передає їх разом з gclid.
Як перевірити що server-side purchase працює правильно?
Три рівні валідації: 1) логування кожної відправки з response кодом, 2) перевірка в GA4 DebugView що purchase прив'язується до правильної сесії, 3) порівняння кількості замовлень у WooCommerce vs GA4 за тиждень.
Готові до зростання?
Обговоримо ваш проєкт — знайдемо рішення, що працює саме для вашого бізнесу.