Аналітика та трекінг

GA4 для сайту у 2026: базове налаштування + 10 типових помилок (і як їх уникнути)

by
GA4 для сайту у 2026: базове налаштування + 10 типових помилок (і як їх уникнути)

Оновлено: 2026. GA4 давно замінив Universal Analytics, але “просто поставити код” — вже не працює. Якщо GA4 налаштований криво, ви отримуєте гарні графіки, але погані рішення: не сходяться конверсії, дублюються події, падає якість атрибуції, а реклама оптимізується “в нікуди”. Нижче — практичний гайд для SMB: базова установка + перевірка даних + 10 найчастіших помилок і як їх швидко виправити.

Зміст

Навіщо GA4 у 2026 і що вважати “нормально налаштованим”

GA4 — це подієва аналітика: усе будується навколо подій (events) та параметрів. Для малого/середнього бізнесу “нормально налаштований GA4” — це не сотні кастомних івентів. Це коли ви стабільно відповідаєте на 5 питань:

  • Звідки прийшли люди (канали/кампанії) і що спрацювало?
  • Які сторінки/товари/послуги реально наближають до заявки/покупки?
  • Скільки якісних лідів/замовлень і з яких джерел?
  • Чи збігаються цифри між сайтом, CRM і рекламними кабінетами (хоча б по тренду)?
  • Чи можна довіряти конверсіям для оптимізації реклами?

Базова мета: мати одну зрозумілу структуру подій, коректні UTM, працюючі конверсії, мінімум дублювань і можливість швидко дебажити (DebugView / Realtime / звіти по подіях).

Перед стартом: що підготувати за 15 хвилин

Щоб не “налаштовувати наосліп”, підготуйте короткий список. Це зекономить години на переробках.

  • Доступи: Google Analytics, Google Tag Manager (якщо використовуєте), Google Ads, Search Console.
  • Список конверсій: 1–3 основні (заявка/дзвінок/покупка) + 2–4 мікроконверсії (клік на месенджер, перегляд контакту, початок оформлення).
  • Структура URL і UTM: домовтеся, як команда маркує кампанії (utm_source/utm_medium/utm_campaign/utm_content/utm_term).
  • Технічне: чи є SPA/React-сайт, мультидомени, піддомени, редиректи, платіжні сторінки, iframe, сторонні віджети.
  • Політики: чи потрібна згода на cookies (Consent Mode v2 / банер), чи є вимоги GDPR/локальних законів.

Порада: запишіть “ідеальний шлях” користувача від першого входу до заявки. Саме його ви будете перевіряти у DebugView.

Базове налаштування GA4: покроково

Крок 1. Створіть property GA4 і Data Stream

У GA4 створіть новий ресурс (property) або перевірте, що працює існуючий. Далі — Data Stream (Web): вкажіть домен сайту та назву потоку. Саме тут ви отримаєте Measurement ID (вигляду G-XXXX).

Перевірте в налаштуваннях потоку:

  • Enhanced Measurement увімкнений (але не “довіряйте на слово” — далі перевіримо, що воно не ламає події).
  • Чи не збираєте випадково зайві домени/піддомени (особливо на staging/dev).

Крок 2. Впровадження: Google tag або GTM

Є два нормальні варіанти:

  • Google tag (gtag.js) — простіше для базового старту, менше шансів “накосячити” з тригерами.
  • Google Tag Manager — краще, якщо потрібні кастомні події, ecommerce, умовні тригери, мультидомени, інтеграції з іншими тегами.

Критично: має бути один встановлений GA4-тег на продакшн-домені. Подвійна установка (і gtag, і GTM, або два GA4 конфіги) — найшвидший шлях до дублювань.

Крок 3. Перевірка збору даних у Realtime та DebugView

Після установки відкрийте сайт у новій вкладці та перевірте:

  • Realtime: чи з’являється активний користувач.
  • DebugView: якщо ви в режимі дебагу (через GTM Preview / GA Debugger / debug параметр), чи бачите події по кроках.

Якщо Realtime порожній — спочатку перевіряйте впровадження (чи є тег на сторінці), правильність Measurement ID і чи не блокує щось скрипти (CSP, adblock, банер згоди).

Крок 4. Відсікаємо внутрішній трафік (без “видалення даних”)

У 2026 типова помилка — “фільтрувати все підряд” і потім не розуміти, чому даних мало. Робимо акуратно:

  • Додайте правило Internal traffic за IP офісу/команди (де це стабільно).
  • Увімкніть фільтр у режимі Testing, подивіться 2–7 днів, переконайтесь, що не відрізали клієнтів.
  • Лише потім переводьте у Active.

Якщо у вас динамічні IP або команда працює з мобільного інтернету — краще використати підхід з параметром/кукою для internal через GTM, щоб відсікати себе більш надійно.

Крок 5. Крос-домен і реферальний “смітник”

