Як у WordPress та WooCommerce відстежувати дохід, транзакції та покупки в Google Analytics 4

Вступ

Власники магазинів на WooCommerce часто впевнені, що Google Analytics 4 вже показує їм дохід, кількість транзакцій і поведінку покупців. На практиці ж більшість сайтів передають у GA4 тільки перегляди сторінок — жодних view_item, add_to_cart чи purchase подій там немає. Це означає, що:

• в GA4 немає звіту “Дохід за джерелом трафіку”;
• Google Ads не бачить реальної цінності конверсій (ROAS рахувати нема з чого);
• рішення про масштабування реклами приймаються наосліп.

У цій статті — покроковий кейс, як ми діагностували та повністю налаштували ecommerce-трекінг на реальному клієнтському WooCommerce-магазині: від першої перевірки “а чи взагалі щось передається” до підтвердженого робочого purchase-івенту в GA4.

Крок 0. Як перевірити, чи ecommerce-трекінг взагалі працює

Перш ніж щось встановлювати, перевірте поточний стан. Найшвидший спосіб — відкрити код сторінки товару (Ctrl+U / Cmd+Option+U) і пошукати dataLayer.push.

Типова пастка: якщо ви шукаєте слово add_to_cart на сторінці товару WooCommerce, ви майже напевно його знайдете — але це буде лише CSS-клас кнопки:

<button class="single_add_to_cart_button ... add_to_cart_button ajax_add_to_cart" data-product_id="124">

Це не доказ роботи трекінгу. Реальна подія виглядає інакше — це виклик dataLayer.push() з об’єктом ecommerce:

dataLayer.push({
  "ecommerce": {
    "currency": "USD",
    "value": 358,
    "items": [{
      "item_id": 591,
      "item_name": "Назва товару",
      "price": 358,
      "item_category": "Products"
    }]
  },
  "event": "view_item"
});

Якщо на сторінці товару такого блоку немає — ecommerce-дані в GA4 не йдуть, навіть якщо базовий gtag('config', ...) для перегляду сторінок стоїть і працює.

Що ще варто перевірити на цьому етапі: – скільки разів на сторінці завантажується googletagmanager.com/gtm.js — має бути рівно один раз. Два виклики = дубльовані дані в GA4 (класична проблема, коли GTM-код і вручну вставлений, і доданий плагіном одночасно); – чи є вже встановлений, але неактивний, плагін-конектор (наприклад, Site Kit by Google) — часто стоїть “про всяк випадок”, але не виконує ecommerce-функцію взагалі.

Крок 1. Встановлення GTM4WP (Google Tag Manager for WordPress)

Для WooCommerce ecommerce-трекінгу оптимальний вибір — безкоштовний плагін GTM4WP (автор Thomas Geiger, slug у каталозі WordPress.org: duracelltomi-google-tag-manager). Причина вибору саме цього плагіна:

• вже офіційно реалізує GA4 E-commerce specification для WooCommerce “з коробки”;
• не вимагає написання жодного PHP-коду вручну;
• добре поєднується з уже наявним на сайті Google Tag Manager-контейнером.

Встановити можна стандартно: Плагіни → Додати новий → пошук “GTM4WP” → Встановити → Активувати.

Крок 2. Налаштування вкладки General

Після активації плагіна заходимо в Settings → Google Tag Manager, вкладка General.

Тут три ключові поля:

Google Tag Manager ID

Вставте ID вашого існуючого GTM-контейнера, наприклад GTM-XXXXXXX. Використовуйте той самий контейнер, що вже стоїть на сайті — не створюйте новий, інакше доведеться вручну переносити весь інший трекінг (рекламні пікселі, конверсії тощо), який вже може бути там налаштований.

Container code ON/OFF — найважливіший момент

Це поле вирішує долю дублювання GTM-контейнера на сайті:

Сам плагін прямо підказує це в описі поля: “This should be only used in specific cases where you need to place the container code manually or using another tool” — тобто це офіційно задокументований сценарій саме для випадку, коли GTM вже стоїть іншим способом.

Чому це критично: якщо залишити On при вже наявному ручному коду — контейнер завантажиться двічі на кожній сторінці, і GA4/Google Ads почнуть рахувати вдвічі більше подій і переглядів, ніж є насправді. Це одна з найпоширеніших і водночас найнепомітніших помилок в ecommerce-трекінгу — цифри виглядають правдоподібно, тож проблему часто виявляють лише через місяці, звіряючи дохід GA4 з реальними продажами.

Container code compatibility mode

