Які інструменти аналітики потрібні маркетингу?

Якби десь у 2017 році мене попросили назвати базовий набір інструментів для вебаналітика, схема була б доволі простою: Google Tag Manager збирає дані, а Google Analytics допомагає їх аналізувати. Для багатьох компаній ці два інструменти й досі залишаються єдиними інструментами. Але сьогодні такого набору вже недостатньо.

І причина не в тому, що інтерфейс GA4 незручний порівняно з Universal Analytics. Змінилася сама логіка роботи з даними: частина інформації тепер не доходить до аналітичних систем через поширення блокувальників реклами, частина взаємодій відбувається поза сайтом, а реальні дані про клієнтів, замовлення й оплати зберігаються в CRM або внутрішніх системах бізнесу, частина інформації втрачається через нюанси роботи певних браузерів тощо. Так світ змінився за ці майже 10 років. І аналітика теж дуже сильно змінилася.

Сучасну вебаналітику варто будувати не навколо одного інтерфейсу, а як архітектуру, що поєднує GA4, CRM, рекламні платформи, сховище даних, BI-систему та інструменти серверного збору даних. GA4 у цій архітектурі залишається важливим компонентом, але вже не може бути єдиним джерелом правди. У статті я розберу, які інструменти потрібні маркетинговій команді, як вони пов’язані між собою та, найголовніше, які завдання допомагає вирішувати кожен інструмент.

• Чому можливостей GA4 уже недостатньо
  • Чому передавання CRM-конверсій у GA4 не дає повної картини
• Як побудувати повноцінну систему вебаналітики
  • Два завдання сучасної аналітики: звітність і оптимізація реклами
  • CRM як джерело даних про клієнтів і продажі
  • Чому важливо мати окреме сховище даних
    • Хмарне чи self-hosted сховище?
    • Чому для маркетингової аналітики варто розглянути BigQuery?
  • Як завантажити й підготувати дані в BigQuery
    • Завантаження даних: BigQuery Data Transfer Service, Google Cloud Datastream, Fivetran, Airbyte та власні інтеграції через Google Cloud
    • Трансформація даних: dbt і Dataform
  • Використання підготовлених даних
    • BI-система: перетворення даних на звіти
    • Використання даних для реклами
      • Передача конверсій у Google Ads
      • Передача конверсій у Meta, Tik Tok та інші платформи
      • Передача аудиторій у рекламні платформи
  • GTM, server-side GTM та Google Tag Gateway: збір, передавання та згода
    • Як працює server-side GTM
    • Google Tag Gateway чи server-side GTM?
  • Додаткові інструменти, які можуть доповнювати аналітичний стек
    • Consent Management Platform (CMP): керування згодою користувачів
    • Session replay, heatmaps та UX-аналітика
    • CDP — Customer Data Platform
    • A/B-тестування та feature flags
    • Агенти для роботи з даними
• Як сформувати стек під конкретні завдання бізнесу
• Замість висновку
• FAQ
  • Які альтернативи GA4 існують?
  • Дані про конверсії з BigQuery надходять у Google Ads із затримкою. Чи можна пришвидшити їх передавання, щоб PPC-фахівці швидше ухвалювали рішення?
  • Як краще налаштувати передачу даних з CRM до Google Ads: з CRM до GA4, а потім імпортувати конверсії з GA4 до Google Ads чи передавати з CRM напряму до Google Ads?
  • Якщо перенести код Meta Pixel із браузера на сервер, хто генеруватиме ідентифікатори кліку? Чи зможе Meta визначити, з якого оголошення прийшов користувач, якщо _fbc та _fbp формуються самостійно?
  • Чи має сенс налаштовувати server-side GTM, якщо сайт відвідують лише 200–500 користувачів на день?
  • Чи можна створити окремі акаунти або серверні контейнери GTM для різних сайтів і як їх кількість впливає на вартість?
  • Чому частина продажів може потрапити в direct після повернення користувача з платіжної системи та чи допоможе передавання даних із CRM відновити джерело трафіку?
  • Як оцінювати вплив медійних кампаній, якщо користувачі не клікають на рекламу, але після її запуску зростають прямі продажі та кількість брендових запитів?

Далі буде детальний розбір нюансів підбору систем. Але якщо ви хочете одразу перейти до фінальної схеми — клікніть тут.

Чому можливостей GA4 уже недостатньо

Google Analytics традиційно був першою системою, про яку згадували, коли йшлося про вебаналітику. Це логічно: інструмент безкоштовний, відомий ринку й добре закриває базове завдання — показує, як користувачі взаємодіють із сайтом або застосунком. Проблема не в тому, що GA4 став “поганим”. Просто шлях клієнта став іншим, і сьогодні він бачить лише частину цього шляху.

Прогалини виникають одразу на кількох рівнях:

• Частина вебданих не доходить до GA4.
  Браузери обмежують термін зберігання cookie, блокувальники реклами зупиняють частину запитів, а вимоги щодо згоди користувачів створюють додаткові прогалини.
