Чек-ліст перевірки ecommerce Google Analytics 4. Шаблон від Spilno Agency

Перш ніж витратити перші гроші на Google Ads чи Meta Ads, ми в Spilno Agency завжди робимо одну й ту саму річ — перевіряємо, чи коректно працює ecommerce-трекінг у Google Analytics 4. Якщо подія purchase не приходить або приходить без value, реклама фактично «летить наосліп»: оптимізатор Google не розуміє, що таке конверсія, і витратить бюджет не на тих, хто купує. У цій статті — наш чек-ліст із 7 кроків і шаблон у Google Sheets, який ми використовуємо на кожному клієнтському проєкті.

Чому важливо перед запуском реклами завжди перевіряти роботу всіх подій ecommerce GA4

Запустити Google Ads чи Meta Ads без правильно налаштованої аналітики — це як їхати по трасі вночі з вимкненими фарами. Ви бачите, що дорога є, але куди вона веде і чи безпечно по ній рухатись — не знаєте. Алгоритми Google Smart Bidding і Meta Advantage+ навчаються на даних: чим точніше ви відправляєте подію purchase з валідним value, тим швидше реклама знаходить «правильну» аудиторію.

Друга причина — вартість помилки. Якщо в перший тиждень кампанії пікселі звітують про в 2 рази більше покупок, ніж було насправді (дубль-події add_to_cart порахували як purchase), оптимізатор завищить ставки. Через місяць ви побачите ROAS у 50 % від реального, і клієнт буде впевнений, що канал не працює. Насправді ж проблема — у даних.

Третя причина — атрибуція. Якщо transaction_id не передається, GA4 рахує одну й ту саму покупку кілька разів (бо кожне оновлення сторінки «дякую за замовлення» — нова подія). У Google Ads імпортовані конверсії роздуваються в 3–10 разів. ROAS на папері — захмарний, у кешбоксі — порожньо.

• Алгоритм Smart Bidding оптимізує те, що бачить — якщо подія purchase не з валідним value, ставки оптимізуються за «пустишкою»
• Дубль-події (одна покупка = 2–5 хітів) роздувають конверсії і ROAS у Google Ads та GA4
• Без currency у події purchase Google Ads імпортує конверсії за валютою акаунта, що псує дані для крос-валютних магазинів
• Без події view_item неможливо запустити динамічний ремаркетинг у Google Ads (Performance Max, Demand Gen)
• Без правильно налаштованого item_list_id у view_item_list неможливо побачити, які категорії конвертують краще

9 обов’язкових подій ecommerce у GA4

У Google Analytics 4 ecommerce-події — це окремий стандарт, який Google задокументував у Measurement Protocol. Не всі вони обов’язкові, але якщо ви хочете побудувати повну воронку від першого перегляду до покупки, у вас має бути щонайменше 9 подій. Ось вони, у порядку появи у воронці.

1. view_item_list — Користувач відкрив сторінку категорії, пошуку або колекції товарів. Параметри: item_list_id, item_list_name, масив items.
2. select_item — Клік по картці товару в списку. Та сама структура параметрів, що й у view_item_list, але вже з конкретним товаром.
3. view_item — Перегляд сторінки товару. Тут обов’язково мають бути currency, value, масив items з item_id, item_name, price.
4. add_to_cart — Додавання в кошик. Параметри: currency, value, items з quantity.
5. view_cart — Перегляд сторінки кошика. Без цієї події у вас не буде даних для CRO-аналізу — ви не побачите, скільки людей відкрило кошик, але не пішло далі.
6. remove_from_cart — Видалення товару з кошика. Допомагає оцінити, які товари «не подобаються» при ближчому перегляді ціни / умов доставки.
7. begin_checkout — Початок оформлення замовлення. Це ваш бенчмарк для розрахунку Cart-to-Checkout CR.
8. add_payment_info — Додавання способу оплати. Опційно, але корисно — між цим кроком і покупкою найбільший відсоток падінь у воронці.
9. purchase — Завершена покупка. Параметри обов’язкові: transaction_id (унікальний!), value, currency, items, shipping, tax. Це ключова подія (Key event) у GA4 і ваша головна конверсія у Google Ads.

