Всім привіт! Мене звати Яна Ляшенко, я Google-логіст. Сьогодні розберемо, як підготувати сайт на WordPress до запуску рекламних кампаній — будь то Google Shopping або Performance Max.
Почнемо з двох базових речей, без яких далі рухатися просто неможливо:
Налаштування цілей. Це установка аналітики, яка буде фіксувати всі дії відвідувачів на Вашому сайті — від перегляду сторінок до оформлення замовлення.
Встановлення динамічного ремаркетингу. Без нього Ви не зможете повернути відвідувачів, які переглядали конкретні товари, але так і не купили їх.
У цьому матеріалі покажу, як все зробити безкоштовно. Будемо налаштовувати електронну торгівлю та динамічний ремаркетинг через плагін Google Tag Manager для WordPress від Томаса Гейгера. Якщо у Вас є інший інструмент, якому довіряєте — використовуйте його. Але цей плагін перевірений на сотнях проектів і працює стабільно практично у всіх.
Скільки дзвінків і продажів я отримаю замовивши у Вас контекстну рекламу?
Один момент, про який варто знати заздалегідь. Безкоштовні рішення не підходять для всіх можливих сценаріїв. Кожен сайт унікальний: хтось використовує стандартну тему, хтось — кастомну з десятком плагінів. Якщо Ваш сайт завантажується повільно або має складну структуру, можливо, доведеться шукати альтернативний спосіб інтеграції. Наприклад, підключити преміум-версію плагіна або налаштувати передачу даних через розробника.
Створення облікового запису в Google Tag Manager
Переходимо до практики. Насамперед потрібно встановити плагін на WordPress, а потім — створити обліковий запис у Google Tag Manager. Процес простий, впорається будь-хто.
Заходимо на tagmanager.google.com і натискаємо «Створити обліковий запис». Тут Вас попросять вказати назву облікового запису.
Моя порада: називайте акаунт за назвою бренду або домену сайту. Наприклад, «myshop-ua» або «BrendName». Чому це важливо? Згодом акаунтів може накопичитися багато, і, якщо скрізь буде щось на кшталт «test123» або «новий акаунт» — Ви витратите купу часу, щоб знайти потрібний.
Наступний крок — назва контейнера. Тут у полі «Цільова платформа» вибираємо «Web» і натискаємо «Створити».
З’явиться вікно з умовами використання. Тут все просто: або погоджуєтеся і працюєте, або ні. Після підтвердження система покаже інструкцію з установки коду. Якщо зайти в розділ «Теги», там поки порожньо — це нормально, ми все налаштуємо через плагін.
Вставка Google Tag Manager в WooCommerce
Тепер пов’яжемо створений обліковий запис із сайтом. Для цього копіюємо ідентифікатор контейнера — це код формату GTM-XXXXXXX, який відображається у верхній частині екрана Tag Manager.
Далі переходимо в адмінку WordPress, знаходимо налаштування плагіна — розділ називається «Google Tag Manager for WordPress options». У вкладці General вставляємо скопійований ідентифікатор у відповідне поле.
І обов’язковий момент: перемикач Container code On/Off повинен бути в положенні «On». Без цього контейнер просто не буде завантажуватися на сайті, і все налаштування виявиться марним.
Налаштування плагіна Google Listings & Ads для WooCommerce
Переходимо до налаштування самого плагіна. Відкриваємо вкладку Integration, потім розділ WooCommerce. Тут потрібно встановити кілька важливих параметрів.
Насамперед ставимо галочку навпроти «Track e-commerce». Власне, заради цієї функції ми й затіяли всю цю історію з плагіном — без неї дані про покупки просто не передаватимуться.
«Products per impression» — тут вказується, скільки товарів враховується при перегляді списку. За замовчуванням стоїть 10 або 15, але я зазвичай ставлю 5. З подією view_item_list на WordPress бувають проблеми, тому пізніше ми зробимо для нього окреме ручне налаштування. Поки що не критично, яке число вкажете.
Далі йдуть чекбокси для додаткових даних. Рекомендую включити «Customer data» і «Order data». А ось податки і вартість доставки я зазвичай виключаю з розрахунку доходу. Чому? Якщо хочете бачити реальну маржинальність реклами, вважайте чисту суму замовлення без цих накруток.
Наступний блок — налаштування для динамічного ремаркетингу Google Ads. У полі «Google Ads Business Vertical» вибираємо «Retail», якщо у Вас інтернет-магазин. Інші варіанти (освіта, готелі, авіаквитки) — для інших типів бізнесу.
Тепер важливий момент з «Product ID prefix». У мене тут вказано gla_. Поясню, навіщо це потрібно.
Для вивантаження товарного фіду я використовую безкоштовний плагін Google Listings & Ads. Він автоматично додає до ідентифікаторів товарів префікс «gla_». Тобто якщо в WooCommerce товар має ID «12345», у фіді він перетворюється на «gla_12345».
Для динамічного ремаркетингу критично важливо, щоб ID товарів у фіді збігалися з тими, що передаються з сайту. Якщо у фіді «gla_12345», а сайт відправляє просто «12345» — ремаркетинг не спрацює, Google просто не зіставить дані.
Видалити цей префікс у плагіні Google Listings & Ads неможливо, правила перетворення для Content API теж не допомагають. Тому додаємо префікс вручну на стороні GTM-плагіна — і все сходиться.
Після всіх налаштувань не забудьте натиснути «Зберегти зміни». Базову конфігурацію ми задали, далі будемо доопрацьовувати окремі події.
Повертаємося до вкладки Integration, відкриваємо розділ WooCommerce і знаходимо посилання Official Guide. Переходимо за ним.
Не буду змушувати Вас вручну створювати десятки змінних і розбиратися у всіх тонкощах Google Tag Manager. Якщо у Вас інтернет-магазин, логічніше налаштувати все максимально швидко і просто. Для тих, кому цікавий розширений мануал з поясненням, звідки беруться змінні і як з ними працювати — напишіть у коментарях, я запишу окремий матеріал. Але це скоріше для фахівців.
Зараз рекомендую просто прочитати офіційний гайд — він написаний зрозумілою мовою і охоплює основні сценарії.
Встановлення тегу аналітики
Перше, що нам потрібно — встановити Google Tag. Це ідентифікатор Google Analytics, який пов’язує Ваш сайт з аналітикою.
У Tag Manager вибираємо тип тегу «Google Tag» і бачимо поле Tag ID. Де його взяти?
Переходимо на analytics.google.com і створюємо новий обліковий запис аналітики. Не буду детально зупинятися на процесі створення — там все інтуїтивно зрозуміло. Головне — дайте обліковому запису зрозумілу назву. Якщо напишете щось на кшталт «Тест для ГА4», потім будете довго шукати потрібний обліковий запис серед десятка схожих. Пошук у Google Analytics працює тільки за назвою, а не за ідентифікатором.
Після створення облікового запису переходимо до розділу «Адміністратор» і знаходимо пункт «Потоки даних». Клацаємо на потрібний потік — там побачите буквено-цифровий код формату G-XXXXXXXXX.
Копіюємо цей ідентифікатор і повертаємося в GTM. Вставляємо код в поле Tag ID.
У розділі Triggering вибираємо тригер «Initialization – All Pages» — саме так рекомендує робити офіційний гайд плагіна. Можна поставити і просто «All Pages», але краще дотримуватися інструкції.
Даємо тегу зрозумілу назву (наприклад, «GA4 – Config») і натискаємо «Зберегти».
Зверніть увагу: якщо довго возитися з налаштуваннями, GTM може повідомити, що дані застаріли. У такому випадку просто повторіть процедуру: скопіюйте ID заново, вставте, виберіть тригер і збережіть.
Де завантажити готовий контейнер для Google Tag Manager?
Повертаємося до інструкції плагіна. Нам потрібно завантажити template (шаблон контейнера). Не лякайтеся, все елементарно: клацаєте правою кнопкою миші в порожньому місці сторінки, вибираєте «Зберегти як» і зберігаєте файл. Готово — шаблон завантажиться в потрібному форматі JSON.
Тепер переносимо завантажений шаблон в наш GTM. Переходимо в розділ «Адміністратор», знаходимо пункт «Import container» і натискаємо «Choose container file». Вибираємо завантажений файл і натискаємо «Відкрити».
Далі система запитає, куди імпортувати — в нову робочу область чи існуючу. Оскільки наш Tag Manager поки що порожній, вибираємо «Existing» і вказуємо «Default Workspace».
Наступний крок — вибір способу імпорту:
Overwrite — повністю перезаписати контейнер
Merge — об’єднати з існуючими налаштуваннями
Якщо Ви щойно створили обліковий запис і там нічого немає — сміливо ставте «Overwrite». Якщо ж у Вас вже були якісь теги, які хочете зберегти — вибирайте «Merge». У цьому випадку система запропонує перейменувати конфліктуючі елементи або перезаписати дублі.
Після імпорту ви побачите, що в контейнері з’явилося багато всього: теги, тригери, змінні.
Чому ми робимо саме через імпорт, а не створюємо все вручну? Тому що це позбавляє від рутинної мавпячої роботи. У шаблоні близько 18 змінних, і кожну довелося б прописувати вручну. Сам процес нескладний: заходите в «New», вибираєте тип «Data Layer Variable» і вписуєте назву змінної.
Деякі змінні прості — наприклад, ecommerce.transaction_id. А деякі виглядають ось так: orderData.customer.billing.phone_hash. Вся «складність» — у монотонному копіюванні. Але коли таких змінних майже два десятки, імпорт готового контейнера GTM економить купу часу. Дві секунди — і все готово.
Редагування тегу GA4 – Подія
Важливий момент: якщо Ви перезаписали контейнер, то стерся і Google Tag, який ми створювали раніше. Таке буває, нічого страшного — просто потрібно виправити налаштування.
Знаходимо тег «GA4 – Event». Тут потрібно вказати ідентифікатор аналітики заново. Видаляємо старе значення, натискаємо «Плюсик», потім ще раз «Плюсик» біля Variable Configuration. Шукаємо тип змінної «Константа» і вставляємо туди ідентифікатор Вашої аналітики (той самий G-XXXXXXXXX).
Назву змінної можете задати будь-яку — хоч просто номер ідентифікатора. Після збереження обов’язково перевірте, чи з’явилася галочка «Google tag found in this container». Це підтвердження, що зв’язка працює.
Перевірка результатів роботи Google Tag Manager
Тепер переконаємося, що все налаштовано правильно. Копіюємо адресу нашого сайту, вставляємо в поле і натискаємо «Connect» для запуску режиму попереднього перегляду.
Перед перевіркою обов’язково вийдіть з адмінки WordPress — інакше дані можуть передаватися некоректно. Натискаємо Preview і починаємо тестувати: заходимо на сайт, відкриваємо картку товару, натискаємо «Купити», переходимо в кошик.
Що ми повинні побачити в режимі попереднього перегляду? У блоці «Теги» при наведенні на подію View_item має відображатися, що наш тег спрацював. Також можуть з’явитися кілька view_item_list — це залежить від теми сайту, іноді інформація дублюється. Пізніше ми це підчистимо.
Для детальної перевірки переходимо в Google Analytics, розділ «Відображення даних» → «DebugView». Події можуть з’явитися відразу або з затримкою в пару хвилин.
Клацаємо на View_item і перевіряємо наявність обов’язкових параметрів:
Value — вартість товару
Валюта — валюта
Елементи — дані про товар (Item_ID, Quantity тощо)
Зверніть увагу: у подіях view_item_list параметр Value може бути відсутнім, а в елементах будуть різні товари. Це нормально — такі події фіксують перегляд списку товарів, а не конкретної картки.
Далі натискаємо «Купити» і чекаємо появи події add_to_cart. У DebugView вона теж повинна містити Value, Currency та інформацію про доданий товар. Рекомендую повторити цю перевірку з декількома товарами — так Ви переконаєтеся, що передача даних працює стабільно.
Корекція відображення декількох View_item_list
Перш ніж робити тестове замовлення, розберемося з дублями подій. Пам’ятаєте, під час перевірки ми бачили 4 події view_item_list замість однієї? Це засмічує аналітику і спотворює дані. Виправимо це.
Заходимо в Google Tag Manager, відкриваємо розділ «Тригери» і видаляємо view_item_list із загального списку подій. Тепер створимо для нього окремий тег GTM.
Дублюємо існуючий тег для view_item_list. Налаштування залишаємо колишніми, але тригер змінюємо: видаляємо старий, натискаємо «Плюсик» → «Trigger Configuration», прокручуємо вниз і вибираємо «Custom Event». Вставляємо назву події, яку скопіювали раніше, і зберігаємо.
Важливий крок: переходимо в «Advanced Settings» (розширені налаштування) і вибираємо «Once per page». Тепер подія буде спрацьовувати тільки один раз на сторінку, без дублів.
Повторна перевірка результатів після налаштування View_item_list
Час протестувати все заново — тепер уже з повним циклом покупки. Робимо тестове замовлення: додаємо товар у кошик, переходимо в кошик, видаляємо одну позицію, оформлюємо замовлення до фінальної сторінки.
У режимі попереднього перегляду дивимося, які події спрацювали. Ось що ми можемо побачити:
view_cart — перегляд кошика (не дублюється — чудово!);
remove_from_cart — видалення товару;
begin_checkout — початок оформлення (може дублюватися);
add_shipping_info — додавання адреси доставки;
add_payment_info — вибір способу оплати;
purchase — покупка завершена.
Якщо begin_checkout дублюється — застосовуємо той самий прийом, що і з view_item_list: створюємо окремий тригер з налаштуванням «Once per page».
Переходимо в Google Analytics 4, розділ DebugView, і перевіряємо кожну подію. Особлива увага — події Purchase. У ній повинні бути:
Currency — правильна валюта;
Transaction_ID — номер замовлення (звірте з тим, що показує сайт);
Value — сума покупки;
Shipping — вартість доставки;
Items — список товарів з коректними ID.
Невеликі розбіжності в цифрах (наприклад, 99 замість 100) — це особливість передачі даних сайтом. При безкоштовному налаштуванні таке трапляється, і з цим доведеться змиритися.
Головне — переконайтеся, що ID товарів скрізь збігаються і жодна інформація не загубилася. Якщо все на місці — налаштування електронної комерції GA4 завершено успішно.
Усунення дублювання Begin_checkout
Залишився останній штрих — прибрати дублі події begin_checkout. Звертаю увагу: у Вас може дублюватися щось інше — view_item, add_to_cart або будь-яка інша подія. Принцип виправлення однаковий, просто не залишайте проблему «на потім».
Отже, begin_checkout дублюється. Що робимо? Заходимо в основний тег і прибираємо звідти begin_checkout. Потім дублюємо тег, даємо йому зрозумілу назву (наприклад, «GA4 – Begin_checkout»). Видаляємо старий тригер, створюємо новий типу Custom Event і прописуємо назву події. Не забуваємо про «Once per page» в розширених налаштуваннях.
На цьому налаштування Google Analytics 4 завершено. Всі цілі фіксуються коректно, без дублів.
Налаштування динамічного ремаркетингу
Але ми ще не закінчили. Якщо плануєте запускати Performance Max, варто довести до ладу динамічний ремаркетинг Google Ads. Його алгоритми машинного навчання працюють набагато ефективніше, коли отримують повні дані про поведінку користувачів на сайті.
Для початку потрібно встановити тег Google Ads. Заходимо в рекламний аккаунт, переходимо в розділ «Інструменти» → «Загальна бібліотека» → «Менеджер аудиторій». Відкриваємо вкладку «Ваші джерела даних» і знаходимо тег Google Ads. Якщо він ще не активований — там буде кнопка «Налаштувати».
Натискаємо «Деталі» → «Налаштування тегу» і вибираємо варіант «Використовувати Google Tag Manager». Копіюємо цифровий ідентифікатор.
Повертаємося в GTM, створюємо новий тег типу Google Tag, вставляємо скопійований ID. Тригер вибираємо «All Pages». Називаємо тег, наприклад, «Google Ads – ID».
Тепер налаштовуємо сам ремаркетинг. Створюємо ще один тег: «Tag Configuration» → «Google Ads» → «Google Ads Remarketing». Система запропонує створити Conversion Linker — погоджуємося, залишаємо налаштування за замовчуванням.
У полі Conversion ID вставляємо той самий ідентифікатор. Включаємо опцію «Send dynamic remarketing event data». Далі підтягуємо змінні, які створилися під час імпорту контейнера:
Event — назва події
Значення події → беремо «Значення електронної комерції»
Елементи → беремо «Елементи електронної комерції»
Перевіряємо, що google_business_vertical встановлений як «Retail» і префікс ID на місці.
У розділі Triggering вибираємо той самий принцип, що і для аналітики — тригер на події електронної комерції. Зберігаємо. Для дублюючих подій (begin_checkout, view_item_list) створюємо окремі теги за аналогією з тим, що робили раніше.
Перевірка переданих даних динамічного ремаркетингу
Для коректної роботи динамічного ремаркетингу Google Ads потрібно переконатися, що передаються чотири ключові події:
View_item — перегляд картки товару;
Add_to_cart — додавання до кошика;
Purchase — покупка;
View_item_list — перегляд списку товарів.
Запускаємо режим попереднього перегляду і переходимо на сайт. Іноді WordPress може видавати помилки або показувати, що чогось не існує, хоча хвилину тому все працювало. Це нормально — просто оновіть сторінку і спробуйте знову.
Відкриваємо картку товару і переходимо в розділ Variables в налагоджувачі GTM. Перевіряємо наші змінні: Ecommerce value і Ecommerce items повинні містити дані. При кліці на подію View_item бачимо набір параметрів — ідентифікатор товару, вартість, елементи з ID.
Однак є нюанс: змінна Event може показувати «undefined», хоча сама подія спрацьовує. Такі дрібні глюки — звичайна справа при роботі з безкоштовними інструментами.
Переробка тегу «Google Ads – rem – events»
Стандартний спосіб інтеграції, який пропонує розробник плагіна, не завжди працює стабільно. Тому переробимо тег ремаркетингу, щоб отримати більше контролю над передаваними даними.
Скільки дзвінків і продажів я отримаю замовивши у Вас контекстну рекламу?
Відкриваємо наш тег і вимикаємо опцію «Send dynamic remarketing event data». Замість автоматичної передачі задамо параметри вручну.
Які дані потрібно передати:
Event — назва події (задамо константою)
ID товару — для цього створимо окрему змінну
Google_business_vertical — залишаємо «Retail»
Для ID товару створюємо нову змінну типу Data Layer Variable з шляхом ecommerce.items.0.id. Ця конструкція витягує ідентифікатор першого товару з масиву. Перевіряємо, що змінна працює на всіх подіях електронної комерції, які нам потрібні.
Перевірка результатів налаштувань
Дивимося, що вийшло. У налагоджувачі бачимо подію view_cart — передаються ID товару з префіксом «gla_» і параметр google_business_vertical. Система може скаржитися на User Consent Mode, але, якщо Ваш бізнес не працює на ринок США або ЄС, це налаштування можна пропустити.
Перевіряємо змінну ecommerce.items.0.id — там повинен бути ідентифікатор з префіксом «gla_». Тепер найважливіше: заходимо в Google Merchant Center і шукаємо той самий товар. Якщо ID в Мерчанті збігається з тим, що передається з сайту — все налаштовано правильно. Це саме те, що потрібно для роботи динамічного ремаркетингу.
Всього ми передаємо три обов’язкові параметри: ID товару, Event і google_business_vertical. Це базовий набір, який вимагає Google. При бажанні можете додати Value (вартість) та інші параметри, але для запуску ремаркетингу цього буде достатньо.
Корекція дублювання View_item_list
Пам’ятаєте, view_item_list у нас дублювався? Пора це виправити і для тегу ремаркетингу.
Заходимо в тригер «Ecommerce Events» і дивимося, які події там вказані. Для ремаркетингу Google Ads принципово важливі тільки view_item, view_item_list і purchase. Решта подій (begin_checkout, add_to_cart) — приємне доповнення, але не критичні.
Видаляємо view_item_list із загального тригера і створюємо для нього окремий тег з налаштуванням «Once per page» — точно так само, як робили для GA4.
Перевірка спрацьовування тегу, доопрацювання
Запускаємо фінальну перевірку. Проходимо весь шлях користувача: картка товару → додавання до кошика → перегляд кошика.
Що бачимо в налагоджувачі? View_item_list спрацьовує кілька разів — значить, тригер ще не виправлений. View_item теж може дублюватися. У такому випадку прибираємо view_item із загального тригера і створюємо для нього окремий блок.
Після всіх правок перевіряємо знову. Тепер view_item — один раз, view_item_list — один раз, ніяких повторів. Це саме той результат, якого ми домагалися.
В ідеалі варто зробити ще одне тестове замовлення і переконатися, що подія purchase теж передається коректно — з правильними ID товарів і всіма необхідними параметрами. Якщо все на місці, вітаю: налаштування динамічного ремаркетингу WooCommerce завершено, і Google отримує саме ті дані, які йому потрібні для ефективної роботи рекламних кампаній.
Налаштування динамічного ремаркетингу
Переходимо до фінального етапу — активації динамічного ремаркетингу в рекламному кабінеті. Повертаємося в Google Ads, відкриваємо розділ Tools → Shared Library → Audience Manager. Знаходимо вкладку «Ваші дані» (Your data sources).
Тут шукаємо Google Ads tag і натискаємо «Set up». У налаштуваннях вибираємо опцію «Збирати дані про відвідувачів сайту для показу персоналізованої реклами». Оскільки у нас інтернет-магазин, у полі типу бізнесу вказуємо Retail.
Окремий пункт стосується вимог для Каліфорнії та Колорадо — це актуально тільки для ринку США. Якщо Ви працюєте в Україні або інших країнах, цю галочку можна не чіпати. Натискаємо Save and Continue.
На наступному кроці вибираємо Tag Manager як спосіб установки. Система покаже тільки Conversion ID — копіюємо його.
Тепер переносимо все в GTM. Створюємо новий тег: New → Tag Configuration → Google Ads → Google Ads Remarketing.
Вставляємо скопійований Conversion ID. Поле Label залишаємо порожнім — для ремаркетингу воно не потрібне.
Далі вибираємо, як передавати дані: автоматично з рівня даних (Dynamic) або вручну (Manual). Покажу динамічний варіант — він простіший.
Налаштовуємо параметри:
Event — вибираємо готову змінну {{Event}}.
Event value — тут потрібно вказати вартість. Щоб зрозуміти, звідки її брати, загляньте в Data Layer при подіях purchase або view_item. Там побачите параметр Ecommerce value без вкладених рівнів — його і вибираємо.
Event items — ця змінна збирає дані про товари: ID з потрібним префіксом і google_business_vertical. Завдяки плагіну Томаса Гейгера весь набір вже готовий, тому просто вибираємо Ecommerce Items.
Переходимо до Advanced Settings. Тут важливий момент з Consent Mode: якщо Ваш бізнес не працює на ЄС або окремі штати США (Каліфорнія, Колорадо), це налаштування можна пропустити. Для України Consent Mode не потрібний.
Зберігаємо тег і переходимо до тестування — потрібно переконатися, що всі дані передаються коректно.
Вибір тригерів
Переходимо до налаштування тригерів GTM. Тут можна піти різними шляхами: або передавати всі події поспіль, або вибрати тільки потрібні.
Якщо вирішите відправляти все — нічого критичного не станеться. Але фактично Google Ads вимагає лише п’ять обов’язкових подій:
View_item — перегляд картки товару;
View_item_list — перегляд категорії або лістингу;
Add_to_cart — додавання до кошика;
View_search_result — перегляд результатів пошуку;
Purchase — покупка.
Решта подій (remove_from_cart, view_cart, begin_checkout) для ремаркетингу Google Ads не є принциповими.
Якщо хочете передавати тільки необхідну інформацію, створюємо кастомний тригер: натискаємо «Плюсик» → Trigger Configuration → Custom Event. У полі вписуємо назви подій через вертикальну риску: view_item|add_to_cart|purchase|view_item_list|view_search_results.
Щоб дізнатися точну назву події view_item_list для Вашого сайту, зайдіть в будь-який розділ каталогу і подивіться в налагоджувачі, яка подія спрацьовує. Скопіюйте її звідти — так точно не помилитеся. Те ж саме з view_search_result: введіть що-небудь в пошук на сайті і знайдіть потрібну подію в Data Layer.
Зберігаємо тригер і називаємо його зрозуміло, наприклад «Remarketing Events».
Перевірка правильності передачі даних
Фінальний етап — переконатися, що налаштування ремаркетингу WooCommerce працює коректно. Проходимо повний шлях користувача: каталог → картка товару → додавання до кошика → пошук → оформлення замовлення до сторінки «Дякуємо за покупку».
Відкриваємо Summary в налагоджувачі GTM. Бачимо, що тег ремаркетингу спрацював 14 разів — забагато, але зараз розберемося. Частина спрацьовувань припадає на дублюючі view_item_list — це виправимо пізніше.
Головне — перевірити, що в кожній події передаються потрібні параметри. Клацаємо на view_item_list: у даних мають бути ID товарів і google_business_vertical. Є? Чудово.
Переходимо до view_item — та сама перевірка: ID і business_vertical на місці. Це саме те, що потрібно для роботи динамічного ремаркетингу.
Перевіряємо add_to_cart — тут теж повинен передаватися повний набір даних про додані товари. І фінальна точка — подія purchase. Вона повинна бути одна (без дублів) і містити інформацію про куплені товари.
Якщо десь події дублюються — повертаємося до тригерів і застосовуємо вже знайомий прийом з налаштуванням «Once per page».
Коригування правильності передачі даних
Тепер наведемо порядок у подіях для динамічного ремаркетингу. Відкриваємо тригер на редагування і прописуємо всі п’ять обов’язкових подій через Custom Event:
переглянути_елемент;
Додати до кошика
придбання;
переглянути_список_елементів;
перегляд_результатів_пошуку.
Розділяємо їх вертикальною рискою. Плагін Томаса Гейгера вже створив усі необхідні події, включаючи Site Search — залишається тільки зібрати їх в один тригер. Перераховуємо: 1, 2, 3, 4, 5 — повний комплект. Називаємо тригер зрозуміло, наприклад «Events – rem», і зберігаємо.
Важливий момент: не забудьте поставити галочку «Use regex matching». Без неї тригер не розпізнає події, перераховані через вертикальну риску. Такі дрібниці легко пропустити, особливо коли довго возишся з налаштуваннями.
Ще одна рекомендація — для подій типу view_item_list додайте обмеження «Once per page» в розширених налаштуваннях тригера. Краще передавати менше даних, але якісних, ніж засмічувати аналітику дублями.
Повторна перевірка правильності передачі даних
Запускаємо фінальне тестування. Натискаємо Preview і проходимо весь шлях користувача: відкриваємо картку товару, додаємо в кошик, вводимо щось у пошук, заходимо в каталог, переходимо в кошик і оформлюємо замовлення до кінця.
Відкриваємо Summary в налагоджувачі і дивимося результат. Тег ремаркетингу Google Ads спрацював — і тепер спрацьовувань помітно менше, ніж було раніше. Ніяких зайвих дублів, тільки потрібні події.
Перевіряємо кожну подію: view_item, add_to_cart, view_item_list, view_search_result, purchase. Скрізь повинні передаватися ID товарів з правильним префіксом і параметр google_business_vertical. Якщо все на місці — налаштування динамічного ремаркетингу WooCommerce завершено успішно, і Ваші рекламні кампанії отримають всі дані для ефективної роботи.
Налаштування окремої передачі Add_to_cart
Перевіряємо всі події — і виявляємо, що add_to_cart чомусь не спрацював. Такі нюанси трапляються, нічого критичного. Заходимо в тригер, дивимося — подія прописана правильно. Значить, справа в чомусь іншому.
Рішення просте: прибираємо add_to_cart із загального тригера і створюємо для нього окремий тег. Відкриваємо існуючий тег ремаркетингу, натискаємо Copy. У копії залишаємо тільки add_to_cart, видаляємо старий тригер і створюємо новий Custom Event спеціально для цієї події. Зберігаємо.
Перезавантажуємо сторінку — іноді інтерфейс Google просто глючить. Запускаємо Preview і перевіряємо. Тепер в Summary бачимо: add_to_cart спрацював один раз. Чудово!
Але є нюанс: у даних може передаватися кілька товарів замість одного. Чому з’являються ID 4010, 4004, 4023, хоча додавали тільки один товар? Часта причина — Ви не вийшли з адмінки WordPress. Це не баг самого сайту, а особливість роботи Google. Просто вийдіть з облікового запису і повторіть тест.
Якщо після цього в add_to_cart все одно зникає кілька позицій, створюємо нову змінну. Заходимо в Variables → New → Data Layer Variable і прописуємо шлях cartContent.items. Це витягне дані саме про доданий товар.
Те саме стосується суми: якщо value не збігається з ціною товару, візьміть змінну cartContent.total. Перевіряємо: value показує 855 — це відповідає вартості доданого товару. Отже, все працює коректно.
Перевірка та редагування тегів за View_item
Тепер з такою ж увагою перевіряємо інші події. View_item — одна позиція, спрацювала правильно.
А ось view_item_list знову може дублюватися. Щоб цього уникнути, виносимо його в окремий тег: копіюємо існуючий, в тригері вказуємо тільки view_item_list, в розширених налаштуваннях ставимо «Once per event» або «Once per page». З основного тригера цю подію прибираємо.
View_item — ремаркетинг спрацював, одна позиція. Супер!
View_item_list — спрацював один раз, дані передаються. Чудово!
Add_to_cart — одна позиція, value 855. Ідеально!
Site Search — подія спрацювала, але дані не передаються.
З пошуком розберемося окремо, а основні події динамічного ремаркетингу Google Ads вже налаштовані і працюють як треба.
Редагування та перевірка події Site Search
Виявили, що Site Search не передає дані. Таке буває — іноді доводиться вносити додаткові корективи, щоб все запрацювало як треба.
Перевіряємо подію: називається view_search_result — це правильно. Проблема в тому, звідки беруться items і value. Стандартні змінні не підхоплюють дані, тому створюємо нові.
Для value прибираємо поточну змінну, натискаємо «Плюсик» і створюємо нову типу Data Layer Variable. Прописуємо шлях cartContent.totals — це витягне суму з потрібного місця в коді.
Для items робимо те саме: створюємо змінну cartContent.items. Якщо така вже існує — просто використовуємо її. Зберігаємо зміни.
Запускаємо Preview і проходимо тестовий шлях: додавання в кошик → каталог → пошуковий запит. Так, перевірка займає час, але краще переконатися, що все працює коректно, ніж потім розбиратися, чому ремаркетинг Google Ads не збирає аудиторії.
Дивимося Summary:
Search_result — спрацював один раз. Чудово!
View_item_list — п’ять спрацьовувань, це можна виправити.
Add_to_cart — один раз, як і має бути.
Purchase — є, одна позиція з чотирма одиницями товару (це правильно — ми замовили чотири штуки одного товару).
У GA4 дані теж відображаються коректно: чотири штуки однієї позиції. Все сходиться.
Редагування ремаркетингу
Залишився останній штрих — очистити основний тег ремаркетингу від зайвих подій. Із загального тригера прибираємо add_to_cart і view_search_result, оскільки для них уже створено окремі теги. В основному тригері залишаємо тільки view_item і purchase.
Підбиваємо підсумок: тепер у нас налаштовані всі п’ять обов’язкових подій для динамічного ремаркетингу WooCommerce:
View_item — перегляд картки товару;
Purchase — покупка;
Add_to_cart — додавання до кошика;
View_item_list — перегляд категорії;
View_search_result — результати пошуку.
Кожна подія спрацьовує один раз, без дублів, і передає правильні дані: ID товарів з потрібним префіксом і параметр google_business_vertical. Це саме те, що потрібно для запуску Performance Max і ефективної роботи рекламних кампаній.
Підбиття підсумків — що налаштовано
Ви можете ще раз пройти весь шлях користувача і переконатися, що динамічний ремаркетинг працює коректно. Якщо в налагоджувачі GTM всі події спрацьовують по одному разу і передають потрібні дані — значить, все зроблено правильно.
Тепер в Google Ads почнуть автоматично формуватися аудиторії. Зайдіть в розділ джерел даних — там вже з’явилися списки ремаркетингу. Спочатку вони будуть порожніми, але протягом декількох годин інформація підтягнеться, і система почне збирати відвідувачів Вашого сайту.
Що ми налаштували за підсумком:
Google Analytics 4 — повноцінна електронна комерція з усіма подіями.
Тег покупки — конверсія для відстеження замовлень.
Динамічний ремаркетинг Google Ads — п’ять обов’язкових подій для повернення відвідувачів.
Залишилося пов’язати сервіси між собою, щоб дані передавалися коректно і Performance Max отримав доступ до всієї інформації.
Поєднання Google Ads з Merchant Center
Для повноцінної роботи товарних кампаній необхідно пов’язати Merchant Center з Google Ads. Переходимо в рекламному кабінеті в розділ Data Manager і шукаємо підключення до Мерчанту.
Якщо там вказано неправильний обліковий запис — натискаємо Unlink і від’єднуємо його. Потім натискаємо «Плюсик», вибираємо потрібний Merchant Center (звіряйте за назвою або доменом) і підтверджуємо зв’язок кнопкою Submit.
Перевіряємо коректність підключення: в Data Manager повинен відображатися правильний домен Вашого магазину.
Тепер заходимо в сам Merchant Center, розділ «Діагностика». Якщо бачите повідомлення, що обліковий запис Google Ads не підключений — переходьте в «Linked Accounts» → «Google Ads». Переконайтеся, що номер облікового запису збігається з Вашим рекламним кабінетом. Через деякий час помилка зникне.
У діагностиці також можна відстежити, як товари з фіду проходять модерацію. Після зв’язки Merchant Center і Google Ads позиції почнуть завантажуватися і йти на перевірку — це нормальний процес, який займає від декількох годин до пари днів.
Поєднання аналітики з Google Ads
Останній крок — підключити Google Analytics 4 до рекламного кабінету. Навіщо це потрібно? Щоб усі сервіси обмінювалися даними і Performance Max бачив повну картину поведінки користувачів.
Переходимо в аналітику, розділ «Адміністратор», знаходимо пункт «Зв’язок з Google Ads» і натискаємо «Пов’язати». Вибираємо потрібний рекламний аккаунт — якщо він один, система підтягне його автоматично.
Якщо обліковий запис не відображається в списку, перевірте доступ: Ваша пошта повинна мати адміністративні права у всіх трьох сервісах — Merchant Center, Google Ads і Google Analytics. Це часта причина, чому зв’язок не працює.
Залишаємо увімкненою опцію «Enable auto-tagging» — вона дозволяє автоматично розмічати трафік з реклами. Підтверджуємо і зберігаємо. За необхідності ці налаштування можна змінити пізніше.
Налаштування передачі конверсій
Залишився ще один момент. Оскільки ми налаштовували передачу даних через GTM для WooCommerce, потрібно вказати це в налаштуваннях конверсій.
Заходимо в Google Ads → Конверсії → Settings. У полі джерела вибираємо Google Tag Manager і зберігаємо. Тепер система знає, звідки отримувати інформацію про покупки.
Підсумки
Давайте перевіримо чек-лист того, що ми зробили:
Цілі в GA4 — налаштовані, всі події електронної комерції передаються коректно.
Динамічний ремаркетинг Google Ads — працює, п’ять обов’язкових подій спрацьовують без дублів.
Пов’язування Merchant Center з Google Ads — виконано.
Поєднання Google Analytics з Google Ads — виконано.
Налаштування конверсій — джерело вказано правильно.
Базова підготовка завершена. Тепер потрібно дочекатися, поки товари в Merchant Center пройдуть модерацію — зазвичай це займає від декількох годин до двох-трьох днів. Після цього можна переходити до створення рекламних кампаній. Про це — в наступному матеріалі.