• Реальний бізнес-результат часто відбувається не на сайті.
  Багато років тому достатньо було фіксувати кількість трафіку на сайт і кількість відправлених форм. Але сучасна вебаналітика йде набагато далі: до реальних покупок і повторних покупок. GA4 може зафіксувати заявку, перехід на сторінку подяки або початок оформлення замовлення, але не знати, чи відбулася оплата, чи скасували замовлення та яку суму бізнес зрештою отримав. Інформація про клієнтів, продажі й гроші зазвичай зберігається в CRM чи внутрішній базі даних.
• Шлях до покупки виходить за межі сайту.
  Спочатку вебаналітика будувалася переважно навколо сесій, потім у центрі опинився користувач, а тепер до його шляху додаються агенти, які можуть діяти від його імені. Користувач уже може знайти товар, порівняти пропозиції та оформити замовлення всередині ШІ-інтерфейсу. Google розвиває Universal Cart та Universal Commerce Protocol, а OpenAI — Agentic Commerce Protocol. Частина взаємодій із брендом поступово відбувається поза сайтом, тому GA4 фізично не може бачити весь контекст.

Як наслідок, сучасна аналітика вже давно не лише про відповідь на запитання “Що користувач робив на сайті?”. Вона повинна допомагати зрозуміти:

• хто зрештою став клієнтом;
• що саме він придбав;
• скільки грошей приніс бізнесу;
• які маркетингові взаємодії могли вплинути на рішення;
• які дані потрібно повернути в рекламні системи для подальшої оптимізації тощо.

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

Чому передавання CRM-конверсій у GA4 не дає повної картини

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

Але тут є декілька важливих обмежень.

• По-перше, якщо ви хочете, щоб офлайн-подія коректно успадкувала джерело, канал і кампанію конкретної онлайн-сесії, Google рекомендує передавати її не пізніше ніж через 24 години від початку цієї сесії, а максимальний відведений на це час становить 72 години — це жорстке обмеження самого Measurement Protocol.
  
  Уявімо SaaS-продукт із семиденним пробним періодом. Сьогодні користувач прийшов із Google Ads і активував його, а через сім днів оплатив підписку. Через згадані часові ліміти ви вже не зможете коректно «повернути» цю оплату в ту саму початкову сесію та показати GA4, що саме вона принесла дохід. Якщо в інтернет-магазині період від оформлення замовлення на сайті до моменту, коли користувач його забрав, становить більше 72 годин — теж упретеся в обмеження.
  
• По-друге, для зв’язування офлайн-події з користувачем і сесією потрібні правильні ідентифікатори, зокрема client_id та session_id. Але якщо умовний блокувальник реклами не дозволив створити cookie або користувач відмовився від аналітичного відстеження, цих ідентифікаторів у вас просто не буде.
  
  Звісно, можна придумати новий client_id. Але тоді GA4 побачить окремого користувача, якого не зможе пов’язати з попередньою рекламною взаємодією. Це приблизно як прийти до аналітичної системи й сказати: “Тарас зробив покупку”, а у відповідь почути: “Який Тарас? Я його ніколи не бачив”.

Саме тому передавання CRM-конверсій у GA4 не варто сприймати як універсальний спосіб побудови наскрізної аналітики.

У деяких кейсах це може працювати: наприклад, якщо майже всі покупки відбуваються протягом короткого часу, у вас зберігаються потрібні ідентифікатори та немає суттєвих прогалин через використання банерів згоди користувача. Але для більшості бізнесів краще поєднувати GA4 і CRM не всередині Google Analytics, а в окремому сховищі даних.

Тож далі розберемо, з яких компонентів має складатися повноцінна система вебаналітики та як поєднати їх між собою.

Як побудувати повноцінну систему вебаналітики

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

Два завдання сучасної аналітики: звітність і оптимізація реклами

Сучасну вебаналітику корисно умовно розділити на дві частини.

• Перша — аналітика для аналітики.
  Її мета — зібрати дані з різних систем, обробити їх, побудувати звіти та допомогти бізнесу ухвалювати рішення.
• Друга — аналітика для реклами.
  Дані потрібні не лише людям, а й алгоритмам рекламних платформ. Google Ads, Meta Ads, LinkedIn та інші мають розуміти, які заявки завершилися реальною оплатою та які клієнти мають найбільшу цінність.

Ці дві частини не існують окремо. Якщо ви вже зібрали в одному місці інформацію з CRM, GA4, рекламних кабінетів, email-розсилок і call tracking, ті самі підготовлені дані можна використовувати і для звітності, і для оптимізації реклами.

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

CRM як джерело даних про клієнтів і продажі

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

Саме CRM або система, яка виконує її функції, має бути джерелом правди щодо продажів. В ідеальному світі суми в ній повинні узгоджуватися з тим, що відбувається на банківських рахунках компанії. Якщо клієнт заплатив, у CRM має бути зрозуміло, хто це зробив, коли, за який товар або послугу та на яку суму.

Якщо такої системи у вас немає, будувати повноцінну маркетингову аналітику буде дуже складно. Ви можете аналізувати трафік, кліки та поведінку на сайті, але не матимете надійної відповіді на головне запитання: скільки грошей бізнес реально заробив і які маркетингові активності на це вплинули.

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

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

Чому важливо мати окреме сховище даних

Потреба у сховищі виникає тоді, коли для відповіді на бізнесове запитання вже недостатньо даних однієї системи. GA4 показує взаємодії із сайтом, CRM — клієнтів, замовлення й оплати, рекламні платформи — витрати та результати кампаній. Поки ця інформація зберігається окремо, бізнес бачить лише фрагменти шляху клієнта.

