
Google Analytics 4 (GA4) — сервіс Google, який показує, що люди роблять на вашому сайті чи в застосунку: звідки приходять, які сторінки відкривають, чи залишають заявку, чи телефонують, чи купують. Бізнесу він потрібен, щоб бачити, які канали приводять клієнтів, на яких сторінках люди йдуть із сайту і чи окупається реклама.
У цьому посібнику пояснюємо, як влаштований GA4, як його встановити, що перевірити першого дня і чому цифри в GA4, CRM і Google Ads майже ніколи не збігаються. Інтерфейс GA4 регулярно змінюється, тому ми насамперед пояснюємо логіку налаштувань. Орієнтовні шляхи в меню зібрано в окремій таблиці нижче. Назви пунктів у вашому ресурсі можуть відрізнятися, тож звіряйте їх з офіційною довідкою Google.
Що таке Google Analytics 4 коротко
GA4 збирає дані у вигляді подій. Перегляд сторінки, клік, надсилання форми, покупка — кожна така дія записується як окрема подія. Подробиці (яка сторінка, яка сума, яка валюта, який товар) передаються в параметрах цієї події. Офіційний опис моделі даних є в довідці Google Analytics.
На практиці налаштування починається з простого запитання: «Які дії на сайті для нас важливі?». Відповідь на нього і є списком подій, які треба вимірювати.
Що з Universal Analytics
Universal Analytics — попередня версія Google Analytics. Для нового налаштування її вже не розглядають. Дати припинення обробки даних для стандартних ресурсів і для версії 360 Google публікує на окремій сторінці довідки.
Важливо розуміти, що GA4 — це окремий ресурс, а не оновлена версія старого. Дані в ньому з'являються з моменту, коли на сайті почав працювати тег GA4. Тому що раніше ви його встановите, то довшою буде історія для порівнянь.
Що змінилося в термінах
Дії, важливі для бізнесу (заявка, покупка, дзвінок), у GA4 позначають як ключові події. У старих інструкціях, а також у Google Ads ви побачите слово «конверсії». Не плутайте ці назви і звіряйте їх з тим, що бачите у своєму ресурсі.
Як влаштований GA4: обліковий запис, ресурс, потік даних
У GA4 три рівні:
- Обліковий запис — верхній рівень, зазвичай один на компанію.
- Ресурс — окремий сайт або продукт. Тут задаються часовий пояс, валюта, період зберігання даних, зв'язки з іншими сервісами Google і доступи.
- Потік даних — джерело, з якого надходять дані: вебсайт або мобільний застосунок. В одному ресурсі може бути кілька потоків.
Порада з практики: обліковий запис має належати компанії, тобто корпоративному Google-акаунту, а не особистій пошті підрядника чи колишнього співробітника. Агенціям і фрилансерам надавайте доступ з потрібною роллю, а не права власника.
Ідентифікатор вимірювання G-XXXXXXX
Кожен вебпотік має ідентифікатор вимірювання у форматі G-XXXXXXX. Знайти його можна в налаштуваннях вебпотоку даних. Саме цей ідентифікатор вказують у тезі Google на сайті або в Google Tag Manager, щоб дані потрапляли у ваш ресурс.
Якщо дані не з'являються, насамперед перевірте, чи на сайті стоїть правильний G-ідентифікатор. Буває, що після редизайну на сайті лишається тег іншого чи тестового ресурсу.
Які бувають події
- Базові події, які тег збирає сам. Для них нічого не треба налаштовувати, достатньо встановити тег.
- Події розширеного вимірювання. Це набір подій, які вмикаються і вимикаються перемикачами в налаштуваннях вебпотоку. Актуальний перелік є в довідці Google. Перевірте, чи кожен увімкнений пункт справді коректно працює на вашому сайті, особливо якщо форми чи пошук зроблені нестандартно.
- Події, налаштовані вручну. Заявки, кліки на телефон чи месенджер, оформлення замовлення, покупка — усе, що залежить від логіки вашого сайту. Щоб скласти такий список, випишіть усі способи, якими клієнт може з вами зв'язатися або купити, і для кожного визначте момент, коли дію можна вважати виконаною: наприклад, не клік на кнопку «Надіслати», а успішне надсилання форми.
Покрокове встановлення GA4 на сайт
Загальний порядок дій (обліковий запис → ресурс → потік → тег) Google описує в інструкції з налаштування. Нижче — що важливо врахувати на кожному кроці.
Крок 1. Обліковий запис і ресурс: часовий пояс і валюта
Під час створення ресурсу оберіть часовий пояс і валюту, у яких ви рахуєте гроші та звіряєте звіти з CRM чи бухгалтерією. Від часового поясу залежить, до якого дня потрапить замовлення, зроблене близько опівночі. Від валюти залежить, як GA4 показуватиме дохід. Якщо ці налаштування не збігатимуться з CRM, розбіжності з'являться ще до того, як ви почнете аналізувати дані.
Крок 2. Вебпотік даних
Створіть вебпотік: вкажіть адресу сайту та зрозумілу назву. На цьому ж кроці перегляньте налаштування розширеного вимірювання і скопіюйте ідентифікатор вимірювання G-XXXXXXX. Орієнтовний шлях в англомовному інтерфейсі: Admin → Data collection and modification → Data streams.
Крок 3. Оберіть спосіб встановлення: код сайту чи Google Tag Manager
Тег можна розмістити безпосередньо в коді сайту або через Google Tag Manager (GTM). Коротке порівняння:
| Тег Google у коді (gtag.js) | Google Tag Manager | |
|---|---|---|
| Хто вносить зміни | Розробник, через код сайту | Маркетолог або аналітик в інтерфейсі GTM |
| Скільки подій зручно вести | Небагато | Багато: форми, кліки, кроки оформлення |
| Інші рекламні теги | Кожен окремо в коді | В одному контейнері |
| Перевірка перед публікацією | Залежить від процесу розробки | Вбудований режим попереднього перегляду |
Що обрати. Якщо ви плануєте відстежувати більше ніж кілька базових подій або на сайті є інші рекламні теги, зазвичай зручніше GTM. Тег у коді має сенс для простого сайту, де зміни бувають рідко і є розробник, який їх вносить.
Варіант 1: тег Google (gtag.js) у коді сайту
GA4 показує код тегу Google, який треба розмістити на всіх сторінках сайту так, як вказано в інструкції в інтерфейсі.
Цей варіант підходить, якщо:
- сайт простий, а подій небагато;
- є розробник, який вноситиме зміни в код;
- ви не плануєте часто додавати нові теги.
Мінус у тому, що кожна нова подія чи зміна потребує правок у коді сайту.
Варіант 2: через Google Tag Manager
Google Tag Manager — це «контейнер» для тегів. Його код один раз встановлюють на сайт, а далі тег Google з вашим G-ідентифікатором, події та інші пікселі налаштовують уже в інтерфейсі GTM.
GTM зручніший, якщо:
- потрібно відстежувати багато подій (форми, кліки, кроки оформлення замовлення);
- на сайті є інші рекламні теги;
- маркетолог хоче змінювати налаштування без розробника;
- важливо тестувати зміни перед публікацією в режимі попереднього перегляду.
Головне правило: обирайте один спосіб встановлення. Якщо одночасно стоять тег у коді, тег через GTM і ще плагін CMS, події дублюються, а звіти стають непридатними для аналізу.
Примітки для поширених CMS
- WordPress. Тег можна додати через плагін, через налаштування теми або встановити контейнер GTM. Оберіть щось одне. Після оновлення чи зміни теми перевірте, чи тег не зник і не задублювався.
- OpenCart. Тег зазвичай додають через модуль або в шаблон. Для подій електронної комерції результат залежить від модуля і версії оформлення замовлення, тому обов'язково зробіть тестову покупку і перевірте, які події та параметри передаються.
- Shopify. Перш ніж додавати код вручну, перевірте, чи сервіси Google вже не підключені через інтеграції платформи або встановлені застосунки. Інакше легко отримати дублі.
Крок 4. Перевірте, що дані надходять
- Звіт у реальному часі (Realtime). Відкрийте сайт, наприклад, з телефона через мобільний інтернет, а не через офісний Wi-Fi, і подивіться, чи з'явився візит. Так ваш візит не відсіє фільтр внутрішнього трафіку за IP-адресою офісу, якщо ви його вже налаштували.
- DebugView. Показує події з параметрами для пристроїв у режимі налагодження. Зручно вмикати через режим попереднього перегляду GTM або Tag Assistant.
- Tag Assistant. Показує, які теги спрацювали на сторінці і з яким ідентифікатором.
Якщо в Realtime візит є, а в DebugView немає потрібних подій, проблема зазвичай у налаштуванні конкретної події, а не в установці тегу загалом.