Якщо у вас оплата/бронювання/кабінет на іншому домені або піддомені, налаштуйте cross-domain, інакше GA4 буде “різати” сесію, приписувати конверсії рефералам (платіжним системам) і псувати атрибуцію.

Паралельно налаштуйте список Unwanted referrals (небажані реферали): це домени оплат, віджетів, сервісів, які не повинні ставати джерелом конверсій.

Події та конверсії: мінімальний набір для SMB

Почніть з простого. Ваша мета — не “засипати” GA4 івентами, а зробити так, щоб кожна подія мала сенс і була стабільною.

  • generate_lead — успішна відправка форми (після реального success, не по кліку кнопки).
  • contact — відкриття контактів або клік “показати телефон” (якщо є логіка).
  • click з параметрами — кліки на месенджери/телефон/email (щоб бачити, що реально натискають).
  • view_item — перегляд картки товару/послуги (якщо каталог).
  • begin_checkout, add_to_cart, purchase — якщо e-commerce (краще через повний ecommerce, але базово можна стартувати навіть з purchase).

Важливо: події мають спрацьовувати один раз на одну дію. Якщо форма відправилась один раз, а generate_lead прилетів 3 рази — реклама і звіти будуть брехати.

Як правильно зробити конверсії

У GA4 будь-яку подію можна позначити як конверсію. Але логіка має бути такою:

  • Конверсія — це “цінна завершена дія” (лідогенерація/покупка/бронювання), а не просто перегляд сторінки.
  • Конверсія має бути прив’язана до факту успіху (thank-you сторінка, серверна відповідь 200 OK, показ повідомлення “успішно”).
  • Заздалегідь визначте, чи це один раз на сесію/користувача, чи може повторюватися (наприклад, purchase може бути багато разів).

Для SMB часто достатньо 1–3 ключових конверсій: generate_lead / purchase / booking_complete. Решту подій залиште як аналітичні (без позначки conversion), щоб не “забруднювати” оптимізацію в Ads.

Трафік і UTM: щоб джерела не “з’їжджали”

У 2026 найчастіша причина хаосу в джерелах — неправильні UTM і неконтрольовані редиректи. Базові правила:

  • utm_source — платформа/джерело (google, facebook, tiktok, newsletter).
  • utm_medium — тип трафіку (cpc, paid_social, email, referral).
  • utm_campaign — назва кампанії (spring_sale_2026, brand_search, retargeting).
  • utm_content — креатив/варіант (video_1, banner_blue, headline_a).
  • utm_term — ключове слово (актуально для пошуку або коли ви свідомо це заповнюєте).

Домовтесь про єдиний формат: нижній регістр, без пробілів, слова через підкреслення. І не змішуйте “cpc”, “ppc”, “paid”, “CPC” — це створює різні канали.

Окрема рекомендація для SMB: зробіть короткий внутрішній “словник” допустимих utm_source/utm_medium і використовуйте його в команді та підрядниках. Це зменшить хаос у звітах у рази.

Інтеграції (Google Ads, Search Console) і що перевірити

Інтеграції не потрібні “для галочки”. Вони потрібні, щоб конверсії доходили в рекламу, а SEO-запити було видно в одному місці.

  • Зв’яжіть GA4 з Ads на рівні адміністратора.
  • Увімкніть імпорт конверсій (обережно: імпортуйте тільки те, що дійсно є “цінним”).
  • Перевірте, чи немає дублювання конверсій (наприклад, одночасно GA4-конверсія і окрема конверсія з Google Ads тегу на ту саму дію).

Зв’язка з GSC дає органічні запити/посадкові прямо в GA4-звітах. Це корисно власникам і маркетологам: швидко бачите, які сторінки з SEO приводять трафік і чи є взаємодія.

У 2026 тема згоди на cookies (Consent Mode v2) — практична, а не юридична “галочка”. Якщо згода налаштована неправильно, ви можете бачити різкі провали в сесіях/конверсіях або “дірки” по рекламних кампаніях. Мінімальна рекомендація: переконайтеся, що банер згоди не блокує GA4 повністю, а працює за логікою згоди (коли потрібно).

Таблиця-чеклист: швидка перевірка правильності

Що перевіряємоОзнака “ОК”Як швидко перевірити
Один GA4-тег на сайтіНема дублювань page_view / session_startDebugView + перегляд джерела сторінки / GTM контейнер
Події не дублюютьсяgenerate_lead спрацьовує 1 раз на успішну відправкуDebugView під час тестової заявки
Конверсії прив’язані до факту успіхуКонверсія не спрацьовує “по кліку”Перевірка тригера (success message / thank-you)
UTM стандартизованіОдин формат source/medium, без хаосу регістрівReports → Acquisition → Traffic acquisition
Крос-домен налаштованийСесія не “рветься”, реферали оплат не забирають конверсіїПорівняйте шлях користувача до/після оплати
Внутрішній трафік відсічений акуратноКоманда не “накручує” метрики, але клієнти не відрізаніФільтр Internal traffic у режимі Testing → Active