Можна будувати прямі інтеграції між кожною парою систем, але з кожним новим джерелом така схема стає складнішою: потрібно підтримувати більше зв’язків. Аналітики про це подумали і вирішили, що логічніше зробити незалежне сховище центральною точкою аналітичної архітектури.

У такій архітектурі кожна система передає до сховища ту частину інформації, за яку вона відповідає:

1. GA4 передає до сховища дані про взаємодію із сайтом;
2. CRM передає інформацію про клієнтів, замовлення та оплати;
3. рекламні платформи додають витрати, кампанії, кліки й покази;
4. інші маркетингові системи передають власні дані;
5. уже всередині сховища все це обробляється та поєднується.

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

Головна перевага архітектури з окремим сховищем полягає в тому, що бізнес контролює зібрані дані й не залежить від інтерфейсу однієї платформи. Якщо компанія вирішить змінити CRM, історична інформація залишиться у сховищі. Якщо Google випустить чергову версію Google Analytics або прибере частину функціоналу, ваші дані не зникнуть. Якщо рекламний кабінет заблокують, попередні результати все одно будуть доступні для аналізу.

У нашій практиці були проєкти, які змінювали CRM, але продовжували працювати з усією історією, тому що вона заздалегідь накопичувалася в такому сховищі. Те саме відбулося під час переходу з Universal Analytics на GA4: перенести всю історію в новий інтерфейс було неможливо, але дані зі старої системи можна було зберегти в окремому сховищі й використовувати далі.

Хмарне чи self-hosted сховище

Після того як роль сховища зрозуміла, наступне рішення — де його розмістити. На верхньому рівні сховища можна розділити на хмарні та self-hosted.

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

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

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

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

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

Серед популярних варіантів — Google BigQuery, Snowflake, а також рішення для побудови сховищ у хмарних екосистемах AWS та Microsoft Azure. Усі вони можуть закривати сучасні аналітичні завдання. Але для маркетингової аналітики я найчастіше рекомендую саме BigQuery.

Чому для маркетингової аналітики варто розглянути BigQuery

Я не стверджую, що BigQuery технічно найкращий у кожній можливій ситуації. Десь Snowflake або інший згаданий вище продукт може мати перевагу. Але якщо ви будуєте маркетингову аналітику з нуля, BigQuery має сильний практичний аргумент — він є частиною екосистеми Google.

Можна легко уявити компанію, яка не рекламується на Amazon або не використовує Microsoft Advertising. Але складно уявити сучасний онлайн-бізнес, який не має нічого з екосистеми Google: Google Ads, GA4, Search Console, Merchant Center, YouTube, Google Play тощо. І нативні інтеграції BigQuery з іншими сервісами Google часто економлять маркетинговій команді час і бюджет, який в іншому випадку пішов би на тижні додаткової розробки.

Особливо важливим для маркетингової аналітики є експорт GA4 у BigQuery. Це єдиний нативний спосіб регулярно отримувати сирі події Google Analytics на рівні окремих записів. Через API звітності ви отримуєте вже оброблені й агреговані дані, а не повний сирий набір.

Навіть якщо основне корпоративне сховище компанії розташоване в Azure або іншій екосистемі, BigQuery може залишатися проміжною ланкою для експорту GA4: спочатку сирі події надходять у BigQuery, а вже потім передаються до основного сховища.

Водночас BigQuery може працювати не лише як місце зберігання. У поєднанні з іншими сервісами Google Cloud він допомагає завантажувати, трансформувати, аналізувати та передавати дані в інші системи. Тому далі розберемо практичне питання: як зібрати в BigQuery дані з різних джерел і підготувати їх до звітності та використання в маркетингових платформах. А трохи пізніше в цьому ж матеріалі я розберу, чому BigQuery ще й зручний для передачі даних до рекламних систем.

Як завантажити й підготувати дані в BigQuery

Завантаження даних: BigQuery Data Transfer Service, Google Cloud Datastream, Fivetran, Airbyte та власні інтеграції через Google Cloud

Ми визначили, навіщо потрібне сховище та чому для маркетингової аналітики варто розглянути BigQuery. Тепер головне практичне питання: як доставити туди дані з CRM, рекламних платформ, платіжних сервісів та інших джерел?

Універсальної відповіді немає. Залежно від джерела можна використати нативну інтеграцію, готовий сторонній конектор або власний код.

BigQuery Data Transfer Service

BigQuery Data Transfer Service дозволяє налаштувати регулярне автоматичне завантаження даних без власної інфраструктури.

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

• Google Ads;
• Google Merchant Center;
• YouTube;
• Google Play;
• Campaign Manager та інші продукти Google;
• Facebook Ads;
• Salesforce;
• HubSpot;
• Klaviyo;
• Mailchimp;
• Shopify;
• Stripe;
• PayPal;
• PostgreSQL, MySQL, SQL Server та інші бази.

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

Google Cloud Datastream

Datastream призначений передусім для реплікації змін з операційних баз даних. Він працює за логікою Change Data Capture: відстежує вставлення, оновлення та видалення записів і передає ці зміни в BigQuery з низькою затримкою.