Усі ці події GA4 «розуміє з коробки» — їх не треба створювати вручну в розділі «Події». Вам потрібно лише, щоб ваш dataLayer пушив їх з правильними іменами і параметрами. GA4 автоматично визначить їх як ecommerce-події і покаже у звітах «Електронна торгівля» та «Шлях покупця».

7 кроків перевірки ecommerce GA4 перед запуском Google Ads

Це наш робочий чек-ліст. Кожен пункт — це окремий ризик, який ми закриваємо до того, як клієнт побачить першу сплачену рекламу. Усі сім кроків ми вже зібрали в готовий шаблон у Google Sheets — посилання нижче в статті.

1. Крок 1. GA4-потік і Measurement ID. Заходимо в Admin → Data Streams. Перевіряємо, що потік один (а не дублюється), Measurement ID (G-XXXXXXX) відповідає тому, що зашитий у GTM-теги. Якщо у вас 2 потоки на той самий сайт — половина подій буде «втрачена».
2. Крок 2. GTM на всіх сторінках. У DevTools (Network → фільтр gtm.js) перевіряємо, що контейнер GTM завантажується на: головній, категорії, картці товару, кошику, чекауті, сторінці «дякуємо за замовлення». Особлива увага — до сторінки thank-you: саме на ній спрацьовує purchase.
3. Крок 3. dataLayer пушить 9 подій. Відкриваємо DevTools → Console → пишемо dataLayer. Бачимо масив. Робимо повну подорож по сайту і дивимось, що додалось. Має бути всі 9 подій із правильними параметрами. Якщо view_item приходить без value — це блокер.
4. Крок 4. DebugView у GA4. У GA4 → Admin → DebugView вмикаємо режим (через GTM-debug або розширення GA Debugger). Робимо тестову покупку. Дивимось, що подія purchase прийшла з усіма параметрами і з правильним transaction_id.
5. Крок 5. Параметри purchase. Перевіряємо в DebugView вкладку «Параметри події»: transaction_id має бути унікальним, value — числом (не рядком!), currency — у форматі ISO 4217 (UAH, USD, EUR), items — непорожній масив. Один пропуск тут — і реклама вчиться неправильно.
6. Крок 6. Позначення Key event. У GA4 → Admin → Events знаходимо purchase і вмикаємо тумблер «Mark as key event». Без цього кроку Google Ads не зможе імпортувати purchase як ціль для оптимізації.
7. Крок 7. Google Ads + GA4 link. У GA4 → Admin → Product links → Google Ads створюємо зв’язок. У Google Ads → Tools → Conversions імпортуємо ключову подію purchase з GA4. Перевіряємо, що статус — «Recording» і атрибуція — «Data-driven» (а не Last-click).

3 інструменти для перевірки подій GA4

Один інструмент дає неповну картину. Ми завжди використовуємо три у зв’язці: DebugView показує, як GA4 зрозумів подію; GTM Preview показує, чи правильно спрацював тег; Chrome DevTools — чи взагалі пішов hit на сервер Google.

DebugView — це адмінська панель у GA4, де ви бачите кожну подію вашого пристрою у реальному часі. Вмикається через розширення Google Analytics Debugger у Chrome або через GTM у режимі попереднього перегляду. Тут ви бачите не лише факт події, але й усі її параметри — це фінальна перевірка перед запуском реклами.

GTM Preview — режим попереднього перегляду в Google Tag Manager. Показує, який тег коли спрацював, які тригери спрацювали, які змінні були передані. Якщо тег GA4 Event — purchase не спрацював на сторінці «дякуємо», у Preview ви побачите це за 2 секунди. Chrome DevTools → Network — найнижчий рівень. Тут ми бачимо, чи hit на /g/collect реально пішов на сервер Google. Якщо у Preview все працює, а в Network hit не йде — значить, блокує adblock або CSP-політика сайту.

Шаблон чек-ліста від Spilno Agency у Google Sheets

Ми використовуємо один і той самий шаблон чек-ліста на всіх клієнтських проєктах — від UA-маркетплейсу одягу до магазину запчастин в ЄС. Він уже містить:

• Таблицю з 9 ecommerce-подіями і чек-боксами «GTM», «dataLayer», «DebugView», «Google Ads import»
• Окремий аркуш «Параметри події purchase» — для перевірки кожного поля по черзі
• Аркуш «Поширені помилки» — 12 проблем, які ми бачили на реальних проєктах, і як їх діагностувати
• Колонку «Відповідальний» — щоб закріпити, хто за що відповідає (PM, dev, аналітик)
• Колонку «Статус» з 4 значеннями: To check / In progress / Passed / Failed
• Поле «Дата перевірки» — фіксуємо момент успішної перевірки, щоб потім легко знайти регресію

Якщо ви — підрядник або агентство, шаблон можна адаптувати під своє брендування: змінити кольори, додати логотип, переписати назви аркушів. Ми не проти — це не комерційний продукт, а інструмент, яким ми ділимось з ринком.

Поширені помилки і як їх уникнути

Ось 6 проблем, які ми регулярно бачимо при аудиті GA4-налаштувань нових клієнтів.

1. Дубль purchase при оновленні сторінки thank-you. Якщо подія прив’язана до завантаження сторінки, а не до серверного callback, перезавантаження «дякуємо за замовлення» дає +1 покупка. Лікується перевіркою transaction_id у GTM-змінній (custom event) і блокуванням повторного push.
2. value як рядок, а не число. value: "1500" — це не те ж саме, що value: 1500. GA4 другий варіант обробляє коректно, перший — ігнорує. Перевірте в DebugView тип параметра.
3. Відсутня currency. Якщо ваш магазин обслуговує клієнтів з UA, EU і US, без currency у події purchase GA4 запише всі покупки за валютою акаунта. Result — Revenue у звітах не відповідає реальному.
4. Подія add_to_cart на кожне натискання + / -. Якщо у кошику можна збільшувати кількість кнопкою +, не пушити подію на кожне натискання. Інакше Cart additions роздуваються в 5–10 разів.
5. view_item на список товарів. Часто developer плутає view_item (картка одного товару) і view_item_list (категорія). Перевірте: на сторінці категорії має бути view_item_list з масивом, на сторінці одного товару — view_item з одним об’єктом у items.
6. Покупка з нульовим value. Якщо value: 0 для тестових / промо-замовлень — Smart Bidding інтерпретує як «безкоштовний продаж» і знизить ставки. Фільтруйте такі замовлення на рівні GTM або серверного API.

FAQ

Що зробити в першу чергу, якщо ecommerce GA4 не працює?

Зайти в DebugView, відкрити сайт у режимі debug (розширення GA Debugger) і пройти шлях покупця. Якщо в DebugView подія purchase не з’являється — проблема в dataLayer або тегах GTM. Якщо з’являється, але без параметрів — проблема в маппінгу параметрів у тегу GA4 Event.

Чи треба налаштовувати ecommerce-події в GA4 вручну?

Ні. 9 стандартних подій (view_item, add_to_cart, purchase і т.д.) GA4 розпізнає автоматично за іменами. Не треба створювати їх у розділі «Custom events». Достатньо, щоб dataLayer пушив правильно і тег GA4 у GTM передавав параметри без втрат.

Як часто треба робити цей чек-лист?

Перший раз — обов’язково перед запуском платної реклами. Далі — раз на квартал як планову перевірку, плюс після кожного релізу нової версії сайту, зміни template чекауту, додавання нової валюти або мови. Будь-яке оновлення фронтенду може зламати dataLayer.

Чи можна використовувати шаблон для Shopify / WooCommerce / OpenCart?

Так. Шаблон описує події, які мають з’являтися — незалежно від того, чим вони генеруються. Для Shopify і WooCommerce є офіційні плагіни/інтеграції, які пушать ці події з коробки. Чек-лист залишається тим самим — ви просто менше часу витратите на dev-роботу.

Що робити, якщо transaction_id повторюється?

GA4 нової покупки з тим самим transaction_id не запише — це захист від дублювання. Але якщо ви помилково генеруєте один і той самий ID для різних замовлень (наприклад, через timestamp без міллісекунд), частину покупок ви втратите. Перевірте логіку генерації ID на бекенді.

Висновок

Перевірка ecommerce GA4 — це не «технічна формальність», а захист бюджету. Якщо ви виділяєте на Google Ads 100 000 грн на місяць і у вас 20 % втрачених або задубльованих покупок — ви платите 20 000 грн просто за «шум». Перевірте всі 9 подій по нашому чек-лісту, збережіть шаблон собі на Google Диск і використовуйте його перед кожним запуском нової кампанії.