Чекліст першого дня: налаштування, які часто пропускають
Встановити тег — це половина роботи. Ось що варто перевірити одразу після встановлення:
- [ ] Період зберігання даних. Від нього залежить, за який період можна будувати дослідження (Explorations) на детальних даних. Перевірте поточне значення і виставте потрібне. Доступні варіанти описано в довідці Google. Зверніть увагу: дані, які вже видалено, це налаштування не поверне.
- [ ] Фільтр внутрішнього трафіку. Визначте IP-адреси офісу та команди, щоб ваші власні візити не змішувалися з клієнтськими. Переконайтеся, що фільтр активний, а не лише створений. Якщо IP у команди динамічні, фільтр за IP працюватиме нестабільно, тож варто обговорити з розробником інші способи.
- [ ] Список небажаних рефералів. Коли покупець після оплати повертається на сайт зі сторінки платіжної системи чи банку, джерелом замовлення може стати домен цієї системи. Додайте такі домени до списку, щоб замовлення лишалося за справжнім каналом: рекламою, пошуком чи розсилкою.
- [ ] Розширене вимірювання. Перевірте, що увімкнені події не дублюють ваші ручні налаштування (наприклад, надсилання форм) і що внутрішній пошук сайту визначається правильно.
- [ ] Ключові події. Позначте як ключові лише ті дії, які означають реальний результат для бізнесу.
- [ ] Зв'язок з Google Ads. Потрібен, щоб передавати дані між сервісами та використовувати аудиторії GA4 у рекламі.
- [ ] Зв'язок із Search Console. Дає змогу бачити в GA4 дані про пошукові запити й органічні сторінки.
- [ ] Google signals. Вмикайте свідомо: коли вам справді потрібні функції, пов'язані з рекламою та аудиторіями, і на сайті коректно працює механізм згоди. Як Google signals впливає на порогові значення у звітах, дивіться в довідці Google.
- [ ] Доступи. Перевірте, хто має доступ до ресурсу і з якою роллю. Приберіть колишніх підрядників і співробітників.
- [ ] Тест у DebugView. Пройдіть шлях клієнта самі: відкрийте сторінку, надішліть тестову заявку чи зробіть тестове замовлення і подивіться, які події та параметри прийшли.
Якщо ви вже налаштовували GA4 раніше і не впевнені в результаті, пройдіться цим списком як міні-аудитом.
Де шукати ці налаштування: орієнтовні шляхи в меню
Шляхи нижче наведено за англомовним інтерфейсом GA4. В українській версії назви пунктів можуть бути перекладені інакше, а сам Google час від часу переносить налаштування. Якщо пункту немає там, де вказано, шукайте його в довідці Google.
| Налаштування | Орієнтовний шлях |
|---|---|
| Потоки даних, ідентифікатор G-XXXXXXX, розширене вимірювання | Admin → Data collection and modification → Data streams → ваш вебпотік |
| Період зберігання даних | Admin → Data collection and modification → Data retention |
| Google signals | Admin → Data collection and modification → Data collection |
| Правило внутрішнього трафіку, небажані реферали | Admin → Data streams → ваш вебпотік → Configure tag settings → Show more |
| Активація фільтра внутрішнього трафіку | Admin → Data display → Data filters |
| Ключові події | Admin → Data display → Events або Key events |
| DebugView | Admin → Data display → DebugView |
| Зв'язки з Google Ads і Search Console | Admin → Product links |
| Доступи користувачів | Admin → Property access management |