Це хороший варіант, коли CRM або внутрішня система працює на PostgreSQL, MySQL, SQL Server, Oracle чи іншому підтримуваному джерелі, а бізнесу потрібні майже актуальні дані без регулярного повного копіювання таблиць.

Data Transfer Service і Datastream вирішують різні задачі. Перший зручний для запланованого завантаження даних із SaaS, маркетингових платформ і баз даних; другий — для безперервного перенесення змін з операційних систем.

Fivetran та Airbyte

Якщо нативних можливостей Google недостатньо або вони не підходять під конкретну систему, можна використати готові сторонні рішення. Серед найпопулярніших — Fivetran та Airbyte.

Вони мають велику бібліотеку конекторів і можуть передавати дані не лише в BigQuery, а й в інші сховища. Це важливий момент: якщо ваша інфраструктура побудована на Snowflake, Azure або AWS, такі сервіси теж можуть закрити значну частину інтеграцій.

Власні інтеграції через Google Cloud

Якщо готового рішення немає, можна написати власний процес завантаження. У Google Cloud для цього часто використовується зв’язка:

1. Cloud Scheduler запускає процес за розкладом.
2. Pub/Sub передає повідомлення про запуск.
3. Cloud Run function виконує код, отримує дані через API та записує їх у BigQuery.

Код найчастіше пишуть на Python, але доступні й інші середовища, зокрема Node.js.

На слух це може здаватися набором окремих складних сервісів. Насправді всі вони розташовані в межах Google Cloud і нормально працюють разом. Саме це я маю на увазі, коли кажу, що BigQuery — не просто база даних, а частина великої екосистеми.

Трансформація даних: dbt і Dataform

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

• Найвідоміший інструмент у цій категорії — dbt. Він став фактичним стандартом для організації аналітичних трансформацій у багатьох командах.

• Google має власне рішення — Dataform. Обидва інструменти можуть працювати з BigQuery та мають свої переваги й недоліки.

У наших проєктах ми використовуємо Dataform: він є частиною Google Cloud і закриває наші поточні завдання. Для інфраструктури, побудованої навколо BigQuery, це зручний варіант, оскільки всі основні інструменти залишаються в межах однієї екосистеми.

Але це наш практичний вибір, а не універсальна рекомендація. dbt також є сильним рішенням, тому, якщо команда вже має готовий dbt-проєкт, відповідні компетенції та налагоджені процеси, переходити на Dataform лише через його присутність у Google Cloud немає потреби.

Якщо ж ви вирішили використовувати іншу хмару — dbt буде оптимальним вибором.

Використання підготовлених даних

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

BI-система: перетворення даних на звіти

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

Для цього використовуються BI-системи. Серед найвідоміших:

• Power BI;
• Tableau;
• Data Studio (Looker Studio).

Що вибрати? Якщо у вас достатньо компетенцій і часу на налаштування, у більшості типових маркетингових задач Power BI, Tableau або Data Studio (Looker Studio) дозволять отримати якісний і досить схожий результат. Різниця буде в ціні, екосистемі, зручності для команди та особливостях конкретного проєкту.

Ми найчастіше використовуємо Power BI. І причина доволі банальна: історично він мав найнижчий поріг входу за вартістю ліцензії, особливо для невеликих команд. На великих enterprise-проєктах фінальна вартість різних платформ може зближуватися, але для малого та середнього бізнесу стартова ціна має значення.

Ну і те, що Power BI з року в рік займає найвищі позиції в рейтингах інструментів бізнес-аналітики, теж, звісно, відіграє свою роль.

Водночас я не вважаю, що Power BI — єдино правильна відповідь. Якщо команда вже працює в Tableau, Data Studio (Looker Studio) або іншій BI-системі й вона закриває завдання, немає сенсу змінювати її лише заради зміни.

Використання даних для реклами

Підготовлені дані можна повертати в рекламні платформи для двох основних завдань: передавати підтверджені конверсії та оновлювати аудиторії на основі даних CRM. Спочатку розберемо передавання конверсій, а потім — роботу з аудиторіями.

Передача конверсій у Google Ads

У GA4 може бути подія переходу на сторінку подяки. Але сторінка подяки ще не означає реальну оплату: замовлення могли скасувати, платіж міг не пройти. Рекламному алгоритму значно корисніше отримати фінальний статус із CRM.

Для Google Ads існує нативна інтеграція через Data Manager. Ви можете підключити BigQuery як джерело та використовувати підготовлені дані для трекінгу конверсій.

Це особливо корисно в кейсах із довгим циклом продажу:

• користувач залишив заявку сьогодні, а оплатив через тиждень;
• клієнт активував trial і придбав підписку пізніше;
• продаж підтверджується менеджером у CRM;
• цінність замовлення змінюється після повернення або допродажу.

У таких випадках логічніше зберегти реальний результат у BigQuery та передати його безпосередньо в рекламну систему, а не спочатку намагатися відтворити покупку в GA4.

Передача конверсій у Meta, TikTok та інші платформи

Для Meta та багатьох інших рекламних систем немає настільки ж простої нативної зв’язки з BigQuery, як для Google Ads. Підтверджені конверсії можна передавати через API за допомогою власної Cloud Run function.

