Звіт GA4 показує, що з тих, хто почав оформлення, купує лише частина, але він не пояснює, де саме і чому покупці зникають. До того ж частина цих «втрат» взагалі не є втратами. Людина оплатила на сторінці LiqPay чи monobank і закрила вкладку, тому подія покупки не дійшла до аналітики. Нижче описано, як налаштувати воронку чекауту WooCommerce в GA4, звірити її з базою замовлень і відрізнити реальне відпадання від помилки вимірювання.

Скільки покупців кидають кошик у середньому

Baymard Institute зібрав 50 досліджень, опублікованих з 2006 по 2025 рік, і середній показник кинутих кошиків у них становить 70,22% при діапазоні від 55% до 84% (Baymard, Cart Abandonment Rate). У тому ж опитуванні 42% американських покупців кидали кошик, бо просто роздивлялися. Серед решти найчастіші причини такі:

додаткові витрати на доставку, податки чи комісії виявилися завеликими (40%);
доставка надто довга (20%);
покупець не довіряв сайту дані картки (19%);
сайт вимагав створити акаунт (18%);
оформлення було задовгим або складним (17%);
на сайті сталася помилка (17%);
картку відхилили (10%).

Ці цифри зібрано в США, тож для українського магазину вони працюють як перелік гіпотез. Яка з них спрацьовує саме у вас, показує тільки воронка, розбита по кроках.

Які події має надсилати магазин

GA4 має готовий звіт «Шлях оформлення замовлення» (Checkout journey) у розділі «Життєвий цикл → Монетизація». Якщо його немає в меню, адміністратор ресурсу додає звіт через «Бібліотеку». Звіт будується з чотирьох подій (довідка Google Analytics):

Крок	Подія GA4	Коли спрацьовує у WooCommerce
Початок оформлення	`begin_checkout`	Відкрилася сторінка чекауту
Доставка	`add_shipping_info`	Покупець обрав спосіб доставки
Оплата	`add_payment_info`	Покупець обрав спосіб оплати
Покупка	`purchase`	Завантажилася сторінка «Дякуємо за замовлення»

Воронка в цьому звіті закрита, тобто враховує лише тих, хто почав з першого кроку. Якщо між begin_checkout і purchase немає двох проміжних подій, ви бачите один великий провал без жодних деталей.

Офіційний плагін Google Analytics for WooCommerce почав надсилати add_shipping_info і add_payment_info лише з версії 2.2.0 від червня 2026 року, а остання версія 2.4.4 вимагає WooCommerce 11.1 або новішої (changelog плагіна). Магазин, який давно не оновлював WooCommerce, ці дві події не отримує. Те саме стосується інтеграцій через GTM, які колись налаштували лише на покупку.

Перевіряється це за п'ять хвилин. Відкрийте Google Tag Assistant, введіть адресу магазину і пройдіть чекаут до вибору оплати. У списку подій мають з'явитися begin_checkout, add_shipping_info і add_payment_info, а після тестового замовлення ще й purchase.

Чому покупки «губляться» на кроці оплати

Найбільший провал зазвичай видно між add_payment_info і purchase, і саме тут найбільше помилок вимірювання. Плагін рахує покупку тільки тоді, коли покупець після оплати повернувся на сторінку подяки. Документація WooCommerce прямо пише, що для відстеження покупок потрібен платіжний шлюз, який переадресовує на цю сторінку (Google Analytics for WooCommerce).

LiqPay і monobank повертають покупця на сайт через параметри result_url і redirectUrl, а статус оплати надсилають окремим запитом із сервера на сервер через server_url і webHookUrl (LiqPay API, monobank API). Оплаченим замовлення в базі робить серверний запит, а подія в GA4 з'являється лише після повернення покупця. Stripe у своїй документації окремо попереджає, що відвідування сторінки після оплати не гарантоване, бо покупець може оплатити і втратити зв'язок до її завантаження (Stripe Docs).

Ще три причини розбіжностей:

Повернення з платіжного домену GA4 записує як новий візит з джерелом liqpay.ua чи monobank.ua, і продаж приписується платіжці замість реклами. Ці домени треба додати в список небажаних рефералів. Google наводить платіжні системи як основний приклад для цього налаштування (довідка GA4).
До версії 2.4.4 плагін надсилав purchase і для замовлень зі статусом «Не вдалося» чи «Скасовано». Тоді в GA4 потрапляли покупки, яких насправді не було.
З версії 2.4.1 плагін рахує дохід як суму товарів без податку і доставки, тому дохід у GA4 буде меншим за суму замовлень в адмінці. Це очікувана розбіжність.