Ключові події та електронна комерція
Як позначити подію як ключову
- Переконайтеся, що потрібна подія вже надходить у GA4: перевірте це в DebugView або у звіті подій.
- Якщо окремої події немає, її можна створити на основі наявної, наприклад, з перегляду сторінки «Дякуємо за заявку». Але надійніше надсилати окрему подію саме в момент успішного надсилання форми.
- Позначте подію як ключову в адміністративних налаштуваннях ресурсу (орієнтовний шлях є в таблиці вище). Якщо інтерфейс у вашому ресурсі відрізняється, звірте з довідкою Google.
Не робіть ключовими прокручування сторінки чи кліки на будь-які кнопки. Що більше «ключових» подій, то менше вони означають. Заявки з форм, кліки на телефон і на месенджери краще відстежувати окремими подіями, щоб у звітах було видно, яким способом клієнти звертаються найчастіше.
Карта подій інтернет-магазину
Базовий шлях покупця в магазині виглядає так:
- view_item — перегляд картки товару;
- add_to_cart — додавання в кошик;
- begin_checkout — початок оформлення;
- purchase — завершена покупка.
Повний перелік рекомендованих подій електронної комерції і їхніх параметрів (товари, сума, валюта, ідентифікатор транзакції) є в документації Google для розробників про електронну комерцію в GA4. Передайте її розробнику чи власнику модуля як технічне завдання.
Типові помилки
- Дублі purchase. Покупець оновлює сторінку подяки, на сайті стоять два способи встановлення, або покупку надсилають і з браузера, і з сервера без узгодження. Передавайте унікальний ідентифікатор транзакції і перевіряйте, що одне замовлення дає одну подію.
- Немає value або currency. Тоді подія є, а доходу у звітах немає або він показаний не в тій валюті.
- Purchase до підтвердження оплати. Подія спрацьовує, навіть якщо оплата не пройшла, і в GA4 з'являються «замовлення», яких немає в CRM.
- Порожній список товарів. Без даних про товари не працюють звіти про те, що саме купують.

