Відкрий свій GA4 у сусідній вкладці. Знайди відповідь на одне питання: скільки заявок або замовлень сайт приніс минулого тижня? Якщо за пів хвилини ти бачиш лише «Користувачі» та графік відвідувань, справа не в тому, що треба пройти курс аналітики. Можливо, сайт просто не передає в GA4 дії, заради яких працює бізнес.
Google Analytics 4, або GA4, збирає дані про те, звідки люди прийшли на сайт і що там зробили. Для малого бізнесу корисна версія налаштування починається з трьох запитань: що вважаємо результатом, у який момент його фіксуємо та як перевіримо, що запис у GA4 відповідає реальній події. Встановлений тег сам по собі на них не відповідає.
Нижче пройдемо шлях на умовному інтернет-магазині спортивного харчування. У нього є каталог, кошик, доставка Новою Поштою та кнопки Viber і Telegram. Це навчальний приклад, а не клієнтський кейс GrandMa. Він потрібен, щоб показати, де закінчується клік і починається замовлення.
1. Що саме рахує GA4
У GA4 основна одиниця вимірювання - подія. Відкриття сторінки може створити page_view, перегляд товару - view_item, початок оформлення - begin_checkout, завершене замовлення - purchase. До події можна додати параметри: наприклад, назву товару, його ідентифікатор, суму або валюту. Google описує рекомендовані назви й параметри, щоб звіти однаково розуміли типові дії магазину.
Сесія, користувач і подія відповідають на різні питання. «Користувачі» показують оцінку кількості людей, «Сесії» - відвідування, а «Події» - зафіксовані дії. Одна людина може відкрити п’ять карток і двічі почати оформлення. Тому 100 переглядів товару не дорівнюють 100 покупцям. Стару Universal Analytics часто згадують через цілі та перегляди сторінок; у GA4 важливі дії спершу визначають як події, а потім деякі з них позначають як ключові події.
Повернися до відкритої вкладки. У розділі Reports знайди Realtime для перевірки поточного трафіку. Якщо опублікована колекція Life cycle, у ній Acquisition → Traffic acquisition допомагає подивитися джерела відвідувань, а Engagement → Events - назви та кількість подій. Google описує склад колекції Life cycle; адміністратор може налаштувати навігацію, тому відсутність одного пункту в меню не доводить, що збір даних вимкнений. Назви тут наведено за англомовною довідкою Google, українська локалізація може відрізнятися.
Поки ігноруй спокусу розібрати всі звіти. Знайди одну подію, що відповідає реальному замовленню. Якщо її немає, наступна робота відбувається не у графіку, а в налаштуванні сайту.
2. План подій для одного магазину
У нашому умовному магазині людина відкриває протеїн, додає його в кошик, переходить до оформлення, обирає доставку й створює замовлення. Вона також може написати в Telegram замість покупки на сайті. Це різні кроки з різним значенням для бізнесу.
| Подія | Коли надсилати | Потрібний контекст | Ключова? | Як перевірити |
|---|---|---|---|---|
page_view |
Сторінка справді відкрилася | Адреса сторінки без персональних даних | Ні | Відкрити сторінку й побачити одну подію, а не дві від дубльованих тегів. |
view_item |
Відкрилася картка конкретного товару | items із ідентифікатором товару |
Ні | Порівняти item_id у DebugView із відкритою карткою. |
add_to_cart |
Товар дійсно додано в кошик | items, за наявності коректні value і currency |
Зазвичай ні | Спробувати успіх і помилку додавання. |
begin_checkout |
Почався процес оформлення | items, сума та валюта, якщо вони відомі |
Зазвичай ні | Відкрити оформлення й перевірити одну подію. |
purchase |
Система створила або підтвердила замовлення за узгодженим правилом | Унікальний transaction_id, value, currency, items |
Так, якщо це головний результат | Зробити тестове замовлення й звірити ID та суму з адмінкою магазину. |
| Клік у Viber чи Telegram | Людина натиснула посилання на месенджер | Назва каналу без тексту повідомлення | Ні: клік не підтверджує розмову | Натиснути кожне посилання й перевірити, чи подія не дублюється. |
| Клік по номеру телефону | Людина натиснула tel:-посилання |
Місце кнопки або тип контакту, без номера користувача | Ні: клік не доводить дзвінок | Перевірити на телефоні й окремо звірити дані телефонії, якщо вона є. |
Це план, а не вимога впровадити всі сім рядків у перший день. Спершу потрібні purchase та кілька кроків, які допомагають знайти втрату покупця. Якщо в магазині немає онлайн-оплати, домовся, що означає «покупка» у вашій моделі: створене замовлення, оплачене замовлення чи відвантаження. Не називай першу подію продажем, якщо гроші надходять пізніше. За потреби веди ці статуси в адмінці або CRM й звіряй із GA4 окремо.
Для purchase унікальний transaction_id особливо важливий. Google пояснює, як він допомагає уникати повторного підрахунку тієї самої покупки у вебпотоці. Порожній або однаковий ID для різних замовлень спотворює дані. Номер замовлення може бути ID, якщо він не містить персональних даних покупця.
3. Що можна ввімкнути без власного коду, а що потребує налаштування
Почни з офіційної послідовності Google: обліковий запис Analytics, ресурс GA4, вебпотік для сайту, тег збору даних. У вебпотоку є Measurement ID, що починається з G-. Звір його з тегом на сайті, щоб не надсилати дані в тестовий або підрядниковий ресурс. Бізнес має контролювати доступ до ресурсу, а фахівець - мати потрібну роль для налаштування.
Тег можна додати засобами платформи магазину, безпосередньо в коді або через Google Tag Manager. Обери контрольований спосіб і перевір дублювання. Якщо платформа вже встановлює GA4, ще один тег у Tag Manager може двічі надсилати page_view або purchase. Для магазину це гірше, ніж відсутність красивого дашборда: він показуватиме продажі, яких не було.
Enhanced measurement у вебпотоці може збирати перегляди сторінок, вихідні переходи, взаємодії з формами та інші базові дії без змін у коді сторінки. Це зручний старт, але його form_submit не означає автоматично, що менеджер отримав заявку. Вихідний click показує перехід за посиланням, а не повідомлення, надіслане в месенджері. Перевір кожний потрібний сценарій на конкретному сайті; кнопка, що працює через скрипт, може потребувати окремого тригера.
Події електронної торгівлі на кшталт add_to_cart і purchase не збираються GA4 автоматично для довільного магазину. Їх передає платформа або налаштована інтеграція. Google Tag Manager може бути місцем налаштування тегів і тригерів, але він не вгадує, коли магазин підтвердив замовлення, та не створює коректні items і transaction_id без даних із сайту. Постав розробнику або інтегратору точне завдання: яка подія відбувається, коли, з якими параметрами та як уникнути повторного надсилання.
Коротке ТЗ для фахівця можна записати так: «Після підтвердження успішного оформлення замовлення надсилати один purchase у наш ресурс GA4. Передавати унікальний ID замовлення, суму в гривнях, валюту UAH та куплені товари. Не надсилати подію при помилці оплати або повторному відкритті сторінки підтвердження. Показати тест у DebugView і те саме замовлення в адмінці». Це не готовий код для кожної платформи. Це умови приймання, за якими власник зможе перевірити роботу, навіть якщо сам не відкриває Tag Manager.
Для кнопок месенджерів запиши окрему умову: що саме рахуємо, за якою назвою та чи може одна дія породити і автоматичний click, і власну подію. Інакше звіт подарує тобі два «контакти» за одну спробу написати повідомлення. Після тесту збережи план подій біля доступів до аналітики, щоб наступний підрядник не відновлював логіку за здогадками.
4. Які дії позначати ключовими
Ключова подія в GA4 - це подія, особливо важлива для успіху бізнесу. У прикладі магазину таким кандидатом є purchase. Перегляд товару й додавання в кошик потрібні для діагностики, але їх не варто автоматично записувати в графу результатів. Для бізнесу із заявками ключовою може бути generate_lead, коли звернення справді створено й потрапило в робочий процес. qualify_lead означає наступний статус, який команда підтвердила за своїми критеріями; сам GA4 не вирішить, чи клієнт підходить.
Не став статус ключової події кліку по Viber тільки тому, що там часто купують. Частина людей відкриє чат і нічого не напише. Якщо треба рахувати саме діалоги, потрібне окреме підтвердження з месенджера або CRM і надійний спосіб співвіднести його з джерелом переходу. Поки цього немає, підписуй метрику «кліки в месенджер» і не підмінюй нею заявки.
Шлях до налаштування ключових подій може змінюватися разом з інтерфейсом GA4. Для тебе важливіше правило: спершу перевір тригер події, потім позначай її ключовою. Позначка біля помилкової події робить помилку помітнішою у звіті, а не виправляє її.
5. Тест, після якого налаштування можна приймати
Зроби окреме тестове замовлення. Перед цим відкрий Google Tag Assistant або режим попереднього перегляду Tag Manager. Вони допоможуть увімкнути режим налагодження для твого пристрою. Потім у GA4 відкрий Admin → Data display → DebugView: Google описує саме цей маршрут. Події мають з’являтися в послідовності, яку ти пройшов: картка, кошик, оформлення, покупка.
Натисни на purchase у DebugView. Звір transaction_id, валюту, суму й товар із записом в адмінці магазину. Повернися на сторінку підтвердження або онови її: покупка не повинна перетворюватися на нову тільки від повторного відкриття. Окремо пройди невдале оформлення та скасування до завершення. Там не має бути purchase. У Realtime можна перевірити надходження даних, але для детального аналізу параметрів під час тесту зручніший DebugView.
Після цього звір зовнішню реальність. Чи є замовлення в системі магазину? Чи прийшло підтвердження? Чи воно не створилося двічі? Ми вже описували випадок, коли форма казала «дякуємо», а заявка не доходила до команди. Подія в браузері не є доказом доставки до менеджера.
Якщо в DebugView порожньо, перевір чотири речі: чи вибраний правильний ресурс і G- ID, чи ввімкнений режим налагодження для твого пристрою, чи спрацював тег, і чи дозволяють це налаштування приватності та згода. Google прямо зазначає, що за певних обмежень на клієнтському боці або без згоди на аналітичні cookie події можуть не відображатися в DebugView. Не лікуй це примусовим збором даних усупереч вибору відвідувача.
У звичайні події не передавай ім’я, email, телефон, текст повідомлення чи ці дані в URL. Правила Google Analytics забороняють надсилати персональні дані, які ідентифікують людину. Для перевірки потрібні назва дії, технічний ID замовлення без особистих даних і коректні неперсональні параметри.
6. Згода й межі точності
Якщо сайт працює з відвідувачами з Європейської економічної зони, перевір правила щодо cookie й персональних даних для своєї реалізації. Google вимагає відповідних сигналів згоди для певних сценаріїв вимірювання й рекламної персоналізації в ЄЕЗ. Consent Mode передає вибір людини тегам Google; це технічний механізм, а не заміна коректного банера та політики. Google описує зв’язок банера і Consent Mode. Європейська комісія також дає відвідувачам вибір щодо аналітичних cookie на власних сайтах.
Коли людина відмовляється від згоди, має блокувальник або браузер обмежує відстеження, цифри можуть бути неповними. Не обіцяй звірку «до останнього користувача». Перевір, що система поважає вибір, а звіт пояснює межу даних. Для комерційного рішення зіставляй GA4 із замовленнями магазину та даними CRM, бо ці системи відповідають на різні питання.
7. Що дивитися щопонеділка за 10 хвилин
Повернімося до вкладки з GA4. Обери минулий повний тиждень і подивись на три питання:
| Питання | Де шукати | Із чим звірити |
|---|---|---|
Скільки було purchase або підтверджених generate_lead? |
Events або стовпець Key events у відповідному звіті | Замовлення в адмінці чи заявки в CRM за той самий період і часовий пояс. |
| З яких каналів прийшли ці дії? | Traffic acquisition, вибравши потрібну ключову подію | Джерела замовлень у бізнес-системі; не роби висновків із одного дуже малого тижня. |
| Де люди зупиняються на шляху до результату? | Події view_item, add_to_cart, begin_checkout, purchase або звіт шляху покупки |
Реальні помилки оформлення, доставка, оплата, повторні питання клієнтів. |
Звіряй однакові періоди та часові пояси. Після зміни тега запиши дату, щоб не порівнювати тиждень із новим набором подій зі старим як наче умови однакові. Якщо замовлень мало, одне додаткове замовлення зробить відсотковий графік дуже драматичним. Перед рішенням про бюджет подивись на самі записи та якість звернень.
У кейсі Ratner Beauty ми використовували архівовані дані GA4, щоб показати частку каналу: 62,7% усіх сесій за 1 липня 2025 - 30 червня 2026 року припадали на Organic Search. Це перевірений показник джерела відвідувань за конкретний період. Кейс не публікує кількість продажів чи виручку, тож я не роблю з цієї частки висновок про покупки. Так само твої «сеанси з пошуку» не замінять у звіті підтверджені замовлення.
Якщо потрібен план, що саме міряти до налаштування тегів, у нас є окремий матеріал про план вимірювання GA4. Для B2B реклами ми окремо розбираємо якість конверсій Google Ads. Якщо події вже є, але команда не може з них ухвалити рішення, послуга GrandMa з аналітики починається зі зв’язку між подіями, заявками та питаннями бізнесу.
8. FAQ
9. Джерела
- Google Analytics: налаштування ресурсу, вебпотоку й тега
- Google Analytics: рекомендовані події та параметри
- Google Analytics: Enhanced measurement
- Google Analytics: події електронної торгівлі
- Google Analytics: ключові події
- Google Analytics: DebugView
- Google Analytics: згода в ЄЕЗ
- GrandMa: кейс Ratner Beauty за липень 2025 - червень 2026