Той самий підхід працює з платформами, які мають Conversion API або інший серверний endpoint: Meta, TikTok, Pinterest, Snapchat, Microsoft Advertising та інші.

Через API можна передавати підтверджені конверсії. Частота залежатиме від завдання: для одних проєктів достатньо одного оновлення на добу, для інших важливо надсилати події одразу.

Передача аудиторій у рекламні платформи

Рекламним платформам можна передавати не лише підтверджені конверсії. У BigQuery можна сформувати сегменти на основі CRM-даних, а потім передати їх у Google Ads через рідну інтеграцію або регулярно оновлювати в Meta, TikTok та інших платформах через API. Наприклад:

• клієнти, які припинили оплачувати підписку;
• покупці певної категорії товарів;
• користувачі з високим LTV;
• клієнти, які придбали одну частину комплекту, але не придбали іншу;
• користувачі, яким настав час запропонувати повторну покупку.

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

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

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

У результаті BigQuery стає не лише місцем зберігання, а центральною точкою, з якої підготовлені дані надходять у BI-системи, рекламні платформи, email-сервіси та CRM. Повна схема нижче показує весь цикл: від збору й об’єднання даних до побудови звітів і передавання потрібних сигналів у маркетингові системи.

Але й це ще не все, тому що в сучасному світі хороша аналітична система має дати вам можливість легко інтегрувати її з агентами для роботи з даними. І наша поточна схема під це прекрасно підходить. У вас навіть буде декілька варіантів: ви зможете використовувати вбудований агент Conversational Analytics у BigQuery (тут за посиланням детальна інструкція про те, як це зробити від мене) або підключати своїх власних агентів до даних у BigQuery чи Power BI (а тут за посиланням про одне з рішень, яке ми зробили нашому партнеру).

Тепер, коли ми обговорили основну архітектуру сучасної вебаналітики, трохи зупинюся на іншому. Як я писав на початку матеріалу, базовими інструментами вебаналітики завжди були Google Analytics та Google Tag Manager. У що зараз трансформувався Google Analytics, ми розібрали вище. Давайте тепер розберемо все, що стосується GTM.

GTM, server-side GTM та Google Tag Gateway: збір, передавання

Щоб дані можна було поєднати й використати, спочатку їх потрібно правильно зібрати та передати із сайту до потрібних систем. На цьому рівні основну роль відіграють GTM, server-side GTM і Google Tag Gateway.

Для більшості проєктів базовим інструментом залишається Google Tag Manager. Він дозволяє реагувати на дії користувачів і передавати інформацію в GA4, Google Ads, Meta та інші системи без постійного внесення змін безпосередньо в код сайту.

У традиційній схемі вебконтейнер GTM працює в браузері:

1. Користувач виконує дію на сайті.
2. Вебконтейнер отримує інформацію про цю дію.
3. Теги надсилають запити безпосередньо в GA4 та рекламні платформи.

Тобто браузер напряму взаємодіє зі сторонніми платформами:

Схема взята з офіційної довідки: https://developers.google.com/tag-platform/tag-manager/server-side/intro

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

Саме тут з’являється server-side Google Tag Manager.

Як працює server-side GTM

У схемі із server-side GTM між сайтом і зовнішніми платформами додається серверний контейнер:

1. Вебконтейнер надсилає дані на ваш tagging server.
2. Серверний контейнер обробляє запит.
3. Уже з нього інформація передається в GA4, Google Ads, Meta, TikTok та інші системи.

Тобто server-side GTM додає контрольований серверний рівень між сайтом і зовнішніми системами.

Схема взята з офіційної довідки: https://developers.google.com/tag-platform/tag-manager/server-side/intro

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

Google Tag Gateway чи server-side GTM?

Google Tag Gateway дозволяє завантажувати Google tag і надсилати частину вимірювальних запитів через first-party-інфраструктуру вашого сайту. Налаштувати його можна через підтримуваний CDN, load balancer, вебсервер або разом із серверним тегуванням.

На перший погляд Google Tag Gateway і server-side GTM вирішують схожу задачу: допомагають працювати з Google measurement у first-party-контексті. Але повними аналогами їх називати не варто.

Google Tag Gateway зосереджений передусім на Google tag та продуктах Google. Server-side GTM дає ширші можливості:

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

Якщо ви вже маєте правильно налаштований server-side GTM, швидше за все, ви вже використовуєте first-party-підхід. Водночас актуальна документація Google описує і комбіновану архітектуру, у якій CDN завантажує Google-скрипти з first-party-домену, а серверний контейнер відповідає за збір та обробку даних.

Отже, вибір залежить від завдання: Google Tag Gateway допомагає перевести роботу Google tag у first-party-контекст із меншими ресурсами, а server-side GTM потрібен, коли важливі ширша маршрутизація, обробка, контроль даних та first-party-підхід для інших рекламних платформ.

Додаткові інструменти, які можуть доповнювати аналітичний стек

До цього моменту ми побудували базову систему:

• CRM або внутрішня база зберігає інформацію про клієнтів і дохід;
• GA4 збирає дані про взаємодію із сайтом;
• BigQuery об’єднує різні джерела;
• BI-система візуалізує результат;
• дані повертаються в рекламні та маркетингові платформи;
• GTM, server-side GTM і Google Tag Gateway відповідають за технічний рівень збору та передавання подій.

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