Впливає на розміщення другої (<noscript>) частини коду GTM. Якщо на цьому пункті вибрано Container code = Off — це поле не має значення (плагін нічого не вставляє). Якщо ж обрали On і сайт побудований на Elementor — офіційна документація плагіна прямо радить ставити “Off (no tweak, right placement)”, оскільки Elementor підтримується нативно.

Крок 3. Вкладка Integration → WooCommerce

Тут вмикається сама логіка ecommerce-трекінгу.

Обов’язкові поля

Track e-commerce → увімкнути. Це головний перемикач: без нього WooCommerce ніяк не спілкується з dataLayer. Плагін сам підказує це в описі, якщо бачить активний WooCommerce: “strongly recommended to enable this integration”.

Clear ecommerce object before new event → увімкнути. Це офіційна рекомендація Google для GA4 dataLayer-реалізацій: очищує попередній ecommerce-об’єкт перед кожною новою подією, щоб дані з попереднього кроку воронки (наприклад, товари з view_item) не “просочувались” у наступну подію (add_to_cart).

Поля, які варто залишити за замовчуванням

• Products per impression (10) — розбиває великі списки товарів на кілька подій, щоб не втрачати перегляди при великій кількості товарів на сторінці категорії.
• Only track orders younger than 30 хв (experimental) — захист від повторного трекінгу транзакції, якщо покупець повторно відкриє сторінку “Дякуємо за замовлення”.
• Do not flag orders as being tracked → залишити вимкненим. Сам плагін попереджає: вмикати тільки якщо дійсно потрібно, інакше зростає ризик дублювання транзакцій в аналітиці.
• Google Ads Business Vertical → Retail, якщо у вас звичайний інтернет-магазин.

Опціональні поля (не критичні для базового трекінгу доходу)

• Cart content in data layer, Include full category path — корисні для персоналізації сайту чи детальних категорійних звітів, але не потрібні лише для трекінгу доходу/транзакцій. Include full category path плагін прямо попереджає може вплинути на швидкодію при великому трафіку.
• Customer data in data layer / Order data in data layer — це не про базовий ecommerce-трекінг доходу. Це підготовка даних для Enhanced Conversions у Google Ads (передача хешованого email покупця для точнішого мечингу конверсій). Дуже корисно, якщо ви ведете рекламу для сайту, але це окрема задача — див. розділ нижче.
• Exclude tax from revenue / Exclude shipping from revenue — бізнес-рішення: чи має дохід у GA4 включати податок/доставку (тобто відповідати повній сумі замовлення), чи лише “чистий” дохід за товари. Немає універсально правильної відповіді — узгодьте з тим, хто звіряє фінансові показники.

Крок 4. Перевірка dataLayer на живому сайті

Після збереження налаштувань — перевірте результат безпосередньо в коді сторінок (Ctrl+U), пройшовши уявну воронку покупця:

Сторінка товару — має з’явитись:

dataLayer.push({"ecommerce":{"currency":"USD","value":358,"items":[{"item_id":591,"item_name":"...","price":358,...}]},"event":"view_item"});

Кошик з товаром (view_cart) і чекаут з товаром (begin_checkout) — аналогічна структура, але з іншим event та полем quantity у товарах.

Важливий нюанс: якщо ви перевіряєте кошик/чекаут без доданого товару — жодної події не буде, і це нормально. GTM4WP навмисно не генерує view_cart/begin_checkout для порожнього кошика, щоб не засмічувати аналітику фейковими нульовими транзакціями. Спочатку реально додайте товар у кошик, а вже потім перевіряйте код сторінки.

Подію purchase таким способом не перевірити — вона спрацьовує лише після реального оформленого замовлення (хук woocommerce_thankyou). Найпростіший спосіб протестувати — оформити одне тестове замовлення на мінімальну суму або з купоном на 100% знижку.

Крок 5. Налаштування тегів у Google Tag Manager

Дані в dataLayer — це лише половина шляху. Google Analytics 4 нічого не отримає, доки в самому Google Tag Manager немає тегів, які слухають ці події й відправляють їх у GA4.

Варіант А: вручну через інтерфейс GTM

1. GA4 Configuration тег — тип “Google Analytics: GA4 Configuration”, вкажіть ваш Measurement ID (G-XXXXXXXXXX). Якщо на сайті вже є прямий gtag.js для базових переглядів сторінок (поза GTM) — обов’язково вимкніть галочку “Send a page view event when this configuration loads”, інакше отримаєте дубль page_view. Тригер — All Pages.
2. Для кожної події (view_item, add_to_cart, view_cart, begin_checkout, purchase) створіть: – Custom Event тригер з іменем події, що точно збігається з тим, що штовхає GTM4WP; – GA4 Event тег, що посилається на GA4 Configuration тег, з увімкненою опцією “Send Ecommerce Data” — тоді GTM автоматично прочитає весь об’єкт dataLayer.ecommerce, вручну мапити items/value/currency не потрібно.