Звірте воронку з базою замовлень

Остаточну відповідь дає база WooCommerce. У магазинах, встановлених на WooCommerce 8.2 і новіших, замовлення за замовчуванням зберігаються в таблиці wc_orders (документація HPOS). Запит нижче групує замовлення за останні 30 днів за статусом і способом оплати. Префікс wp_ замініть на свій:

SELECT status,
       payment_method_title,
       COUNT(*)                 AS orders,
       ROUND(SUM(total_amount)) AS amount
FROM wp_wc_orders
WHERE type = 'shop_order'
  AND status <> 'wc-checkout-draft'
  AND date_created_gmt >= NOW() - INTERVAL 30 DAY
GROUP BY status, payment_method_title
ORDER BY payment_method_title, orders DESC;

Статус wc-pending («Очікує оплати») при онлайн-оплаті означає, що покупець заповнив форму, натиснув «Оформити», потрапив на сторінку платіжки і не заплатив. Це реальна втрата на кроці оплати, і частину таких замовлень можна повернути листом чи дзвінком. wc-failed означає, що банк відхилив оплату. Якщо таких замовлень багато в одного методу, шукайте проблему в налаштуваннях шлюзу або 3-D Secure, дизайн сторінки тут ні до чого. Чернетки блочного чекауту зі статусом wc-checkout-draft запит не враховує.

Далі порівняйте оплачені замовлення з покупками в GA4. У розділі «Дослідження» створіть таблицю довільної форми з виміром «Ідентифікатор транзакції» за той самий період і експортуйте її в CSV. Плагін передає як transaction_id номер замовлення, і він збігається з ID, якщо у вас не стоїть плагін власної нумерації. Оплачені замовлення (wc-processing і wc-completed) вивантажте з бази в CSV з колонками id і payment_method_title. Скрипт покаже, скільки оплачених замовлень кожного методу не дійшли до GA4:

import csv, sys
from collections import Counter

# python compare.py orders.csv ga4_transactions.csv
ga4 = set()
with open(sys.argv[2], encoding='utf-8-sig') as f:
    for row in csv.reader(f):
        if row and row[0].strip().isdigit():
            ga4.add(row[0].strip())

total, missing = Counter(), Counter()
with open(sys.argv[1], encoding='utf-8-sig') as f:
    for row in csv.DictReader(f):
        method = row['payment_method_title']
        total[method] += 1
        if row['id'] not in ga4:
            missing[method] += 1

for method, n in total.most_common():
    print(f'{method:30} paid {n:5}  not in GA4 {missing[method]:5}  ({missing[method] / n:.0%})')

Буває, що накладений платіж майже весь видно в GA4, а онлайн-оплата втрачає помітну частку. Тоді причина в поверненні з платіжної сторінки, провал між add_payment_info і purchase у звіті завищений, і переробляти через нього дизайн чекауту не варто.

Щоб покупка потрапляла в GA4 незалежно від повернення покупця, її треба надсилати з сервера в момент, коли приходить підтвердження від LiqPay чи monobank. Для цього є Measurement Protocol. Google описує його як доповнення до тегу на сайті, а не заміну, і з'єднує серверні події з візитом через client_id (документація Measurement Protocol). Магазин має зберегти client_id із cookie в замовленні під час оформлення, а обробник вебхука надіслати purchase з тим самим transaction_id. GA4 відкидає дублікати покупок з однаковим ідентифікатором транзакції (довідка GA4), тому подвійного рахунку не буде, навіть якщо покупець таки повернеться на сторінку подяки.

Цю частину ми радимо доручити розробнику, бо помилка у вебхуку може зламати облік оплат разом зі статистикою. Якщо у вас WooCommerce з LiqPay чи monobank і цифри GA4 не сходяться з адмінкою, ми налаштуємо серверне відстеження покупок так, щоб воронка показувала реальні втрати.

Як побудувати власну воронку з розбивкою

Готовий звіт не можна розбити за пристроєм чи способом оплати. Для цього в GA4 відкрийте «Дослідження → Дослідження послідовності» і зробіть таке:

Додайте кроки add_to_cart, begin_checkout, add_shipping_info, add_payment_info і purchase саме в такому порядку.
Залиште воронку закритою, щоб рахувати тільки тих, хто пройшов кроки по порядку. Відкрита воронка корисна, коли частина покупців потрапляє в чекаут кнопкою «Купити в один клік», минаючи кошик (довідка про дослідження послідовності).
У полі «Розбивка» оберіть «Категорія пристрою». Різниця між мобільними і десктопом на кроці доставки зазвичай вказує на незручну форму на телефоні.
Збережіть копію дослідження з розбивкою за параметром payment_type події add_payment_info. Перед цим зареєструйте його як спеціальний вимір у налаштуваннях ресурсу, інакше в списку розбивок його не буде.

Що означає провал на кожному кроці

Де падає	Ймовірна причина	Що перевірити
Кошик → початок оформлення	Неочікувана вартість, вимога реєстрації	Чи видно вартість доставки до чекауту; чи можна оформити без акаунта
Початок оформлення → доставка	Довга форма, незручний вибір відділення на телефоні	Кількість полів; пошук відділення Нової Пошти з мобільного
Доставка → оплата	Ціна доставки або термін виявилися несподіваними	Як змінюється підсумок після вибору доставки
Оплата → покупка	Відмова банку, помилка шлюзу, або покупка не дійшла до GA4	Замовлення `wc-pending` і `wc-failed` у базі, звірка з транзакціями GA4

Типові помилки

Робити висновки з воронки, де між початком оформлення і покупкою немає проміжних подій.
Не додати домени платіжних систем у небажані реферали і вважати платіжку джерелом продажів.
Порівнювати дохід у GA4 з сумою замовлень в адмінці, забуваючи, що плагін не рахує доставку і податок.
Переробляти дизайн чекауту, коли значна частина «втрат» на кроці оплати є покупками, що не дійшли до аналітики.
Тримати ecommerce-теги в GTM і плагін одночасно. Покупки GA4 відсіє за transaction_id, а add_to_cart і begin_checkout порахує двічі, і пропорції воронки зсунуться.

Якщо відпадання підтвердилося на кроці доставки чи оплати, далі йде технічна робота. Про платіжні шлюзи для WooCommerce читайте у статті про інтеграцію Нової Пошти, LiqPay і monobank, а про швидкість мобільного чекауту в гайді з Core Web Vitals для магазину.

Часті запитання

Чому в GA4 покупок менше, ніж замовлень в адмінці WooCommerce?

Найчастіше покупець оплатив на сторінці платіжної системи і не повернувся на сторінку подяки. Також події блокують розширення браузера, а частину замовлень менеджери оформлюють вручну. Звірте ідентифікатори транзакцій GA4 із замовленнями в базі, щоб побачити, який спосіб оплати втрачає події.

Яка нормальна частка кинутих кошиків?

Baymard називає середнє значення 70,22% за 50 дослідженнями з розкидом від 55% до 84%. Корисніше стежити за динамікою власного показника після кожної зміни в чекауті.

Чи потрібен Tag Manager, якщо стоїть плагін Google Analytics for WooCommerce?

Для базової воронки досить плагіна версії 2.2.0 або новішої. GTM потрібен, коли ви хочете додаткові події, наприклад помилки валідації форми, або коли теги реклами мають спрацьовувати на ті самі події.

Чи можна відстежувати покупки без повернення на сайт?

Так, через Measurement Protocol із сервера в момент отримання вебхука від платіжної системи. Подію треба надсилати з тим самим transaction_id і client_id покупця, тоді GA4 приєднає її до візиту і не порахує двічі.

Перевіримо ваш чекаут і аналітику

Надішліть адресу магазину. Ми пройдемо чекаут з телефона і десктопа, перевіримо, які події доходять до GA4, і скажемо, на якому кроці ви реально втрачаєте покупців, а де бачите похибку вимірювання. Налаштування GA4 і Tag Manager у нашому прайсі є окремою опцією за $290, деталі на сторінці цін.

Про доопрацювання і розробку магазинів читайте в розділі інтернет-магазини. Написати нам можна через форму на сайті або в Telegram.

Де покупці кидають чекаут WooCommerce і як це виміряти