Consent Management Platform (CMP): керування згодою користувачів

Якщо бізнес працює в регіонах, де потрібна згода користувача на аналітичні та рекламні cookie, наприклад у ЄЕЗ, варто використовувати спеціалізовану Consent Management Platform.

Це важливо не лише для дотримання вимог GDPR. Некоректне передавання сигналів згоди може обмежити використання даних для вимірювання конверсій, оптимізації кампаній і персоналізації реклами в Google Ads. Конкретний приклад такої ситуації ми розібрали у статті “Нема банеру — нема конверсій. Google почав блокувати передачу даних до Google Ads”.

Серед рішень, із якими ми працюємо та які можемо рекомендувати:

• CookieYes;
• Cookiebot;
• iubenda.

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

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

Session replay, heatmaps та UX-аналітика

Кількісна аналітика показує, що сталося: скільки користувачів залишило сторінку, на якому етапі впала конверсія, який сегмент поводиться гірше.

Але інколи потрібно зрозуміти, чому це сталося. Тут допомагають:

• записи сесій;
• heatmaps;
• опитування;
• аналіз кліків і скролінгу;
• інші UX-дослідження.

Серед найпопулярніших інструментів — Microsoft Clarity і Hotjar. Clarity безкоштовний, тому для базового старту часто немає причини його не протестувати.

На мою думку, одним із найсильніших спеціалізованих продуктів за функціональністю є FullStory. Серед інших варіантів можна розглянути Crazy Egg.

Також записи сесій та суміжну функціональність мають комплексніші платформи, зокрема PostHog і Amplitude. У Matomo подібна функціональність доступна окремо через Heatmap & Session Recording. Якщо продукт уже використовує одну з цих платформ, спочатку перевірте, чи доступна потрібна можливість у вашому тарифі або конфігурації.

Саме тут може з’явитися аргумент на користь заміни GA4. Якщо вам потрібен не один інструмент, а одночасно продуктова аналітика, session replay, експерименти та feature flags, платформа на кшталт PostHog може виявитися практичнішою. Але якщо потрібен лише базовий збір вебданих, GA4 усе ще часто буде простішим рішенням.

CDP — Customer Data Platform

Customer Data Platform — це система, яка:

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

Серед відомих прикладів — Twilio Segment і RudderStack. RudderStack історично розвивався як open-source-рішення, хоча його актуальна модель і доступність окремих компонентів змінювалися.

Ми не використовуємо окрему CDP у своїй базовій архітектурі, тому що значну частину тих самих задач можна реалізувати в BigQuery за допомогою правильної моделі даних та SQL.

Але це не означає, що CDP не потрібна нікому. Якщо компанія вже використовує Segment або іншу платформу, вона закриває потрібні сценарії та вписується в бюджет, немає сенсу відмовлятися від неї лише тому, що подібну логіку теоретично можна написати самостійно.

A/B-тестування та feature flags

Для експериментів я рекомендую звернути увагу на GrowthBook. Він може працювати у self-hosted-форматі або як платний сервіс, інтегрується з BigQuery та добре вписується в описаний стек.

Окремо існують feature flags. Це не обов’язково A/B-тест. Наприклад, команда запускає нову функцію в SaaS-продукті, але не хоче одразу відкривати її всім користувачам. За допомогою feature flag можна поступово ввімкнути функціональність для невеликої частини аудиторії, перевірити стабільність і лише потім розширити доступ.

Такі можливості, зокрема, має PostHog. Якщо вам одночасно потрібні продуктова аналітика, записи сесій, експерименти та feature flags, це ще один аргумент розглянути комплексну платформу замість набору окремих інструментів.

Агенти для роботи з даними

І, звісно, у сучасному стеку вже не можна ігнорувати ШІ-агентів. Для роботи з аналітикою можна використовувати різні рішення:

• BigQuery Conversational Analytics — функціонал для роботи з даними природною мовою та створення data agents безпосередньо в BigQuery;
• Claude;
• Codex (ChatGPT);
• Manus.

Вони закривають різні задачі. Conversational Analytics корисний для керованої роботи з корпоративними даними через природну мову та є частиною Google Cloud Platform, а значить, не потребує підключення додаткових сервісів. А умовні Claude чи Codex можуть виконувати багатоетапні задачі та працювати як самостійний ШІ-помічник.

Але тут діє те саме правило, що й для будь-якого іншого інструмента: агент не виправляє погані дані. Якщо таблиці брудні, бізнес-логіка не задокументована, а показники в різних системах рахуються по-різному, ШІ лише швидше створить упевнено сформульовану неправильну відповідь.

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

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

Як сформувати стек під конкретні завдання бізнесу

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

Базовий стек для більшості компаній можна звести до такої логіки:

1. CRM або внутрішня база зберігає клієнтів, замовлення та реальні оплати.
2. GA4 збирає доступні дані про взаємодію із сайтом або застосунком.
3. Google Tag Manager керує вебтегами, за потреби server-side GTM додає серверний рівень збору й передавання даних.
4. BigQuery об’єднує CRM, GA4, рекламні кабінети та інші джерела.
5. Dataform або dbt систематизує трансформації.
6. Power BI, Tableau або Data Studio перетворює дані на зрозумілі звіти.
7. Підготовлені дані повертаються в Google Ads, Meta, email-платформи та CRM для оптимізації й автоматизації.

