Universal Analytics більше не існує: збір даних зупинили 1 липня 2023 року, версію 360 — роком пізніше, а самі дані з серверів Google видалили влітку 2024-го. Тому питання «переходити чи ні» знято — Google Analytics 4 сьогодні єдиний варіант.
Проблема в іншому. Поставити тег на сайт — це п’ять хвилин, і після цього GA4 справді почне щось збирати. Але «щось» — це перегляди сторінок і автоматичні події, з яких неможливо зрозуміти, скільки заявок принесла реклама й окупається вона взагалі. Ресурс, налаштований наполовину, гірший за відсутність аналітики: він створює відчуття, що дані є, і на них ухвалюють рішення.
Нижче — чек-лист налаштування GA4 з нуля: від створення ресурсу до інтеграцій і того, що перевірити перед тим, як довіряти цифрам. Окремо розберемо три речі, які змінилися вже після появи GA4 і про які старі інструкції не знають: ключові події замість конверсій, режим згоди для трафіку з ЄЕЗ і те, що сталося з Google Signals у лютому 2024 року.
Головна зміна порівняно з Universal Analytics — модель даних. UA будувалася навколо сеансів: усі взаємодії групувалися в межах візиту, а типи звернень були різні (перегляд сторінки, подія, транзакція).
GA4 будується навколо подій. Будь-яка взаємодія — перегляд сторінки, клік, прокручування, покупка — це подія з набором параметрів. Сеанс лишився, але як похідна величина, а не основа моделі.
Що з цього випливає практично:
Ще одне, про що варто знати заздалегідь: інтерфейс розділу «Адміністратор» у 2024 році повністю перебудували. Налаштування згруповані інакше, ніж у більшості інструкцій. Тому нижче я називаю налаштування за назвою, а не за старим шляхом кліків — так ви знайдете потрібне через пошук в адмінці, навіть якщо Google знову щось пересуне.
Робота починається з облікового запису Google. Один акаунт може містити кілька ресурсів (properties), а кожен ресурс — кілька потоків даних (веб-сайт, застосунок Android, застосунок iOS).
Порядок дій:
Одразу дві поради, які потім складно виправити.
Часовий пояс і валюту виставляйте правильно з першого дня. Зміна часового поясу не переписує історичні дані: на графіку з’явиться розрив або сплеск у момент переходу. І якщо в GA4 та Google Ads пояси різні, добові цифри не зійдуться ніколи.
Не плодіть ресурси. Поширена помилка — створити другий ресурс «для тесту» й забути, який із них основний. Через рік ви отримаєте два набори неповних даних замість одного повного.
Є два способи поставити GA4 на сайт.
Напряму в код. Тег Google вставляється в секцію <head> усіх сторінок, які треба відстежувати. Найпростіший шлях, якщо доступ до шаблону є, а планів на складне відстеження немає.
Через Google Tag Manager. Правильний варіант для будь-якого проєкту, де знадобиться більше за базові дані. GTM дозволяє налаштовувати події без правок коду сайту, зберігає історію змін і дає режим попереднього перегляду. У нас є окремі матеріали про те, як встановити GA4 через GTM і як загалом працювати з Tag Manager.
Для сайтів на популярних CMS і конструкторах зазвичай є вбудоване поле для ідентифікатора або офіційний плагін — це те саме встановлення напряму, просто через інтерфейс.
Не пропускайте цей крок: половина проблем з аналітикою — це не «неправильні цифри», а тег, який стоїть не на всіх сторінках.
Перевіряти треба не головну, а всі типи сторінок: картку товару, кошик, сторінку подяки після заявки. Саме на останній тег відсутній найчастіше — і саме там він потрібен найбільше.
Чотири параметри, які виставляються один раз і потім впливають на всі дані.
GA4 дозволяє обрати, скільки зберігати дані на рівні користувачів і подій: 2 або 14 місяців. За замовчуванням стоїть 2.
Змініть на 14 одразу. Це найчастіша й найдорожча помилка новачків: за замовчуванням через два місяці ви втрачаєте можливість подивитися деталізовані дані в «Дослідженнях», а порівняти рік до року не зможете взагалі. Обмеження стосується детальних даних — стандартні звіти зі зведеними показниками зберігаються довше.
Опція «скидати дані користувача при новій дії» продовжує строк для тих, хто повертається: якщо людина заходить щомісяця, її дані не видаляються.
За замовчуванням сеанс завершується після 30 хвилин неактивності — саме неактивності, а не активності. Значення можна змінити в налаштуваннях потоку даних, у додаткових параметрах тегу.
Міняти є сенс рідко. Типовий випадок — сервіси, де людина довго читає одну сторінку без кліків: там короткий тайм-аут штучно роздуває кількість сеансів.
Сеанс вважається залученим, якщо виконано хоча б одну умову: користувач пробув на сайті понад 10 секунд (значення за замовчуванням), переглянув дві або більше сторінки, або здійснив ключову подію. Усе інше — відмова.
Поріг налаштовується там само, де тайм-аут сеансу. Для контентних проєктів його часто піднімають, щоб не зараховувати випадкові заходи.
Ваші власні візити, візити менеджерів і тестування програмістом потрапляють у статистику й псують її — особливо на малих обсягах, де десяток внутрішніх сеансів помітно зсуває конверсію.
GA4 дає два фільтри: внутрішній трафік (за IP-адресами, які ви задаєте правилом) і трафік розробки (події з пристрою в режимі налагодження).
Два важливих застереження. Фільтр діє тільки вперед — історичні дані він не змінює. І створений фільтр за замовчуванням має статус «тестування»: у цьому режимі він нічого не виключає, поки ви не активуєте його вручну. Про це забувають постійно.
Виключати дані варто обережно: те, що відфільтровано, зникає назавжди й у GA4 більше не з’явиться.
Розділ, якого немає в інструкціях старших за два роки, а він зараз найважливіший із юридичного боку.
З березня 2024 року для трафіку з Європейської економічної зони Google вимагає передавати сигнали згоди користувача. Без цього рекламні функції не працюють: аудиторії з GA4 не наповнюються, ремаркетинг і моделювання конверсій для європейського трафіку недоступні.
Механіка така: банер згоди на сайті повідомляє тегам, на що користувач погодився, через чотири параметри — два для аналітики й реклами й два додаткові для персоналізації та даних користувача. Якщо згоди немає, теги не пишуть файли cookie, але надсилають знеособлені сигнали, на основі яких Google моделює втрачені конверсії.
Що потрібно зробити на практиці: поставити банер згоди, який підтримує Consent Mode v2 (більшість сучасних рішень підтримують), і переконатися, що він працює до завантаження тегів, а не після. Перевіряється в режимі попереднього перегляду GTM — там видно статус згоди.
Якщо серед вашої аудиторії немає європейського трафіку, вимога формально вас не стосується. Але банер згоди все одно потрібен, якщо ви взагалі працюєте з персональними даними.
У налаштуваннях збору даних можна вимкнути персоналізацію реклами для окремих країн і регіонів. Якщо вона вимкнена, GA4 не читає й не пише рекламні cookie для цього регіону, а списки аудиторій не поповнюються новими користувачами звідти.
Окремий перемикач, яким ви підтверджуєте Google, що відвідувачі сайту поінформовані про збір даних. Без цієї згоди частина функцій недоступна.
І тверде технічне правило, яке порушують частіше, ніж здається: у GA4 не можна передавати персональні дані — email, телефон, ім’я, точну адресу. Ані в параметрах подій, ані в URL сторінок. Якщо на сторінці подяки в адресі лишається телефон із форми, він потрапляє в аналітику, і це порушення умов використання з ризиком видалення даних. Ці параметри треба вирізати на рівні GTM або налаштувань потоку.
Про те, як обмеження на cookie позначаються на рекламі, є окремий матеріал.
Тут майже всі наявні інструкції дають застарілу картину, тому розберемо окремо.
Раніше GA4 у звітах визначав користувача за трирівневою схемою: спершу User ID, потім Google Signals, потім ідентифікатор пристрою. 12 лютого 2024 року Google прибрав Google Signals із визначення особи у звітах.
Наслідок для практики хороший: майже зникло порогування даних. Раніше GA4 приховував рядки з малою кількістю користувачів, щоб не можна було ідентифікувати конкретну людину, і в звітах з’являлися «дірки» без пояснення. Тепер цього значно менше.
Актуальна картина:
Практичний висновок: вмикати Google Signals має сенс, якщо ви користуєтесь ремаркетингом і демографічними звітами. На точність базових звітів це більше не впливає.
У GA4 усе — події. Вони діляться на чотири типи.
Збираються одразу після встановлення тегу, налаштовувати нічого не треба: перший візит, початок сеансу, перегляд сторінки, залучення користувача.
Вмикається перемикачем у налаштуваннях потоку даних (за замовчуванням увімкнена). Додає події, які раніше доводилося налаштовувати руками:
Останній пункт варто перевірити окремо: автоматичне відстеження форм працює не на всіх реалізаціях. Якщо форма зроблена нестандартно або відправляється через скрипт, події не буде — і треба налаштовувати вручну через GTM.
Події з наперед визначеними Google назвами й параметрами, які ви налаштовуєте самі: реєстрація, вхід, додавання в обране, генерація ліда. Використовувати саме рекомендовані назви важливо — інакше GA4 не покаже їх у стандартних звітах.
Усе, чого немає в попередніх типах: клік по номеру телефону, відкриття месенджера, натискання конкретної кнопки, глибина перегляду каталогу.
Рис. 1 — Звіт про події в Google Analytics 4
Порада з практики: ведіть окрему таблицю з переліком усіх налаштованих подій, їхніх параметрів і того, що саме вони означають. Через рік ніхто не пам’ятає, чим form_submit_2 відрізняється від lead_form, а без цього звіт не читається.
Важлива термінологічна зміна: у 2024 році Google перейменував у GA4 конверсії на ключові події. Слово «конверсії» лишилося за Google Ads — тепер це різні сутності, і плутанина між ними породжує половину питань про розбіжність даних.
Механіка не змінилася: будь-яку подію можна позначити як ключову перемикачем у списку подій. Після цього вона потрапляє у відповідні звіти й може імпортуватися в Google Ads.
Що позначати ключовими — залежить від бізнесу:
Дві помилки, які трапляються постійно.
Позначити ключовою подією клік по кнопці, а не результат. Клік не означає, що форма відправилася — людина може не пройти валідацію. Ключовою має бути подія успішної відправки.
Позначити ключовими десять подій одразу. Тоді в звіті буде велика цифра «ключові події», яка ні про що не говорить, бо змішує заявки з прокручуванням. Тримайте ключовими тільки те, що є для бізнесу результатом.
Кілька подій позначені як ключові за замовчуванням і не потребують дій: purchase для сайту, а для застосунків — first_open, in_app_purchase і події підписок.
Потрібна інтернет-магазинам і будь-яким проєктам, де є кошик і оплата. Без неї GA4 не покаже ні дохід, ні товари, ні шлях до покупки.
Схема така: розробник формує на сайті рівень даних (dataLayer) із параметрами товарів і замовлення, а GTM передає ці дані в GA4 у вигляді стандартних подій — view_item, add_to_cart, begin_checkout, purchase та інших.
Рис. 2 — Звіт електронної торгівлі в Google Analytics 4
Це єдина частина налаштування, яку майже неможливо зробити без розробника. Для сайтів на поширених платформах електронної комерції існують готові модулі й плагіни, які закривають більшість роботи, але перевіряти передачу все одно доводиться вручну.
Що перевірити обов’язково: чи не задвоюється подія purchase при оновленні сторінки подяки, чи збігається сума транзакції з реальною, чи не приходять замовлення без ідентифікатора. Розбіжність між GA4 і бекендом у 5–10% — норма, у 30% — привід шукати помилку.
Крім фільтрів внутрішнього трафіку є ще одна річ, яку налаштовують рідко, а варто завжди.
Список небажаних переходів — це домени, переходи з яких GA4 не має вважати новим джерелом трафіку. Класична ситуація: людина прийшла з реклами, пішла на сторінку платіжної системи, повернулася назад — і GA4 записує джерело покупки як платіжний шлюз. Реклама лишається без конверсії, а в звіті з’являється дивний реферал.
Що додавати в список:
Налаштовується в додаткових параметрах тегу в потоці даних. Умови можна задавати простим збігом або регулярними виразами.
Без цього налаштування звіт по джерелах трафіку буде системно спотвореним, причому саме в найдорожчій частині — там, де відбуваються покупки.
Дозволяють бачити у звітах те, чого GA4 не збирає сам: тип клієнта, категорію послуги, спосіб оплати, статус замовлення з CRM.
Механіка двоступенева: спершу параметр передається разом із подією, потім реєструється в розділі спеціальних визначень — і тільки після цього з’являється у звітах. Дані до реєстрації не підтягуються заднім числом, тому реєструвати треба одразу.
Обмеження на один ресурс: до 50 спеціальних параметрів на рівні події, до 25 на рівні користувача й до 50 спеціальних показників. Виглядає багато, але на великих проєктах вичерпується, тому не заводьте параметри «про запас».
Об’єднують сторінки в логічні категорії — блог, каталог, картки товарів, послуги — і дозволяють порівнювати їх між собою, а не гортати список із тисяч URL.
Рис. 3 — Звіт за групами контенту
Група передається як параметр події при налаштуванні тегу. Це одне з найдешевших налаштувань за співвідношенням зусиль і користі: п’ять хвилин роботи дають можливість відповісти на питання «скільки заявок приносить блог проти каталогу», на яке інакше відповісти неможливо.
Сам собою GA4 показує лише те, що відбувається на сайті. Цінність з’являється, коли він зв’язаний із рештою систем.
Найважливіша інтеграція. Дає:
Одне застереження: імпортовані з GA4 конверсії й власні конверсії Google Ads рахуються по-різному, тому не вмикайте одну й ту саму дію двічі. Інакше алгоритм навчатиметься на подвоєних даних.
Додає у GA4 два звіти по органічному трафіку: за запитами й за цільовими сторінками, з кліками, показами, CTR і середньою позицією. Зручно, коли не хочеться перемикатися між сервісами, хоча повний набір даних усе одно лишається в самій Search Console.
Важливо: після зв’язування звіти треба ще опублікувати в бібліотеці, інакше вони не з’являться в меню. На цьому спотикаються майже всі.
Безкоштовний експорт сирих даних про події. Потрібен, коли ви впираєтесь в обмеження інтерфейсу: складна аналітика, зв’язка з CRM, зберігання без ліміту.
Головна причина підключити його навіть без нагальної потреби — термін зберігання. У GA4 деталізовані дані живуть максимум 14 місяців, у BigQuery — скільки завгодно. Експорт налаштовується за п’ять хвилин, дані пишуться щодня; безкоштовний ліміт — до мільйона подій на день. Якщо є хоч найменша ймовірність, що через два роки вам знадобиться порівняти періоди, вмикайте зараз: заднім числом дані не з’являться.
Для магазинів із товарними оголошеннями. Дозволяє бачити трафік і конверсії з безкоштовних товарних карток у пошуку.
Не інтеграція в адмінці, а конектор — але саме там більшість людей врешті дивиться дані GA4. Звіт збирається один раз і оновлюється сам, а клієнту не треба давати доступ до самої аналітики. У квітні 2026 року Google повернув продукту назву Data Studio, тому в різних джерелах він трапляється під обома іменами. Як це налаштувати, ми розібрали в посібнику з Data Studio; там же — розділ про те, чому цифри в звіті можуть не збігатися з тим, що показує GA4.
Про UTM-мітки для всього нерекламного трафіку — розсилок, соцмереж, месенджерів — у нас є окремий матеріал. Без них джерела зіллються в купу «direct», і жодна інтеграція цього не виправить.
Стандартні звіти GA4 дають загальну картину. Усе цікаве починається в розділі «Дослідження».
Рис. 4 — Приклад звіту в розділі «Дослідження»
Доступні методики:
Рис. 5 — Методики досліджень у Google Analytics 4
Сегменти — це групи користувачів, сеансів або подій за заданою умовою. Доступні всередині досліджень і дозволяють порівнювати, наприклад, поведінку тих, хто прийшов з реклами, і тих, хто прийшов з органіки.
Рис. 6 — Приклад сегмента
Аудиторії — те саме, але зі збереженням і можливістю передати в Google Ads для ремаркетингу. Ключова відмінність від сегментів: аудиторія починає наповнюватися з моменту створення й не працює заднім числом. Тому базові аудиторії — відвідувачі кошика без покупки, ті, хто був на сторінці послуги, — варто створити одразу після налаштування ресурсу, навіть якщо ремаркетинг ви поки не запускаєте.
Рис. 7 — Редактор аудиторій
Окремо варто знати про статистику й аномалії на головному екрані: GA4 сам знаходить незвичайні зміни в даних і повідомляє про них. Можна задати й власні умови сповіщень — наприклад, падіння ключових подій більш ніж на 30% за тиждень.
Рис. 8 — Автоматична статистика на головному екрані
Доступ видається на рівні облікового запису (тоді людина бачить усі ресурси) або окремого ресурсу. Ролі: адміністратор, редактор, аналітик, читач і «немає доступу».
Рис. 9 — Ролі користувачів і їхні можливості
Додатково можна обмежити доступ до показників витрат і доходу — зручно, коли підрядник має бачити трафік, але не фінансові дані.
Правило безпеки: роль адміністратора на рівні облікового запису видавайте мінімальній кількості людей. Адміністратор може видалити ресурс разом з усіма даними, і відновити їх буде неможливо.
Потрібне, коли шлях користувача проходить через кілька доменів — наприклад, сайт і окрема система бронювання. Без налаштування перехід між доменами GA4 порахує як новий сеанс з новим джерелом.
Рис. 10 — Схема міждоменного відстеження
Дві умови обов’язкові: на всіх доменах має стояти один і той самий ідентифікатор потоку (G-XXXXXXXXXX), і домени треба перелічити в налаштуваннях доменів у потоці даних. Для піддоменів налаштовувати нічого не потрібно — вони працюють одразу.
Стислий список для самоперевірки. Якщо все відмічено — аналітиці можна вірити.
Налаштована аналітика — це не мета, а умова. Сенс з’являється тоді, коли з цифр видно, який канал приносить гроші й скільки коштує клієнт. Про те, які показники дивитися й як їх читати, ми написали окремо — у матеріалі про метрики SEO. А якщо потрібен зовнішній погляд на поточні налаштування, ми можемо перевірити ресурс і скласти перелік правок — у межах просування або окремою задачею; вартість напрямків є у прайсі.
Ні. Збір даних у безкоштовній версії зупинили 1 липня 2023 року, у версії 360 — 1 липня 2024-го, а історичні дані видалили з серверів Google. Якщо ви не встигли їх вивантажити, відновити їх неможливо. GA4 — єдиний доступний варіант.
Це те саме, перейменоване у 2024 році. У GA4 тепер «ключові події», а слово «конверсії» лишилося за Google Ads. Різниця важлива при звірці: конверсії в Ads і ключові події в GA4 рахуються за різними правилами атрибуції й майже ніколи не збігаються точно.
Деталізовані дані про події й користувачів — 2 або 14 місяців, залежно від налаштування, за замовчуванням 2. Виставляйте 14 одразу. Для необмеженого зберігання потрібен експорт у BigQuery, який безкоштовний у межах мільйона подій на день.
12 лютого 2024 року Google прибрав Google Signals із визначення особи у звітах. Головний наслідок — майже зникло порогування, через яке GA4 раніше ховав рядки з малою кількістю користувачів. Сам Google Signals лишився й працює для рекламних функцій і аудиторій.
Для трафіку з Європейської економічної зони — так, з березня 2024 року. Без передачі сигналів згоди рекламні функції не працюють: аудиторії не наповнюються, ремаркетинг і моделювання конверсій недоступні. Якщо європейського трафіку немає, вимога формально не стосується вас, але банер згоди все одно потрібен при роботі з персональними даними.
Через GTM, якщо є хоч якісь плани на відстеження подій. Це дозволяє налаштовувати все без правок коду сайту, зберігає історію змін і дає режим налагодження. Напряму в код має сенс лише для простих сайтів без складного відстеження.
Найчастіші причини: різні часові пояси, різні моделі атрибуції, різні вікна врахування конверсії, а також те, що Ads рахує конверсію за датою кліка, а GA4 — за датою самої дії. Розбіжність у 10–20% нормальна. Якщо різниця кратна, перевірте, чи не задвоєні конверсії при імпорті.
Перші дані з’являються одразу, але для аналізу потрібен щонайменше повний тиждень — щоб побачити цикл робочих і вихідних днів. Для сезонних висновків і моделей — від кількох місяців.
Ні. Це різні моделі даних, автоматичного перенесення історії ніколи не існувало, а самі дані UA вже видалені. Максимум, що можна зробити, — тримати вивантажені раніше таблиці окремо, для ручного порівняння.
Тільки BigQuery. Експорт налаштовується за кілька хвилин, дані пишуться щодня й зберігаються без обмеження за строком. Заднім числом він не працює — тому вмикати варто одразу, навіть якщо потреби поки немає.
Звертайтесь!
