Замовити послугу →

Без категорії

Кейс: аудит та налаштування Google Analytics 4 (GA4) ecommerce для сервісу продажу квитків

Буряк Марія | 01 Тра 2026 | 3 хв читання 4 переглядів

У цій статті ми задокументуємо аудит ecommerce модуля в Google Analytics 4, який ми провели для одного з наших клієнтів. Мета цієї статті — представити приклад та обсяг робіт з аудиту та налаштування GA4 для кастомних сервісів та інтернет-магазинів.

Навіщо відстежувати додаткові дані в Google Analytics?

Основна мета відстеження цих даних — подальший аналіз рекламних каналів, зафіксованих у Google Analytics. Наприклад, це допомагає порівняти ефективність реклами Google Ads проти реклами в Instagram. Налаштування ecommerce модуля в GA4 не тільки дозволяє порівнювати вартість лідів за каналами, але й збирати дані про доходи з цих каналів для порівняння ефективності.

Результати аудиту та формат

Аудит конверсій та технічні вимоги до налаштування ecommerce модуля GA4 задокументовані в Google Docs.

Вступна інформація

Цей документ містить аналіз поточного стану веб-аналітики, зокрема даних про конверсії. Він також окреслює технічні вимоги для додаткової конфігурації.

Інформація про проєкт Вебсайт – [project website]

Технології вебсайту

Інструменти веб-аналітики

Огляд коду веб-аналітики

Розміщення кодів аналітики Основні та другорядні фрагменти коду GTM загалом реалізовані коректно. Код містить кілька кастомізацій та додаткових конфігурацій. Також вбудовані коди GA4 та DataLayer, разом з різними іншими скриптами, деякі з яких реалізовані некоректно.

Огляд системи веб-аналітики

Огляд Google Tag Manager Контейнер GTM загалом налаштований коректно.

Відстеження ключових дій GTM налаштований для відстеження значущих дій користувачів та передачі їх до GA4.

Відстеження конверсій Конфігурації відстеження конверсій існують у GTM та вихідному коді вебсайту для продажу квитків. Однак, як покаже аудит, відстеження є неточним.

Тестування конверсій Аудит та подальше налаштування були викликані припущенням, що GA4 коректно відстежує купівлю квитків — як миттєві онлайн-платежі, так і бронювання з оплатою водієві. Однак аналіз показав, що відстеження конверсій має кілька суттєвих помилок.

Тестові покупки Ми провели тестування реєстрації квитків, використовуючи такі дані:

Результати тестування 21.05.2024 ми провели кілька тестових покупок з опцією «оплата водієві». Аналітика успішно зафіксувала конверсії, але загальна вартість конверсій відображала лише останню транзакцію.

Аналіз статистики конверсій

Огляд таблиці продажів Ми проаналізували поточний файл статистики замовлень, який показує:

Аналіз звітів ecommerce в GA4 Звіти ecommerce в GA4 не відображають точно всі дані про продажі. Доступні приклади фрагментів консолідованих звітів, але записуються лише часткові дані.

Порівняння таблиці та звіту Ми порівняли таблицю продажів квитків та звіт GA4 за період з 01.04.2024 по 21.05.2024:

Розбіжності є значними і потребують подальшого дослідження.

Систематизація відстеження конверсій

Загальна інформація
Оскільки проведений аналіз виявив суттєві помилки у відстеженні конверсій, має сенс не тільки виявити та локально виправити ці помилки, але й провести більш комплексну систематизацію відстеження ecommerce подій на сайті.

Квитки як товари
В рамках цього проєкту доцільно розглядати квитки як окремі товари, що відрізняються містом відправлення та містом призначення.

Це дозволить у майбутньому будувати інформативні звіти за комбінаціями міст відправлення та прибуття.

Квитки як пари товарів
Інший, дещо специфічний, але цікавий підхід — фіксувати перегляд або купівлю квитка як комбінацію двох товарів — міста відправлення та міста призначення.

У такому випадку в майбутньому можна буде генерувати більш зручні та інформативні звіти щодо економічної популярності конкретних міст.

Категорії товарів
На найвищому рівні країну можна фіксувати як категорію товару.

Ієрархія категорій товарів
Потенційна структура може включати чотири рівні вкладених категорій товарного каталогу:

Така структура також дозволить отримати високоінформативні звіти за містами та країнами.

