Стаття · Аналітика
Подія оплати в GA4 рахувала кліки по кнопці: чекліст аудиту подій
На сайті вакансій 2 із 9 ключових подій GA4 рахували не те, що вказано в їхніх назвах: на кожну оплачену вакансію припадало 14 подій «оплата вакансії». Чекліст звіряє кожну подію з тим записом у базі, який обіцяє її назва.
У вересні я перевірив усі події, які happymonday.ua надсилає в GA4: 38 назв подій, 38 тегів подій у Google Tag Manager і дані в BigQuery з 29 липня до 25 вересня 2026 року. Потім я порівняв їх із базою даних сайту. Основні цифри зійшлися: відгуки на вакансії, переходи на сайти роботодавців, реєстрації, заявки компаній. Але дві з дев’яти ключових подій не зійшлися. Вони спрацьовували щоразу, але рахували не те, що було вказано в назві.
Подія «оплата вакансії» була кліком по кнопці «Опублікувати» або «Зберегти» у формі вакансії, зокрема й під час редагування. На кожну оплачену вакансію в базі даних у GA4 припадало близько 14 таких подій. Подія «купівля гайду» спрацьовувала на кожній сторінці «Дякуємо за оплату», а 84% цих подій були оплатами вакансій.
Перевірка тегів цього не покаже. Теги спрацьовували, запити доходили до GA4, у звітах були цифри. Потрібно вдруге порахувати ту саму дію в базі даних, платіжній системі або CRM. Далі — чекліст, яким я для цього користуюся, і помилка за кожним пунктом. Перший аудит цього сайту, під час якого я знайшов подвійний підрахунок усіх реєстрацій, описаний в окремому кейсі.
Один коефіцієнт сортує події
Для кожної події, якій відповідає запис у базі даних, я поділив кількість подій у GA4 на кількість записів за ті самі дні. Подія в браузері втрачає частину запитів через блокувальники реклами та вкладки, які закрили раніше, ніж запит пішов. Тому коефіцієнт справної події трохи нижчий за 1. За тиждень 19–25 вересня для відгуків на вакансії він становив 0,96, а для переходів на сайти роботодавців — 0,95. Для заявок компаній за два місяці — 0,99.
Подій у GA4 на один запис у базі
Підписки на вакансії 0, купівлі книжки 0,93, переходи на сайти роботодавців 0,95, відгуки на вакансії 0,96, заявки компаній 0,99, «оплата вакансії» 13,9, «купівля гайду» 14,9.
На несправну подію вказують два типи значень. Якщо значення вище за 1, подія рахує іншу дію або ту саму дію кілька разів. Нуль означає, що вона більше не спрацьовує. У звіті за однією подією обидва значення мають вигляд звичайних цифр, але в одному ряду коефіцієнтів одразу впадають в око.
Для коефіцієнта потрібен запис, із яким можна порівняти подію. Якщо події не відповідає жоден рядок у жодній базі даних, це клік або перегляд, і назва має це відображати. У серпні подія «відгук» була кліком по кнопці «Відгукнутися», яка лише відкриває форму: на кожні 100 таких кліків у базі даних було 56 відгуків.
Другий підрахунок теж потрібно перевірити. Внутрішній дашборд сайту показував близько двох третин реєстрацій компаній, бо рахував лише компанії, які потім заповнили налаштування. У таблиці користувачів були всі.
Що рахували дві події оплати
Тег «оплата вакансії» спрацьовував після натискання кнопки, яка надсилає форму вакансії. Ця сама кнопка зберігає зміни, тому за один тиждень вересня третина таких подій припадала на редагування, а дві третини — на нові вакансії, оплачені чи ні. Сума була порожньою в кожній події, тому ні GA4, ні пов’язані облікові записи Google Реклами не бачили доходу.
Сайт уже надсилав правильний сигнал. На сторінці подяки за оплачене замовлення він передавав на рівень даних подію оплати з типом продукту, але жоден тег у контейнері її не відстежував.
Подія «купівля гайду» чекала на сторінку подяки, спільну для всіх продуктів сайту.
Що записувала подія «купівля гайду»
Оплати вакансій 84%, купівлі книжки 8%, купівлі гайду 8%.
Перезавантаження сторінки додавали ще: одне замовлення порахували сім разів. Події на спільній сторінці потрібні дві умови: її продукт і один підрахунок на номер замовлення.
Тег, який мовчав рік
За 59 днів у даних не було жодної події від тегу сповіщень про вакансії. Востаннє ця подія з’являлася в GA4 29 вересня 2025 року. Тригер чекав на клік по кнопці з певним текстом і класом стилів. На сайті кнопка вже мала інший текст та інший клас, і тег замовк без жодної помилки.
Ще вісім із 38 тегів подій за 59 днів спрацювали не більше двох разів. Одні чекали на події, які сайт більше не надсилає, інші — на кліки в кампаніях, що вже завершилися. Жоден із них не змінює цифр у звітах, але кожен ускладнює читання контейнера.
Одна подія надходила не з контейнера й не з коду сайту. Її створювало правило в самому GA4 у розділі «Адміністратор → Відображення даних → Події → Створити подію», яке перетворювало перегляд однієї сторінки на окрему подію. У ресурсі було п’ять таких правил, і за рік спрацювало лише це.
Повтори, неможливі пари й надто широкі селектори
Подія закриття спливного вікна з обмеженням на читання статей рахувала кожен клік. У вересні 17% закриттів були повторними на тій самій сторінці, до 26 на одній сторінці. У два дні закриттів було більше, ніж показів. Закриттів не може бути більше за покази, як і покупок більше за переходи до оплати. Тому така пара дає змогу швидко перевірити будь-яку воронку.
Тригер показів промокарток в одному розділі сайту також спрацьовував на картках стрічки новин і спецпроєктів на тій самій сторінці. На них припадало 10% показів карток розділу, зокрема в позиціях 1–3, тому фільтр за позицією у звітах їх не прибирав.
П’ять параметрів надходили разом із подіями, але їх не зареєстрували як спеціальні параметри, тому жоден звіт не міг їх показати. Сигнал про реєстрацію також містив UTM-мітки і джерело переходу, але тег їх не передавав.
Як ми виправили події й не зламали Google Рекламу
Ресурс GA4 пов’язаний із трьома обліковими записами Google Реклами. Якщо Google Реклама імпортує ключову подію як конверсію, зміна її тригера того самого дня впливає на те, під що оптимізуються кампанії. Тому пакет виправлень не змінював тригерів старих ключових подій. Ми додали поруч правильні: успішну оплату за сигналом зі сторінки подяки, купівлю гайду лише для гайду й сповіщення про вакансію на екрані, який підтверджує його збереження. Закриття спливного вікна тепер рахується один раз на сторінку, тригер промокарток зчитує лише свій блок, а параметри зареєстровані.
Пакет опублікували 13 жовтня. У перший день нова подія оплати залишалася нижче за кількість оплачених замовлень, а стара записала вдвічі більше подій, ніж було замовлень. Джерело переходу надійшло з 64% реєстрацій, а UTM-мітки — із 26%. Ключові події переведуть на нові після двох тижнів такого порівняння.
Нові події теж мають обмеження. Замовлення, оплачені за рахунком, ніколи не відкривають сторінку подяки, тому подія оплати їх не бачить. Для них сайт має надсилати подію із сервера, коли замовлення позначають як оплачене. Подія сповіщення про вакансію бачить сповіщення, створені на сторінці пошуку, але не ті, які створили прапорцем у формі відгуку.
Деякі знахідки залишилися без змін. Сторонні хости, зокрема тестова копія сайту й Google Перекладач, надіслали в бойовий ресурс 0,05% сеансів за тиждень. Щоб їх відфільтрувати, довелося б додати блокувальний тригер приблизно до 40 тегів, а це більший ризик, ніж такий шум. Втрата близько 5% подій для відгуків і переходів на сайти роботодавців стабільна щодня, що зазвичай вказує на блокувальники реклами. Загальні обсяги все одно беремо з бази даних.
Чекліст аудиту подій GA4
Почніть із перших двох пунктів. Для них потрібні експорт кількості подій і кілька запитів до бази даних. Вони покажуть, які події варто перевірити докладніше.
| Перевірка | Що робити | Яка помилка за цим стоїть |
|---|---|---|
| Назва й запис | Біля кожної події вкажіть запис у базі даних, якому вона відповідає. Якщо запису немає, це клік або перегляд, і назва має це відображати. | «Оплата вакансії» була кліком по кнопці «Опублікувати», зокрема під час редагування. «Відгук» лише відкривав форму. |
| Подій на запис | Поділіть кількість подій GA4 на кількість записів у базі даних за ті самі дні. Значення трохи нижче за 1 означає втрату. Нуль або значення значно вище за 1 — помилку. | 14 «оплат вакансії» на одну оплачену вакансію і 15 «купівель гайду» на один оплачений гайд. |
| Спільні сторінки | Подія на сторінці, спільній для кількох продуктів, має містити умову для свого продукту. | 84% «купівель гайду» були оплатами вакансій. |
| Один підрахунок | Оплати рахуються один раз на номер замовлення, події інтерфейсу — один раз на сторінку. | Одне замовлення порахували сім разів. 17% закриттів спливного вікна були повторними. |
| Неможливі пари | Порівняйте сусідні кроки воронки: закриттів має бути не більше за покази, покупок — не більше за переходи до оплати. | У два дні спливне вікно мало більше закриттів, ніж показів. |
| Мовчазні теги | Щомісяця складайте список тегів без подій за 60 днів і перевіряйте кожен тригер на робочій сторінці. | Тег сповіщень про вакансії мовчав рік після зміни кнопки. |
| Спочатку рівень даних | Запускайте тег за подією на рівні даних, яку сайт надсилає після результату. Тригер за текстом кнопки або класами стилів зламається після наступної зміни дизайну. | Сайт надсилав сигнал про успішну оплату, але жоден тег його не відстежував. |
| Правила в GA4 | Перевірте в розділі «Адміністратор → Відображення даних → Події» правила створення та зміни подій. Вони створюють події, яких немає ні в GTM, ні в коді. | Одна подія надходила з правила GA4. Чотири інші правила за рік не створили жодної події. |
| Охоплення селектора | Перевірте селектор на робочій сторінці в кожному блоці, якому він може відповідати. | В одному розділі 10% показів промокарток надходили зі стрічки новин. |
| Параметри | Зареєструйте кожен параметр, який використовуєте у звітах, і перевірте частку порожніх значень. | Сума оплати була порожньою в кожній події. П’ять параметрів не відображалися у звітах. |
| Пов’язані конверсії | Перш ніж змінювати ключову подію, знайдіть, куди її імпортують. Додайте нову подію поруч зі старою й перемкніть після порівняння. | Ресурс пов’язаний із трьома обліковими записами Google Реклами. |
| Другий підрахунок | Перевірте запит або панель, із якими порівнюєте дані, перш ніж їм довіряти. | Внутрішня панель показувала близько двох третин реєстрацій компаній. |
Про автора
Макс Кірієнко
Десять років займаюся SEO та маркетингом. Складаю план росту, а потім будую інструменти й команди, які виконують його щодня.
Читати далі