Усе інше додається лише тоді, коли виникає реальне завдання:

• потрібна юридично коректна згода — підключаємо CMP;
• потрібно зрозуміти поведінку на сторінці — тимчасово або постійно використовуємо session replay;
• потрібен єдиний профіль клієнта й готові інтеграції для використання даних у маркетингових каналах — розглядаємо CDP;
• запускаємо експерименти — додаємо GrowthBook;
• потрібні feature flags — використовуємо PostHog або інший відповідний продукт;
• хочемо спростити доступ до даних — створюємо й налаштовуємо data agent.

Замість висновку

Google Analytics 4 нікуди не зник і все ще залишається важливою частиною вебаналітики. Але сучасна система не може закінчуватися всередині його інтерфейсу.

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

Хороший стек не обов’язково має бути великим. Він має бути цілісним: збирати доступні дані, зберігати їх у середовищі, яке контролює бізнес, поєднувати різні джерела, допомагати людям ухвалювати рішення та повертати якісні сигнали рекламним алгоритмам.

FAQ

Які альтернативи GA4 існують?

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

До маркетингових альтернатив належать, наприклад:

• Adobe Analytics — потужне й дороге enterprise-рішення для великих міжнародних компаній;
• Matomo — інструмент із можливістю самостійного розгортання та більшим контролем над даними;
• Piwik PRO — рішення, яке часто розглядають компанії з високими вимогами до конфіденційності та роботи на європейському ринку.

Для продуктової аналітики часто використовують:

• Amplitude — часто подають як стандарт індустрії для продуктових задач;
• Mixpanel — класична альтернатива Amplitude;
• PostHog — новіша, але дуже комплексна система, яка полюбилася ком’юніті.

Вони допомагають глибше аналізувати поведінку всередині продукту, будувати воронки, працювати з утриманням, записами сесій, експериментами або feature flags.

Але всі ці рішення об’єднує один момент: за розширений функціонал потрібно платити, а сам факт оплати не гарантує, що система збере більше даних. Браузерні та юридичні обмеження нікуди не зникають лише тому, що ви замінили Google Analytics на інший продукт.

Тому моя базова рекомендація така: якщо у вас немає конкретної причини відмовлятися від GA4, залиште його як систему збору даних. Просто не намагайтеся зробити його єдиним місцем для всієї аналітики.

Інша система може бути виправданою, якщо вам потрібна специфічна продуктова функціональність, самостійне розгортання, особливі вимоги до конфіденційності або комплекс можливостей, які разом вигідніше отримати в одному продукті. Але вибір має починатися із завдання, а не з бажання знайти “новий GA4”.

Дані про конверсії з BigQuery надходять у Google Ads із затримкою. Чи можна пришвидшити їх передавання, щоб PPC-фахівці швидше ухвалювали рішення?

Так. Нативна інтеграція BigQuery через Google Ads Data Manager підтримує запланований імпорт максимум раз на день. Якщо цього недостатньо, конверсії можна передавати частіше через Data Manager API. Наприклад, процес можна автоматизувати через Cloud Scheduler, Pub/Sub і Cloud Run function та запускати з потрібною періодичністю.

Але тут важливо розділяти дві речі: швидкість надходження даних і реальну користь від їх частішого передавання для рекламних алгоритмів. Сам факт того, що ви будете надсилати конверсії щогодини замість одного разу на день, ще не гарантує кращої оптимізації кампаній. Крім того, частіше надсилання не означає, що конверсії миттєво з’являться у звітах Google Ads: платформі все одно потрібен час на обробку імпортованих даних.

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

Як краще налаштувати передачу даних з CRM до Google Ads: з CRM до GA4, а потім імпортувати конверсії з GA4 до Google Ads чи передавати з CRM напряму до Google Ads?

Якщо підтверджена інформація про замовлення вже зберігається в CRM, базі даних або BigQuery, логічніше передати її безпосередньо в Google Ads, а не спочатку відправляти покупку в GA4, а потім імпортувати її звідти в рекламу.

Якщо ви будуєте повноцінну архітектуру для вебаналітики, то найкраще буде налаштувати одну передачу даних з CRM до Google BigQuery, а вже з BigQuery розкидати по рекламних кабінетах. Для цього можна підключити BigQuery як джерело конверсій у Google Ads Data Manager. Якщо потрібне частіше, ніж щоденне, передавання — використовувати Data Manager API.

Тобто схема виглядатиме так: CRM → BigQuery → Google Ads.

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

Якщо перенести код Meta Pixel із браузера на сервер, хто генеруватиме ідентифікатори кліку? Чи зможе Meta визначити, з якого оголошення прийшов користувач, якщо _fbc та _fbp формуються самостійно?

Тут важливо не плутати ідентифікатор кліку, який створює Meta, і cookie, які формуються на його основі. Коли користувач клікає на оголошення, Meta сама генерує ідентифікатор кліку та додає його в URL як GET-параметр fbclid. Тобто цей ідентифікатор не потрібно вигадувати самостійно: Meta вже створила його і знає, якому рекламному кліку він відповідає.

У браузері відповідні cookie називаються _fbc та _fbp, а в Conversions API передаються параметри fbc та fbp.