Бренди
Назву перевізника можна відстежувати в системі веб-аналітики як бренд товару. Це дозволить у майбутньому отримувати звіти за різними перевізниками.

Параметри товару
Додаткову інформацію з товарів слід фіксувати в системі веб-аналітики як параметри товару.

Зокрема, дуже важливим параметром є дата та час відправлення придбаного квитка.
Інші параметри покупки включають ім’я та номер телефону пасажира.

Параметри транзакції
Дата та час покупки будуть автоматично зафіксовані як параметри транзакції.
Ще одним ключовим параметром транзакції є обраний спосіб оплати.

Також є можливість генерувати та фіксувати унікальні ID транзакцій на рівні системи сайту в системі аналітики.

Вартість конверсії
На цьому етапі налаштування веб-аналітики вартість конверсії може бути зафіксована як загальна вартість придбаних або заброньованих квитків.

Відповідно, вартість продажу товару — це ціна, зафіксована з урахуванням можливих знижок та бонусів для певних маршрутів чи перевізників.

Відстеження конверсій
Основною подією, яку необхідно відстежувати, є завершена конверсія — купівля одного або декількох квитків.

Відстеження переглядів товарів
Окрім конверсій та продажів товарів, ми також можемо відстежувати перегляди товарів.

Зокрема, коли користувач вибирає місто відправлення та місто призначення у формі, це може бути зафіксовано як перегляд товару.

Відстеження додавання до кошика
Натискання кнопки «Купити» може бути зафіксовано як дія «додавання до кошика».

У майбутньому це може дозволити ремаркетинг для покинутих кошиків.

Відстеження етапів оформлення замовлення
Ми можемо відстежувати прогрес користувачів через окремі етапи процесу оформлення замовлення.

Зокрема:

Відстеження цих етапів допоможе переконатися, що користувачі належним чином завершують кожен етап і досягають сторінки доставки квитка.

Тестування показує наявність певних проблем, але лише відстеження в реальному часі, збір даних та подальший аналіз зможуть показати, як часто вони виникають у реальних користувачів.

Відстеження скасувань
Фактична посадка та відсоток оплати водієві можуть бути значно нижчими за одиницю. Вони також можуть сильно відрізнятися залежно від міст, маркетингових каналів та періодів часу.

Для моніторингу цього показника та усунення очевидно некоректних транзакцій доцільно впровадити відстеження скасувань.

Це може бути реалізовано як повернення товарів. Однак це вимагає не лише конфігурації сайту, але й базової CRM-системи для обробки замовлень.

По суті, це перший крок до повноцінної аналітики маркетингу та продажів по всьому воронці.

Відстеження прибутку
Другий крок до аналітики по всьому воронці — відстеження не тільки обсягу продажів, але й валового прибутку від конкретних продажів для компанії.

Це дозволить моніторити та оптимізувати ROI сегментів платного трафіку за кампаніями, групами оголошень, креативами, аудиторіями та іншими параметрами.

Технічні завдання для підготовки Data Layer

Загальна інформація
Цей розділ окреслює технічні завдання, які необхідно реалізувати на стороні системи сайту.

Вони стосуються налаштування спеціальної JavaScript-змінної під назвою Data Layer.

На різних сторінках та за різних умов у цю змінну необхідно передавати значення різних параметрів. Ці значення мають бути отримані з коду системи сайту.

Нижче параметри, які слід замінити на актуальні значення, вказані в кутових дужках (<>). Як дужки, так і вміст у них слід замінити на актуальні значення.

Увага! Дуже важливо зберігати навколишні подвійні лапки (“”) на початку та в кінці значень, якщо вони вказані в шаблонах та прикладах коду.

Існуючий код
Певні блоки коду, подібні до наведених нижче, раніше були додані до деяких розділів сайту.

Вони були призначені для відстеження продажів. Однак, як зазначено вище в цьому документі, вони містять суттєві обмеження і навіть помилки.

Тому, будь ласка, задокументуйте розташування цих блоків коду. Також рекомендуємо зберегти поточну версію сайту перед внесенням будь-яких змін.

Після цього, під час впровадження кодів, наведених нижче, видаліть або дуже уважно оновіть існуючий код, щоб він точно відповідав новій структурі.

Перегляд квитків за парою міст