Варіант Б: імпорт готового файлу (швидше)

Замість ручного клікання всіх 6 тегів і 5 тригерів, можна підготувати JSON-файл експорту контейнера з усіма потрібними елементами та імпортувати його одним кліком:

Admin → Import Container → вибрати файл → вибрати робочу область → варіант “Об’єднати” (Merge, НЕ “Перезаписати”).

⚠️ Важливо обрати саме “Об’єднати”, а не “Перезаписати” — Overwrite повністю замінює вміст обраної робочої області тільки тим, що є у файлі, стираючи все інше, що там вже могло бути налаштовано.

Після імпорту — обов’язково перевірте результат у Preview mode GTM перед публікацією, а не публікуйте наосліп: пройдіться сайтом (товар → кошик → чекаут) і в debug-панелі перевірте, що кожен тег дійсно спрацьовує на своїй події.

Крок 6. Публікація і фінальна перевірка

Після Preview-тестування — Submit → Publish у Google Tag Manager. У розділі Версії можна побачити повний перелік того, що потрапило в нову версію:

Фінальна перевірка — переконатись, що опубліковані зміни реально роздаються на сайті прямо зараз. Найшвидший спосіб — завантажити публічний скрипт контейнера напряму:

curl -s "https://www.googletagmanager.com/gtm.js?id=GTM-XXXXXXX" | grep -oE "gaawc|gaawe|view_item|add_to_cart|purchase" | sort | uniq -c

Якщо у відповіді бачите gaawc (GA4 Configuration) та gaawe (GA4 Event) поряд з назвами ваших подій — теги дійсно живі й роздаються відвідувачам сайту, а не просто збережені в чернетці.

Останній крок, який може перевірити лише власник GA4-акаунту, — відкрити GA4 → Звіти в реальному часі або DebugView, пройти сайтом як звичайний відвідувач і переконатись, що події view_item/add_to_cart/purchase дійсно надходять з полями value, currency, items.

У нашому кейсі саме так і сталось — за кілька хвилин після публікації в стандартному звіті GA4 “Кількість подій за назвою події” з’явились нові події з очікуваними параметрами:

Це і є фінальний доказ: дані пройшли весь ланцюжок від WooCommerce до звітів GA4.

Бонус: якщо ви ведете рекламу Google Ads для сайту

Базовий ecommerce-трекінг вирішує задачу “бачити дохід у GA4-звітах”. Але якщо агенція чи власник магазину ще й веде рекламу в Google Ads, варто окремо налаштувати Enhanced Conversions — це суттєво підвищує точність атрибуції конверсій, особливо важливо в умовах обмежень third-party cookies.

Коротко, що для цього потрібно (окремий етап, не змішувати з базовим налаштуванням): 1. Увімкнути опцію “Order data in data layer” у GTM4WP — вона додає в dataLayer на сторінці подяки об’єкт orderData, що вже містить хешований email покупця. 2. Увімкнути Enhanced Conversions у самому акаунті Google Ads клієнта. 3. Додати в GTM тег Google Ads Conversion Tracking з режимом Enhanced Conversions, прив’язаний до полів orderData. 4. Переконатись, що цей тег спрацьовує лише за наявності згоди на ad_storage/ad_user_data (Consent Mode) — оскільки передаються персональні дані, навіть у хешованому вигляді.

Типові помилки — короткий чекліст

• ❌ Плутати CSS-класи кнопок (add_to_cart_button) з реальними dataLayer.push подіями.
• ❌ Залишати ручний GTM-код увімкненим одночасно з автоматичним вставленням від плагіна → дублювання даних.
• ❌ Перевіряти кошик/чекаут без реально доданого товару і робити висновок “не працює”.
• ❌ Обирати “Перезаписати” замість “Об’єднати” при імпорті контейнера в GTM.
• ❌ Публікувати зміни в GTM одразу, без перевірки в Preview mode.
• ❌ Плутати базовий ecommerce-трекінг з Enhanced Conversions — це різні задачі з різною метою.

Висновок

Повний ланцюжок “WooCommerce → dataLayer → GTM → GA4” складається з трьох незалежних шарів, і кожен потрібно перевіряти окремо: чи WordPress генерує правильні дані, чи GTM їх правильно ловить і відправляє, і чи GA4 їх реально отримує. Пропуск будь-якого з трьох кроків — і в звітах буде тиша замість доходу, при цьому здаватиметься, що “все ж начебто налаштовано”.