Consent Mode: що потрібно знати
Режим згоди (Consent Mode) передає тегам Google вибір, який користувач зробив у банері cookies. Залежно від цього вибору теги змінюють свою поведінку. Через це, якщо частина відвідувачів не дає згоди, у звітах може бути менше даних, ніж реальних візитів і дій.
Для користувачів з Європейської економічної зони Google висуває окремі вимоги до передачі сигналів згоди, особливо для рекламних функцій. Перелік параметрів згоди і ці вимоги описано в документації Google для розробників. Звіряйте налаштування саме з нею, бо вимоги можуть оновлюватися.
Що перевірити з технічного боку:
- банер згоди (CMP) справді пов'язаний з тегами, а не просто показує повідомлення;
- до вибору користувача діє правильний стан згоди за замовчуванням;
- після вибору стан оновлюється, і це видно в Tag Assistant;
- усі теги на сайті, а не лише GA4, реагують на вибір користувача.
Важливо: це технічне пояснення, а не юридична консультація. Відповідність GDPR та іншим вимогам щодо захисту даних залежить від усього сайту: форм, CRM, інших пікселів, політики конфіденційності, договорів з підрядниками. Не лише від GA4. Юридичні питання обговорюйте з юристом.
Чому дані GA4 не збігаються з CRM і Google Ads
Розбіжності — це норма, а не обов'язково помилка. Важливо розуміти, звідки вони беруться, і відрізняти природні розбіжності від зламаного відстеження.
Різні моделі атрибуції та вікна конверсій
GA4 і Google Ads можуть по-різному визначати, якому каналу і якому дню приписати дію. Якщо людина спочатку клікнула рекламу, а через кілька днів повернулася з пошуку і купила, системи можуть розподілити цю покупку по-різному. Також у кожної системи свої налаштування періоду, протягом якого дію ще пов'язують із кліком.
Відмови від згоди та блокувальники реклами
Частина відвідувачів не дає згоди на cookies, у частини стоїть блокувальник реклами або браузер обмежує відстеження. У CRM замовлення від таких людей є, а в GA4 його може не бути або воно буде без джерела.
Часові пояси та валюти
Якщо в GA4, Google Ads і CRM різні часові пояси, замовлення «на межі доби» потрапляють у різні дні. Якщо різні валюти чи курси, не збігаються суми.
Різні визначення результату
CRM рахує угоди, оплачені замовлення, дзвінки й повторні звернення. GA4 рахує події на сайті. Скасування, повернення, замовлення по телефону, повторні покупки офлайн — усе це є в CRM, але не на сайті. Тому для питань про гроші й угоди зазвичай варто спиратися на CRM, а не на GA4. За умови, звісно, що саму CRM ведуть акуратно: угоди заносять вчасно, а статуси оновлюють.
Порогові значення та «(not set)»
- Порогові значення (thresholding). Щоб захистити приватність, GA4 може приховувати частину рядків у звітах, коли даних мало. Звіт виглядає «неповним», хоча дані зібрано.
- «(not set)». Так GA4 позначає значення, яке не було передано або не визначилося. Наприклад, у події немає потрібного параметра, або джерело візиту втрачено. Якщо «(not set)» багато, варто перевірити налаштування тегів.
Як звіряти дані на практиці
- Визначте джерело правди для кожного питання. Гроші та угоди — CRM. Поведінка на сайті — GA4. Оптимізація реклами — дані, які отримує Google Ads.
- Порівнюйте однакові речі. Той самий період, той самий часовий пояс, те саме визначення «замовлення».
- Звіряйте за ідентифікатором замовлення. Якщо в GA4 і CRM передається той самий номер замовлення, можна знайти конкретні замовлення, яких бракує.
- Дивіться на тенденції. Якщо розбіжність стабільна, найімовірніше, причини природні. Різкий стрибок — привід перевірити, чи щось не зламалося після оновлення сайту.
Для просунутих: BigQuery і Measurement Protocol
Експорт у BigQuery
Стандартні звіти GA4 показують агреговані дані. Експорт у BigQuery дає сирі дані на рівні подій, з якими можна працювати через SQL: будувати власні звіти, поєднувати дані з CRM, зберігати історію незалежно від налаштувань інтерфейсу. Умови зв'язку описано в довідці Google. BigQuery — окремий сервіс Google Cloud, тому заздалегідь з'ясуйте його умови та можливі витрати.
Measurement Protocol
Measurement Protocol дає змогу надсилати події в GA4 з сервера. Наприклад, коли угода в CRM переходить у статус «оплачено» або коли замовлення підтверджено офлайн.
Він доповнює тегування на сайті, а не замінює його. Щоб серверна подія пов'язалася з відвідувачем, потрібні ідентифікатори з браузерної частини. Тому таку схему планують разом з розробником і тими, хто відповідає за CRM.
Ліміти збору даних
GA4 має обмеження на назви подій, кількість параметрів, спеціальних параметрів і показників. Актуальні значення — на офіційній сторінці лімітів. Плануйте назви подій і параметрів заздалегідь, щоб не впертися в обмеження через хаотичне налаштування.
Потрібна допомога
Команда RBK Digital працює із сайтами, SEO, Google Ads і CRM, тому аналітику ми розглядаємо як частину всієї зв'язки, а не як окремий тег. Якщо GA4 потрібен вам разом із сайтом, рекламою в Google Ads чи CRM, напишіть нам. Спершу розберемося, які дані вам потрібні для рішень, і тоді скажемо, з чого почати. «Ідеально точних» цифр не обіцяємо, бо розбіжності між системами — це нормально. Зате допоможемо зрозуміти, звідки вони беруться і на які дані можна спиратися.
Часті запитання
Чи безкоштовний Google Analytics 4?
Стандартний ресурс GA4 можна створити і використовувати без оплати. Пов'язані сервіси можуть мати власні умови. Наприклад, BigQuery належить до Google Cloud, і його вартість варто з'ясувати заздалегідь на офіційних сторінках Google.
Куди поділися дані з Universal Analytics?
GA4 — окремий ресурс, він не продовжує історію Universal Analytics. Дані в ньому з'являються з моменту встановлення тегу GA4. Статус старих ресурсів і доступ до них Google описує на офіційній сторінці довідки про припинення роботи Universal Analytics.
Скільки зберігаються дані в GA4?
Це задається в налаштуваннях ресурсу. Термін визначає, наскільки далеко в минуле можна заглянути в дослідженнях. За описом Google, на стандартні агреговані звіти це налаштування не впливає, але точні умови і доступні варіанти звірте в довідці Google про зберігання даних. Виставте потрібне значення одразу після створення ресурсу, бо вже видалені дані не відновлюються.
Як виключити свої візити з GA4?
Додайте IP-адреси офісу в правило внутрішнього трафіку і ввімкніть фільтр, бо лише створений фільтр нічого не відсіює. Якщо адреси в команди постійно змінюються, з розробником варто підібрати інший спосіб позначати внутрішні візити.
Як перевірити, що GA4 працює?
Відкрийте сайт і подивіться звіт у реальному часі. Заходьте з мережі поза офісом, наприклад з телефона через мобільний інтернет: якщо фільтр внутрішнього трафіку вже активний, візит з офісного IP у звіті не з'явиться. Для детальної перевірки подій і параметрів скористайтеся DebugView, а Tag Assistant покаже, які теги спрацювали на сторінці і з яким ідентифікатором вимірювання.
Що означає «(not set)» у звітах GA4?
Так GA4 позначає значення, яке не було передано або не визначилося: наприклад, у події бракує параметра або джерело візиту втрачено. Трохи «(not set)» буває завжди, але якщо таких рядків багато, варто перевірити налаштування тегів.