Умови виконання коду:
Цей код має спрацьовувати під час завантаження сторінки, коли відображаються доступні або недоступні маршрути для обраної пари міст відправлення та прибуття — тобто під час завантаження сторінки з доступними маршрутами.

Шаблон сторінки:
URL цих сторінок починається з [site URL] і містить назви та коди міст відправлення та прибуття.

Код для розміщення та активації:

Приклад відповідного призначення значення параметра:

Вибір конкретного квитка

Умови розміщення та активації коду:
Цей код має спрацьовувати після натискання кнопки «Вибрати квиток», коли користувач обрав дату та конкретний маршрут на цю дату.

Шаблон сторінки:
Ті самі сторінки, що описані в попередньому розділі.

Код для активації:

Приклад відповідного призначення значення параметра:

Початок оформлення квитка

Умови розміщення та активації коду:
Цей код має спрацьовувати під час завантаження сторінки «Оформлення квитка».

Шаблон сторінки:
URL цих сторінок починається з [site URL] і містить хеш-код обраного маршруту.

Код для активації:

Приклад відповідного призначення значення параметра:


Додавання пасажира

Умови розміщення та активації коду:
Цей код має спрацьовувати на сторінці «Оформлення квитка» після кожного натискання кнопки «Додати пасажира».
Увага! Він має спрацьовувати після кожного натискання.

Шаблон сторінки:
Та сама сторінка, що й у попередньому розділі.

Код для активації:

Приклад відповідного призначення значення параметра:

Перехід до параметрів оплати

Умови розміщення та активації коду:
Цей код має спрацьовувати на сторінці «Оформлення квитка» після кожного натискання кнопки «Далі», але лише за умови заповнення всіх необхідних даних та переходу користувача до сторінки параметрів оплати.
Увага! Якщо будь-які необхідні дані відсутні, цей код не повинен виконуватися.

Шаблон сторінки:
Та сама сторінка, що й у попередньому розділі.

Код для активації:

Приклад коректного заповнення значень параметрів:

Вибрана оплата на місці

Умови розміщення та активації коду:
Цей код має спрацьовувати на другому етапі процесу «Бронювання квитка», зокрема після натискання кнопки «Оплата на місці».

Увага! Цей код повинен виконуватися лише за умови проходження всіх валідацій, зокрема, якщо встановлено прапорець «Я погоджуюсь з…».

Шаблон сторінки:
URL цієї сторінки відповідає шаблону.

Код для виконання:

Приклад заповнення значень параметрів:

Вибрана онлайн-оплата

Умови розміщення та активації коду:
Цей код повинен активуватися на другому етапі «Купівлі квитка», а саме після натискання кнопки «Онлайн-оплата».

Увага! Цей код повинен виконуватися лише за умови проходження всіх перевірок, зокрема, якщо вибрано прапорець «Я погоджуюсь з…».

Шаблон сторінки:
Такий самий, як у попередньому пункті.

Код для ініціації:

Приклад заповнення значень параметрів:

Квитки продано!

Умови розміщення та активації коду:
Цей код повинен активуватися під час завантаження фінальної сторінки «Готово!», що підтверджує успішне бронювання та оплату квитка, якщо обрано цей варіант.

Шаблон сторінки:
Адреса цих сторінок починається з [website URL] і містить код транзакції.

Код для ініціації виконання:

Приклад заповнення значень параметрів:

P.S. Якщо у вас виникнуть питання щодо цього технічного завдання та аудиту, ви можете залишити запит на консультацію на сайті нашого агентства – https://spilnoagency.com.ua/

Часті запитання

Як я можу дізнатися більше про цю тему?

Рекомендуємо ознайомитися з іншими статтями нашого блогу та офіційною документацією. Наш контент регулярно оновлюється, щоб відображати останні зміни у 2025 році.

Чи можу я отримати консультацію?

Так, ви можете звернутися до нашої команди для безкоштовної консультації через форму зворотного зв’язку на нашому сайті. Ми допоможемо вам знайти найкраще рішення для потреб вашого бізнесу.

Чи є доступні безкоштовні інструменти?

Більшість інструментів, описаних у цій статті, пропонують безкоштовні плани або пробні версії. Перегляньте розділ з цінами у статті для детальної інформації.

Буряк Марія Spilno Agency Всі статті автора →
← Повернутися до блогу