Більшість проєктів, які до нас приходять, уже мають розмітку GA4, але дані в звітах не збігаються з реальністю. Конверсії подвоюються, мікроконверсії не відстежуються, а атрибуція розмазує бюджет. Причина — неправильне проєктування подій і відсутність кастомних параметрів. Ми налаштували аналітику для 40+ проєктів за 10+ років роботи і знаємо, як уникнути цих помилок. Після впровадження правильно спроєктованих подій точність даних досягає 95%, а вартість ліда знижується на 20% за рахунок коректної атрибуції.
Як GA4 відрізняється від Universal Analytics і чому це важливо?
У UA метою було відвідування сторінки або досягнення певної умови. GA4 вважає конверсіями події. Кожна подія може бути позначена як конверсійна, і вона одразу бере участь в атрибуції. Але є нюанс: GA4 рахує кілька конверсій одного типу в сесії. Якщо потрібно враховувати лише першу реєстрацію, це вимагатиме додаткового параметра або фільтрації.
| Характеристика |
Universal Analytics |
Google Analytics 4 |
| Сутність конверсії |
Ціль (goal) |
Подія (event) |
| Повторні конверсії |
За замовчуванням 1 на сесію |
Декілька за замовчуванням |
| Модель атрибуції |
Last Click |
Data-Driven або Last Click |
| Кастомні параметри |
Обмежено |
До 50 кастомних вимірювань |
Чому Data-Driven Attribution точніша за Last Click і коли її використовувати?
Модель атрибуції за замовчуванням у GA4 — Data-Driven (при 1000+ конверсій на місяць). Вона розподіляє цінність між дотиками, а не віддає все останньому кліку. Тести показують, що DDA підвищує точність атрибуції на 30% порівняно з Last Click. Якщо даних менше, GA4 автоматично перемикається на Last Click. Ми рекомендуємо переходити на DDA при достатньому обсязі — це дає більш реалістичну картину.
Як правильно спроєктувати конверсії?
Ми починаємо з аудиту воронки: визначаємо, які дії користувача дійсно значущі — надсилання форми, клік на номер телефону, оформлення замовлення. Потім для кожної дії створюємо окрему подію з унікальною назвою. Наприклад, generate_lead для ліда, purchase для покупки. У назвах використовуємо snake_case без пробілів. Типова помилка — змішування кількох дій в одній події, що призводить до задвоєння та розмивання атрибуції.
Базова розмітка конверсійних подій
Конверсії надсилаються через gtag.js або GTM. Приклад — надсилання форми:
gtag('event', 'generate_lead', {
event_category: 'lead',
event_label: 'contact_form',
value: 1,
currency: 'UAH',
form_name: 'main_contact',
page_section: 'footer',
});
Покупка:
gtag('event', 'purchase', {
transaction_id: 'ORDER-789',
value: 14500,
currency: 'UAH',
items: [{ item_id: 'SKU-001', name: 'Pro Plan', price: 14500, quantity: 1 }],
});
Важливо передавати цінність у параметрі value та валюту.
Кастомні конверсії через GTM і Data Layer
Якщо сайт використовує GTM, налаштування спрощується. Створюємо тригер, наприклад, на надсилання форми або перехід на сторінку спасибі. Потім тег із типом «Google Analytics: GA4 Event». Перевіряємо через Preview і DebugView. Так можна розмітити будь-яку конверсію за кілька хвилин. Для передачі динамічних даних (ID користувача, сума замовлення) використовуємо dataLayer. Обов'язково очищаємо ecommerce: null перед наступною подією, щоб не перетиналися дані.
window.dataLayer.push({
event: 'purchase',
ecommerce: {
transaction_id: orderId,
value: totalAmount,
currency: 'UAH',
items: cartItems,
},
user_id: currentUser?.id,
});
window.dataLayer.push({ ecommerce: null });
| Параметр |
GTM |
gtag.js |
| Час налаштування однієї події |
10–15 хв |
15–30 хв |
| Потрібне виправлення коду |
Ні (якщо dataLayer) |
Так |
| Гнучкість |
Висока (тригери, змінні) |
Середня |
Налаштування в інтерфейсі GA4 та атрибуція
Події, які почали надходити, потрібно позначити як конверсії: Admin → Events → Mark as conversion. Параметри подій реєструємо в Custom Definitions. Ліміт — 50 кастомних вимірювань на ресурс. Для атрибуції GA4 за замовчуванням використовує Data-Driven Attribution (якщо даних достатньо). Модель можна змінити в Attribution Settings. Для імпорту в Google Ads зв'язуємо акаунти та вибираємо потрібні конверсії. Після цього конверсії доступні для стратегій «Цільова ціна за конверсію». Зверніть увагу: при зміні моделі атрибуції дані за минулі періоди перераховуються автоматично — це може викликати тимчасові розбіжності.
Налагодження та перевірка
Використовуйте DebugView у GA4 для реального часу. У консолі браузера перевірте dataLayer і gtag. Розширення Tag Assistant допомагає бачити всі hits.
Докладніше про Tag Assistant
Tag Assistant — це розширення Chrome від Google, яке показує всі спрацьовуючі теги (GA4, GTM, Google Ads) на сторінці. Воно підсвічує помилки, наприклад дублювання тегів або відсутність потрібних параметрів. Рекомендуємо при кожній зміні в GTM прогоняти через нього перевірку.
Що входить у нашу роботу
- Аудит поточної розмітки GA4 та виявлення помилок
- Проєктування подій під бізнес-воронку
- Налаштування GTM або gtag.js для надсилання конверсій
- Реєстрація кастомних параметрів і вимірювань
- Налаштування атрибуції та імпорт у Google Ads
- Передача токенів (client_id, session_id) у CRM при необхідності
- Навчання команди замовника роботі зі звітами
- Документація по всіх налаштованих подіях
Ми гарантуємо точність даних: після здачі ви отримаєте звіти, в яких цифри збігаються з реальними діями користувачів. Замовте аудит поточної розмітки — оцінимо та запропонуємо план доопрацювань. Отримайте консультацію з налаштування конверсій.
Терміни
Розмітка 3–5 ключових конверсій у коді + GTM-теги — 1 день. Налаштування кастомних параметрів і Data Layer — 4–6 годин. Налаштування атрибуції та зв'язка з Google Ads — 2–3 години.
Як налаштувати веб-аналітику: GA4, GTM, Яндекс.Метрика та Amplitude
Ми часто бачимо: конверсія 1.2 %, трафік зростає, а конверсія стоїть. Маркетолог дивиться в Google Analytics і каже: «користувачі йдуть з кроку 2 оформлення замовлення». Розробник відкриває той самий крок — помилок немає, в Sentry тиша. Значить, справа не в JS-базі, а в UX або в кривих даних, які показує аналітика. Аналітика ламається непомітно: подія перестала трекатися після редеплою — ніхто не помітив; GTM-тег стріляє двічі — дані задвоїлися; фільтр GA4 виключає бота, який насправді — реальний трафік з корпоративного проксі. Замовте аудит поточних тегів — ми знайдемо причину за тиждень. Ми маємо понад 5 років досвіду в налаштуванні веб-аналітики для 100+ проєктів — гарантуємо прозорість та достовірність даних.
Після правильного налаштування економія рекламного бюджету може досягати значної суми щомісяця — це реальний кейс інтернет-магазину з 50 000 сесій на день, де дедуплікація purchase повернула 20 % невірно приписаних конверсій.
Чому події GA4 дублюються і як це виправити?
Universal Analytics закрито, його місце зайняла подієва модель GA4. У ній немає фіксованих хітів сторінок і транзакцій — лише події з параметрами. Це гнучкіше, але вимагає правильного дизайну подій.
Автоматичні події GA4 збирає сам: page_view, scroll, click, session_start. Рекомендовані події потрібно реалізувати самостійно: purchase, add_to_cart, begin_checkout, view_item. Google очікує конкретну схему параметрів — якщо передати product_id замість item_id, дані потрапляють в GA4, але не в стандартні звіти e-commerce. Кастомні події для специфіки проєкту: filter_applied, video_progress, form_step_completed. Кастомні параметри необхідно зареєструвати в GA4 Admin → Custom definitions, інакше вони не будуть доступні у звітах.
Часта помилка — подія purchase з дублями. Причина: тег спрацьовує на сторінці /thank-you, користувач оновлює сторінку — другий purchase іде в GA4. Рішення: на бекенді генеруємо унікальний transaction_id і передаємо в подію. GA4 de-duplicates по ньому — перевіряйте через DebugView. Правильна атрибуція економить до 20 % рекламного бюджету, який раніше йшов на невірно приписані конверсії.
Як налаштувати data layer, щоб не втратити дані?
GTM — інструмент для керування тегами без деплою коду. Але «без коду» не означає «без архітектури». Data Layer — основа всього. Передаємо дані з застосунку в GTM через dataLayer.push(). Структура: event + контекстні дані. Для e-commerce: перед відкриттям сторінки продукту — push з даними товару. GTM-тег читає з dataLayer, не з DOM.
window.dataLayer = window.dataLayer || [];
dataLayer.push({
event: 'view_item',
ecommerce: {
items: [{
item_id: 'SKU-12345',
item_name: 'Назва товару',
price: null,
currency: null
}]
}
});
Погана практика: GTM-тег парсить DOM — шукає ціну в span.price, назву в h1. Це ламається при будь-якій зміні верстки. Хороша практика: завжди dataLayer. Використовуємо Preview Mode для налагодження та GTM Server-Side для чутливих даних — відправка з сервера, не з браузера, обходить блокувальники реклами, не втрачає дані. Server-side підхід у 2-3 рази надійніший за client-side за показником втрати подій через розширення браузера.
Як Яндекс.Метрика доповнює веб-аналітику?
Для російської аудиторії Метрика обов'язкова — особливо Вебвізор. Запис сесії користувача, який кинув кошик, часто дає відповідь швидше, ніж тиждень аналізу воронки. Цілі в Метриці: подієві (через ym(COUNTER_ID, 'reachGoal', 'GOAL_NAME')) або автоматичні (клік по кнопці, відвідування сторінки). Зв'язка з CRM через Метрика Плюс — передача офлайн-конверсій. Наш досвід: у 8 з 10 проєктів після налаштування Метрики знаходили приховані баги в UX, які не показували інші системи.
Що дає product analytics в Amplitude?
Amplitude — продуктовий інструмент, на відміну від маркетингових GA4 та Метрики. Він заточений під аналіз поведінки користувачів всередині продукту: воронки, ретеншн, user paths. Amplitude підходить для SaaS-продуктів, мобільних застосунків та будь-яких сервісів із зареєстрованими користувачами, де важливо зрозуміти, як проходять онбординг, на якому кроці йдуть, які фічі використовують частіше. Ключові концепції: identify (пов'язати анонімного користувача з userId після авторизації), group (акаунт у B2B SaaS), когорти для утримання. Amplitude Chart — воронка кроків за останні 30 днів з розбивкою за джерелом.
Моніторинг якості даних
Аналітика без моніторингу — чорна скринька. Налаштовуємо:
- GA4 Realtime — перевіряємо після кожного деплою, що ключові події приходять
- Alerting в GA4 — аномалія в кількості подій
purchase (різке падіння = щось зламалося)
- GTM Preview в staging-оточенні перед продакшеном
- Ручні тести воронок раз на тиждень — просто пройти шлях покупця і перевірити, що все трекається
Якщо ви помітили розбіжності в даних — зв'яжіться, проведемо безкоштовний аудит коректності тегів.
Що перевіряємо після кожного деплою
- Чи всі рекомендовані події присутні в DebugView
- Чи немає задвоєнь (рахуємо кількість
purchase на 100 сесій)
- Чи не змінилася структура dataLayer після оновлення фронтенду
Що входить в роботу
| Компонент |
Опис |
| Аудит поточних тегів |
Перевірка існуючих GTM-тегів, dataLayer, дублів та помилок |
| Дизайн подієвої схеми |
Документація: список подій, параметри, тригери |
| Налаштування GA4 + GTM |
Створення конфігурації, тегів, Custom definitions |
| Яндекс.Метрика |
Встановлення лічильника, створення цілей, налаштування Вебвізора |
| Amplitude (опціонально) |
Налаштування клієнтського та серверного SDK, когорти |
| QA та моніторинг |
Тестування в Preview Mode, Alerting |
| Навчання та передача |
Доступи, інструкція з додавання нових подій, консоль |
Процес та терміни
- Аудит поточних тегів та даних (2 дні)
- Дизайн подієвої схеми (2 дні)
- Розробка Data Layer та налаштування тегів (3–5 днів)
- QA в Preview Mode та на staging (2 дні)
- Деплой та налаштування дашбордів (1 день)
| Сценарій |
Термін |
| Базове налаштування GA4 + GTM |
1 тиждень |
| Повний e-commerce tracking + Метрика |
2–3 тижні |
| Server-side GTM + Amplitude |
3–5 тижнів |
Вартість розраховується індивідуально. Отримайте консультацію з налаштування веб-аналітики для вашого проєкту — ми оцінимо обсяг робіт за один день. Зв'яжіться з нами, щоб почати. Для точного розрахунку вартості залиште заявку — ми проаналізуємо ваш стек за 1 день.