На сайті на основі значення fbclid можна самостійно сформувати _fbc. Спрощено, воно містить отриманий від Meta ідентифікатор кліку та timestamp. Для цього не обов’язково завантажувати всю бібліотеку Meta Pixel — потрібну логіку можна реалізувати невеликим JavaScript-кодом. _fbp також можна сформувати самостійно. Він використовується як браузерний ідентифікатор і складається, зокрема, з часової мітки та випадкового значення.

Тому самостійне формування _fbc та _fbp не означає, що ви самостійно придумуєте рекламний click ID. Значення fbclid усе одно приходить від Meta. Ви лише зберігаєте його у потрібному форматі та передаєте разом із подією через Conversions API. Якщо рекламного кліку і значення fbclid не було, вигадувати fbclid або fbc самостійно не варто.

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

Чи має сенс налаштовувати server-side GTM, якщо сайт відвідують лише 200–500 користувачів на день?

Я б не прив’язував рішення про server-side GTM безпосередньо до кількості відвідувачів. Немає такого, що його переваги починають працювати після певного порогу трафіку. Server-side GTM допомагає вам зменшити кількість сторонніх скриптів у браузері, отримати більше контролю над даними та працювати у first-party-контексті за умови відповідного налаштування власного домену — ці переваги існують і при 100 користувачах на день, і при 100 000.

Інше питання — економічна доцільність. Для невеликого інтернет-магазину з низькою маржинальністю додаткові витрати на сервер і налаштування можуть не окупатися. Для B2B-бізнесу ті самі 200–500 відвідувачів на день можуть приносити кілька дорогих угод, для яких аналіз ланцюжка взаємодії клієнтів із сайтом відіграє важливу роль.

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

Чи можна створити окремі акаунти або серверні контейнери GTM для різних сайтів і як їх кількість впливає на вартість?

Так. У Google Tag Manager можна створювати окремі акаунти та окремі серверні контейнери для різних сайтів так само, як ви створюєте звичайні вебконтейнери. Під час створення контейнера просто обирається тип Server замість Web.

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

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

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

Розміщувати server-side GTM можна, наприклад, у Google Cloud або на власній серверній інфраструктурі. Другий варіант у багатьох випадках може бути дешевшим, але потребує відповідних технічних компетенцій.

Чому частина продажів може потрапити в direct після повернення користувача з платіжної системи та чи допоможе передавання даних із CRM відновити джерело трафіку?

Домени платіжних систем завжди варто додавати до списку unwanted referrals. Тому насамперед варто перевірити дві речі: чи не створює платіжна система небажане referral-джерело та чи зберігаються між переходами той самий браузерний контекст, client_id і сесія.

Наприклад, користувач може перейти на сайт із реклами Facebook у внутрішньому браузері застосунку, а на певному етапі оплати відкрити сторінку вже у звичайному браузері. Для GA4 це потенційно може бути інший client_id і, відповідно, інший користувач та нова сесія. У такому випадку початковий рекламний контакт залишається в одному браузерному контексті, а фінальна покупка — в іншому. Для GA4 вона може виглядати як direct або взагалі не мати коректного зв’язку з попередньою сесією.

Передавання покупки з CRM саме по собі цю проблему не вирішує. Якщо просто відправити в GA4 фінальне замовлення з новим або вигаданим client_id, система не знатиме, до якого попереднього користувача його прив’язати.

Тому важливіше заздалегідь зберігати ідентифікатори та маркетинговий контекст разом із замовленням: наприклад, client_id, session_id, рекламні click ID, UTM-параметри або інші доступні ідентифікатори. Тоді після появи підтвердженої покупки в CRM ці дані можна поєднати на рівні BigQuery.

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

Як оцінювати вплив медійних кампаній, якщо користувачі не клікають на рекламу, але після її запуску зростають прямі продажі та кількість брендових запитів?

У такій ситуації класичної click-based атрибуції вже недостатньо. Якщо людина побачила рекламу, запам’ятала бренд, а через декілька днів самостійно ввела його назву в Google або напряму відкрила сайт, у вебаналітиці фінальний візит може виглядати як organic або direct. Це не означає, що медійна реклама не вплинула на покупку. Але й автоматично приписувати їй усе зростання direct-продажів теж неправильно.

Перший додатковий сигнал для display- і video-кампаній — view-through conversions: вони показують конверсії користувачів, які бачили рекламу, не клікали на неї, але пізніше конвертувалися. Це корисний атрибуційний сигнал, але він сам по собі ще не доводить причинно-наслідковий вплив реклами.

Для великих бізнесів із достатньою історією даних можна також використовувати Marketing Mix Modeling (MMM). Він допомагає оцінювати внесок різних маркетингових каналів без необхідності ідентифікувати кожного конкретного користувача.

Але MMM — це не готова кнопка в інтерфейсі аналітики (якщо у вас не Google Analytics 360). Для нормальної моделі потрібно зібрати й підготувати історичні дані, врахувати сезонність та інші фактори, побудувати й перевірити модель. Тому це вже окрема аналітична задача, яка може потребувати суттєвої роботи з даними.

Головне правило тут просте: зростання direct-продажів і брендових запитів після запуску кампанії — хороший сигнал, але ще не доказ причинно-наслідкового зв’язку.