Server-side трекінг і Consent Mode v2: якість даних у 2026 році
Що дає серверне тегування, чим воно відрізняється від Google tag gateway, як працює режим згоди v2 і з чого почати, щоб Smart Bidding отримував чисті дані.
Команда AdsConceptGoogle Partner · практики Google Ads
Коротко
- Дані про конверсії втрачаються не через «смерть cookie»: Chrome у 2025 році відмовився від відключення сторонніх cookie. Втрати дають блокувальники, обмеження Safari і Firefox, відмови в згоді та помилки розмітки.
- Захист даних — це кілька рівнів: правильна розмітка і режим згоди v2, розширені конверсії, офлайн-конверсії з CRM, і лише потім — Google tag gateway або серверний GTM.
- Server-side трекінг дає контроль над даними, довговічніші first-party cookie і менше сторонніх скриптів, але не обходить згоду користувача і не виправляє погано спроєктовані події.
- Режим згоди v2 обов’язковий для трафіку з ЄЕЗ, Великої Британії і Швейцарії. Розширений режим дає моделювання конверсій для тих, хто відмовився від cookie.
- Якість даних — це не разове налаштування, а щомісячна перевірка.
Кілька років тому ринок жив очікуванням «кінця cookie», і серверне тегування продавали як порятунок від цього кінця. У 2025 році Google вирішив не відключати сторонні cookie в Chrome, а більшість технологій Privacy Sandbox згорнув. Проте проблема втрати даних нікуди не зникла — вона просто ніколи не була лише про Chrome.
Розберімо, звідки насправді беруться втрати, що з цим робить server-side трекінг і де без нього цілком можна обійтися.
Звідки втрачаються дані
- Блокувальники реклами і трекерів. Розширення браузера і деякі браузери за замовчуванням блокують запити до відомих доменів аналітики і реклами.
- Обмеження Safari і Firefox. Safari обмежує строк життя cookie, встановлених через JavaScript, і в приватному режимі може прибирати з URL відомі параметри відстеження. Людина клікнула на оголошення з iPhone, повернулася за тиждень — і зв’язок із кліком уже втрачено.
- Відмова від згоди. Якщо у вас є трафік із ЄЕЗ і людина відмовилася від cookie, теги не можуть зберігати ідентифікатори.
- Технічні помилки. Редирект, що відрізає GCLID, форма на сторонньому сервісі без передачі параметрів, платіжний шлюз, після якого сесія «рветься», дублі тегів.
- Міжпристроєвий шлях. Клік із телефона, заявка з ноутбука. Без розширених конверсій така конверсія часто не прив’язується до реклами.
Для Smart Bidding кожна втрачена конверсія — це сигнал «цей клік не спрацював». Алгоритм знижує ставки на аудиторії і запити, які насправді приносять продажі.
Рівні захисту даних
Ми вибудовуємо вимірювання від простого до складного. Пропускати нижні рівні заради верхніх немає сенсу.
| Рівень | Що це | Що вирішує | Чого не вирішує |
|---|---|---|---|
| 1. Чиста розмітка і режим згоди v2 | Google tag або GTM, коректні події, банер згоди | Дублі, помилки подій, юридично коректний збір даних | Блокувальники, обмеження Safari |
| 2. Розширені конверсії | Хешовані email або телефон разом із конверсією | Міжпристроєві конверсії, частина втрат через cookie | Втрати, коли тег узагалі заблоковано |
| 3. Офлайн-конверсії з CRM | Передача кваліфікованих лідів і продажів у Google Ads | Оптимізація на реальні продажі, а не на форми | Втрати на рівні сайту |
| 4. Google tag gateway | Тег Google завантажується з вашого домену через CDN або балансувальник | Частину блокувань доменів Google, без окремого сервера | Обробку і збагачення даних |
| 5. Серверний GTM | Власний серверний контейнер, що приймає і передає події | Контроль даних, фільтрацію, довговічніші cookie, передачу в кілька систем | Згоду користувача, якість самих подій |
Як працює серверне тегування
У класичній схемі браузер відвідувача сам відправляє дані в Google Analytics, Google Ads, Meta і інші сервіси. Кожен сервіс — окремий скрипт і окремий запит до стороннього домену.
У серверній схемі браузер відправляє події на вашу власну адресу, наприклад на піддомен або шлях вашого сайту. Там працює серверний контейнер Google Tag Manager, який:
- Приймає події через клієнти, наприклад клієнт GA4.
- Обробляє їх: прибирає персональні дані з URL, додає дані з вашої бази (маржу, статус клієнта), фільтрує ботів і тестові події.
- Передає далі в GA4, Google Ads, Meta Conversions API та інші системи — уже з сервера.
- Встановлює first-party cookie через HTTP-відповідь вашого домену, що робить їх довговічнішими, ніж cookie, встановлені скриптом.
Важливий технічний нюанс для Safari: щоб серверні cookie справді вважалися first-party, серверний контейнер має працювати в тій самій інфраструктурі, що й сайт, або бути доступним через шлях на основному домені. Якщо піддомен вказує на зовсім інші IP-адреси, Safari може застосувати ті самі обмеження, що й до cookie зі скриптів.
Що треба для запуску
- серверний контейнер у GTM;
- хостинг: Google Cloud Run або керований сервіс для серверного GTM;
- налаштування власного домену чи шляху для контейнера;
- переведення веб-тегів на відправлення даних у серверний контейнер;
- перенесення тегів GA4, Google Ads і інших систем у серверний контейнер;
- моніторинг: серверний контейнер — це інфраструктура, за якою треба стежити.
Хостинг коштує грошей щомісяця, і сума залежить від трафіку. Тому ми рахуємо, чи окупить точність даних витрати саме для вашого обсягу.
Чого server-side не робить
Тут найбільше міфів, тому скажемо прямо:
- Не обходить згоду. Якщо людина відмовилася від рекламних cookie, серверний контейнер має поважати це рішення так само, як і браузерний.
- Не виправляє погані події. Якщо в браузері подія «покупка» спрацьовує двічі, сервер чесно передасть обидві.
- Не повертає всіх заблокованих користувачів. Частина блокувальників працює не лише за доменами, а й за шаблонами запитів.
- Не замінює розширені конверсії і офлайн-конверсії. Це різні механізми, які доповнюють один одного.
Google tag gateway: легший варіант
Google tag gateway для рекламодавців дозволяє завантажувати тег Google з вашого власного домену, а не з доменів Google. Налаштовується через CDN, наприклад Cloudflare, або власний балансувальник навантаження, а вмикається в налаштуваннях тегу Google.
Чим відрізняється від серверного GTM: окремого сервера немає, обробки і збагачення даних немає. Це спосіб підвищити стійкість стандартного тегу з мінімальними зусиллями. Для багатьох бізнесів малого і середнього розміру це розумний перший крок перед повноцінним серверним тегуванням.
Режим згоди v2
Режим згоди (Consent Mode) передає в теги Google рішення користувача щодо cookie. У версії 2 використовуються чотири параметри:
ad_storage— зберігання рекламних cookie;analytics_storage— зберігання cookie аналітики;ad_user_data— згода на передачу даних користувача в Google для реклами;ad_personalization— згода на персоналізовану рекламу і ремаркетинг.
Для трафіку з ЄЕЗ, Великої Британії і Швейцарії режим згоди v2 потрібен, щоб зберегти вимірювання, ремаркетинг і персоналізацію. Детально — у довідці Google про режим згоди.
Базовий і розширений режими
| Базовий режим | Розширений режим | |
|---|---|---|
| Коли завантажуються теги | Лише після згоди | Одразу, зі станом згоди «відмовлено» за замовчуванням |
| Що передається без згоди | Нічого | Запити без cookie для моделювання |
| Моделювання конверсій | Загальна модель | Модель на даних вашого сайту |
| Хто обирає | Бізнеси з максимально обережним підходом | Бізнеси, яким важлива повнота даних для Smart Bidding |
Що це означає для українського бізнесу
Якщо ваш сайт отримує трафік лише з України, вимога Google щодо ЄЕЗ на вас формально не поширюється. Але є кілька «але»:
- e-commerce з доставкою за кордон, послуги для українців за кордоном, туризм і освіта майже завжди мають трафік із ЄЕЗ;
- українське законодавство про персональні дані також вимагає законної підстави для обробки і поступово наближається до європейських правил;
- банер згоди і режим згоди — це ще й про довіру користувача.
Юридичну оцінку має давати юрист. Наша зона — технічна реалізація: банер згоди, сертифікована платформа керування згодою (CMP), коректна передача сигналів у теги.
Якість даних: що перевіряти щомісяця
- Частка відвідувачів, які дали згоду, і її динаміка після змін банера.
- Діагностика розширених конверсій у Google Ads.
- Статус кожної конверсії і відсутність дублів.
- Частка заявок у CRM, які мають GCLID.
- Збіг кількості покупок у Google Ads, GA4 і бек-офісі з урахуванням різниці в атрибуції.
- Самопосилання в GA4: платіжні шлюзи і власні домени не мають бути джерелами трафіку.
- Частка «(not set)» у ключових звітах GA4.
- Робота серверного контейнера, якщо він є: помилки, затримки, навантаження.
З чого почати
- Аудит поточного вимірювання. Що рахується, звідки, де дублі.
- План вимірювання. Які події важливі, які з них основні конверсії, яку цінність вони мають.
- Режим згоди v2, якщо є трафік із ЄЕЗ.
- Розширені конверсії для ключових дій.
- Офлайн-конверсії з CRM для лідогенерації.
- Google tag gateway або серверний GTM — залежно від обсягу трафіку, кількості рекламних систем і потреби в обробці даних.
Що робити далі
Перш ніж обговорювати сервери, відкрийте список конверсій у Google Ads і звірте їх за останній місяць із CRM або бек-офісом. Якщо розбіжність велика і незрозуміла, проблема найчастіше на першому рівні — у розмітці, а не у відсутності серверного контейнера.
Якщо хочете вибудувати вимірювання системно, команда AdsConcept проводить аудит аналітики, налаштовує GA4, Google Tag Manager, режим згоди v2, розширені конверсії, офлайн-конверсії, а там, де це виправдано, — Google tag gateway і серверний GTM.