10 типових помилок GA4 та як їх уникнути

1) Подвійна установка GA4 (два теги або gtag + GTM)

Симптом: завищені перегляди, дивні стрибки активних користувачів, дубльовані події. Рішення: залиште один шлях впровадження. Якщо працюєте через GTM — приберіть дублюючий gtag (або навпаки).

2) Конверсія “лід” спрацьовує по кліку кнопки

Симптом: конверсій більше, ніж реальних заявок у CRM. Рішення: тригер має спрацьовувати після success-стану (thank-you URL, показ “успішно”, подія з бекенду).

3) Платіжні системи та сервіси “крадуть” атрибуцію (реферали)

Симптом: джерело конверсій — liqpay/wayforpay/stripe/paypal/інші домени. Рішення: cross-domain + unwanted referrals, щоб сесія не перезапускалась на сторонньому домені.

4) UTM хаос: різні medium/source для одного каналу

Симптом: “Paid Social” розпадається на 10 варіантів, важко порівнювати кампанії. Рішення: словник UTM і дисципліна: один формат, нижній регістр, без самодіяльності.

5) Події є, але без параметрів (нічого не зрозуміло)

Симптом: є “click”, але незрозуміло, куди клікали. Рішення: додавайте параметри: link_url, link_text, button_name, form_id, item_id — мінімальний набір, який робить подію придатною для аналізу.

6) Enhanced Measurement створює зайві події або конфлікти

Симптом: дублюються scroll/outbound clicks, важко відрізнити кастомні події від авто. Рішення: або вимикайте конкретні авто-події, або називайте кастомні івенти так, щоб не перетинатися з автоматичними.

7) SPA сайт: “не змінюються сторінки” або page_view не коректний

Симптом: користувач ходить по сайту, а GA4 бачить одну сторінку. Рішення: налаштувати відстеження змін історії (history change) і відправку page_view на віртуальні перегляди.

8) Відсікли фільтрами “півсайту”

Симптом: різко мало трафіку, а бізнес відчуває, що лідів більше. Рішення: фільтри спочатку у Testing, контрольні порівняння з серверною статистикою/CRM, і лише потім Active.

9) Дублювання конверсій між GA4 та Google Ads

Симптом: Ads показує більше конверсій, ніж реальність, або “стрибає” CPA. Рішення: оберіть один основний механізм обліку для оптимізації (часто GA4 або Ads tag), і приберіть дубль.

10) Немає регулярного тесту після змін на сайті

Симптом: “вчора працювало” — після редизайну/нової форми конверсії пропали. Рішення: простий регламент: після релізів тестуємо ключові сценарії у DebugView, а раз на тиждень дивимось аномалії у звітах.

Діагностика: де дивитися, якщо дані “дивні”

Коли цифри не сходяться, не починайте з “GA4 поганий”. Почніть з діагностики по рівнях:

  • Рівень 1 (тут і зараз): Realtime — чи взагалі прилітають події.
  • Рівень 2 (детально): DebugView — чи правильні назви подій, чи не дублюються, які параметри передаються.
  • Рівень 3 (звітність): Reports → Engagement → Events / Conversions — чи конверсії враховуються як треба.
  • Рівень 4 (атрибуція): Acquisition — чи коректні source/medium, чи немає реферального сміття.

Практичний підхід: берете 3–5 тестових сценаріїв (вхід з UTM, перегляд ключової сторінки, клік на контакт, відправка форми) і проходите їх як користувач. Якщо в DebugView все логічно — 80% проблем уже вирішено.

FAQ

Чи достатньо Enhanced Measurement, щоб “все працювало”?

Ні. Enhanced Measurement — це базові авто-події (скрол, вихідні кліки тощо). Для бізнесу ключове — коректні конверсії (лід/покупка) та події з параметрами, які відображають ваш шлях клієнта.

Що важливіше: GA4 чи Google Ads конверсії?

Важливіше — щоб не було дублю і щоб конверсія відображала реальну цінну дію. Для оптимізації реклами часто обирають один основний тип конверсії й роблять його “еталонним”.

Чому конверсій у GA4 більше, ніж у CRM?

Найчастіші причини: конверсія спрацьовує по кліку, подія дублюється (дві установки тега або два тригери), частина заявок не доходить у CRM через технічні помилки, або користувач відправляє форму кілька разів.

Як зрозуміти, що крос-домен налаштований неправильно?

Якщо після переходу на оплату/кабінет сесія “обривається”, а джерелом конверсії стає домен платіжної системи — це майже завжди проблема крос-домену або unwanted referrals.

Що мінімально налаштувати, якщо часу дуже мало?

Один GA4-тег, перевірка Realtime/DebugView, generate_lead по факту успіху, 1–2 конверсії, базова UTM-стандартизація, плюс список небажаних рефералів (якщо є оплати/віджети).

Tracking