UK
Ігор Ніколенко- Що робить GTM і чому одного контейнера вже мало
- Серверний контейнер: як це працює
- Браузер і сервер поруч: що втрачається і що повертається
- Одна заявка — одна подія: дедуплікація
- Розширені конверсії і дані з CRM
- Як перевірити, що подія справді дійшла
- З чого почати і коли це потрібно вам
- Коротко
- Питання, які ставлять найчастіше
Реклама показує вісім заявок за тиждень. CRM показує двадцять. Різниця — не помилка менеджера і не «люди приходять самі». Різниця — це конверсії, які браузерний піксель не зміг передати: блокувальник реклами, відмова від cookie, обмеження браузера, повільне завантаження. Алгоритм рекламного кабінету навчається на восьми заявках замість двадцяти, шукає «схожих» на неповну вибірку і витрачає ваш бюджет на людей, які схожі на випадкову третину клієнтів.
Це не теоретична проблема, а щоденна для кожного, хто платить за рекламу. І вона посилюється: браузери скорочують життя cookie, згода на відстеження стала обовʼязковою для аудиторії з Європи, блокувальники стоять у помітної частки користувачів. Пікселі в браузері поступово перетворюються з джерела правди на джерело приблизних здогадок.
У цій статті — як влаштована передача конверсій через Google Tag Manager, чим серверний контейнер відрізняється від звичного, як не порахувати одну заявку двічі, що таке розширені конверсії і як перевірити, що подія справді дійшла до кабінету. Простими словами, з назвами інструментів такими, як вони є в документації.
Що робить GTM і чому одного контейнера вже мало
Google Tag Manager — це посередник між сайтом і сервісами аналітики й реклами. Замість вставляти в код сайту десяток скриптів, ви вставляєте один контейнер GTM, а всередині нього налаштовуєте теги (що надіслати: подію в Google Analytics 4, конверсію в Google Ads, подію в Meta), тригери (коли: відправка форми, натискання кнопки, перегляд сторінки) і змінні (з якими даними: сума, ідентифікатор, джерело). Дані з сайту потрапляють у GTM через шар даних — dataLayer — це просто список подій, які сайт «оголошує», а GTM слухає.
Класичний контейнер працює в браузері відвідувача. І в цьому його межа: усе, що заважає скриптам у браузері, заважає і йому. Тому у GTM зʼявився другий тип контейнера — серверний. Він живе не в браузері, а на вашому сервері або в хмарі, під вашим доменом, і саме він далі спілкується з Google, Meta, TikTok та іншими.
Серверний контейнер: як це працює
Схема проста, якщо розкласти на кроки.
- Браузерний контейнер надсилає подію не напряму в Google Analytics, а на адресу вашого серверного контейнера — зазвичай це піддомен вашого сайту, на кшталт «gtm.вашдомен».
- Серверний контейнер приймає подію через клієнт (у термінах GTM — модуль, що вміє розуміти певний формат; для подій GA4 це «GA4 client»).
- Далі в серверному контейнері працюють свої теги: GA4, конверсії Google Ads, Meta Conversions API, TikTok Events API та інші. Кожен тег бере дані з події й надсилає їх у відповідну систему з сервера.
Розгортається серверний контейнер на Google Cloud — GTM пропонує автоматичне налаштування — або в будь-якого провайдера, що підтримує контейнери. Технічна частина займає годину у спеціаліста; далі це така сама робота в інтерфейсі GTM, як і зі звичним контейнером.
Що це змінює. По-перше, cookie ставляться з вашого домену, тобто як «власні», і браузери обмежують їх менше, ніж сторонні. По-друге, відвідувач бачить лише один запит на ваш домен, а не десяток на домени рекламних мереж — блокувальники до нього байдужі, а сайт швидший, бо важкі скрипти пікселів у браузері вже не потрібні. По-третє, ви контролюєте, які дані куди йдуть: на сервері можна прибрати зайве, додати потрібне і не передавати нічого, на що людина не дала згоди.
Браузер і сервер поруч: що втрачається і що повертається
| Ситуація | Браузерний піксель | Серверна передача |
|---|---|---|
| Блокувальник реклами | Скрипт не завантажився, подія втрачена | Запит іде на ваш домен, подія доходить |
| Обмеження cookie у браузері | Сторонні cookie короткоживучі, звʼязок із кліком рветься | Власні cookie з вашого домену живуть довше |
| Повільний сайт, ранній клік | Піксель не встиг завантажитися | Подія формується сервером після заявки |
| Швидкість сайту | Кожен піксель — окремий скрипт у браузері | Один легкий запит, решта на сервері |
| Контроль даних | Кожен піксель бере, що бачить | Ви вирішуєте, що і куди передати |
| Дані з форми | Обмежені тим, що є на сторінці | Можна збагатити з CRM перед відправкою |
| Згода на cookie | Дотримується, якщо теги правильно налаштовані | Дотримується так само; сервер не обходить згоду |
Останній рядок — принциповий. Серверна передача вирішує технічні втрати, а не юридичні. Подія без згоди не має йти ні з браузера, ні з сервера; режим згоди Consent Mode v2 працює в обох контейнерах.
Одна заявка — одна подія: дедуплікація
Найчастіше серверна передача запускається поруч із браузерною, а не замість неї: браузерний піксель лишається для тих, у кого він працює, сервер добирає решту. І тут виникає ризик порахувати одну заявку двічі — з браузера і з сервера.
Рішення — спільний ідентифікатор події. Для Meta це параметр event_id: браузерний піксель і Conversions API надсилають одну й ту саму подію з однаковим event_id, і Meta залишає одну. У Google Analytics 4 і Google Ads роль такого ключа виконують ідентифікатори транзакції або клієнта, а сам серверний контейнер побудований так, що подія з браузера проходить через нього один раз. Правило для будь-якої системи: ідентифікатор події народжується на сайті в момент заявки, і всі канали передають саме його.
Перевірка проста: одна тестова заявка має дати рівно одну подію в кожному кабінеті. Дві — значить, дедуплікація не працює; нуль — не працює передача.
Розширені конверсії і дані з CRM
Серверна передача відкриває те, чого браузер не вміє: збагачення події даними, які людина вам уже дала. У Google Ads це називається розширеними конверсіями (Enhanced Conversions): у подію додаються пошта або телефон у захешованому вигляді, і система точніше зіставляє заявку з кліком по рекламі. Meta працює так само через параметри користувача в Conversions API. Хешування відбувається до відправки; у рекламні системи йде не сама пошта, а її відбиток.
Наступний крок — конверсії з CRM. Заявка — ще не продаж. Коли угода закривається, з CRM у рекламні кабінети йде подія «продаж» з тим самим ідентифікатором кліку, збереженим від першого візиту: gclid для Google, fbclid для Meta та їхні аналоги. Тепер алгоритм оптимізується не на тих, хто залишив заявку, а на тих, хто заплатив. Це найбільший стрибок у якості реклами, який я бачив у проєктах, і він неможливий без серверної передачі.
Для цього ідентифікатори кліку треба зберігати від першого візиту до заявки і записувати разом з нею в CRM. Це один із перших пунктів, які я перевіряю в будь-якому проєкті: якщо gclid не доїжджає до CRM, весь ланцюг офлайн-конверсій не працює.
Як перевірити, що подія справді дійшла
Індикатор має показувати факт. Ось де його дивитися:
- Попередній перегляд GTM і Tag Assistant — і для браузерного, і для серверного контейнера: видно кожну подію, які теги спрацювали і з якими даними.
- DebugView у Google Analytics 4 — події з тестового пристрою в реальному часі; ключові події (так GA4 тепер називає конверсії) мають позначатися саме як ключові.
- Test Events у Meta Events Manager — показує події з браузера і з сервера окремо, з event_id, і одразу видно, чи дедуплікуються вони.
- Діагностика конверсій у Google Ads — статус дії-конверсії, чи отримує вона дані, чи працюють розширені конверсії.
Порядок перевірки: одна тестова заявка → одна подія в кожному з чотирьох місць → та сама заявка в CRM з ідентифікаторами кліку. Поки цей ланцюг не пройдено на живих даних, вважати трекінг налаштованим не можна.
З чого почати і коли це потрібно вам
Якщо ви платите за рекламу і бачите розрив між кабінетом і CRM — це вже потрібно. Порядок: спершу шар даних і події заявок у браузерному GTM, потім серверний контейнер під вашим доменом, потім дедуплікація, потім розширені конверсії, потім конверсії з CRM. Кожен крок перевіряється окремо, перш ніж робити наступний.
Де саме у вас губляться заявки — між рекламою і сайтом, між сайтом і кабінетом чи між кабінетом і CRM — я показую в аудиті сайту й воронки: це не «перевірка налаштувань», а пошук точок, де дані й люди зникають. А якщо сайт будується або переноситься, серверна передача конверсій у GA4, Google Ads, Meta, TikTok, LinkedIn і Microsoft може бути вбудована від початку, з дедуплікацією і перевіркою тестової події в адмінці, — так це зроблено в платформі NEO, і тоді серверний контейнер GTM стає необовʼязковим.
Коротко
- Браузерні пікселі втрачають конверсії через блокувальники, обмеження cookie, відмову від відстеження і повільне завантаження; алгоритми реклами навчаються на неповних даних.
- GTM — посередник між сайтом і сервісами; серверний контейнер переносить спілкування з рекламними системами з браузера на ваш домен.
- Сервер повертає втрачені події, робить cookie власними, прискорює сайт і дає контроль над даними — але не обходить згоду.
- Дедуплікація: один ідентифікатор події з сайту в усі канали; одна тестова заявка — одна подія в кожному кабінеті.
- Розширені конверсії передають захешовані контакти; конверсії з CRM навчають рекламу на продажах, а не на заявках.
- Ідентифікатори кліку мають доїжджати до CRM разом із заявкою — інакше офлайн-конверсії не працюють.
- Перевірка — у попередньому перегляді GTM, DebugView GA4, Test Events Meta і діагностиці Google Ads, на живих даних.
Питання, які ставлять найчастіше
Чи потрібен серверний GTM малому бізнесу?
Якщо ви платите за рекламу регулярно і бачите розрив між кабінетом і реальними заявками — так. Якщо реклами немає або вона епізодична, спершу наведіть лад у браузерному контейнері й шарі даних.
Скільки коштує серверний контейнер?
Сам GTM безкоштовний; платите за сервер або хмару, де він працює, і за години налаштування. Конкретна сума залежить від провайдера й трафіку — дивіться тарифи хмари, яку обираєте.
Чи законно передавати дані на сервер без згоди?
Ні, і серверна передача цього не змінює. Події йдуть лише за наявності відповідної згоди; режим згоди має бути налаштований для обох контейнерів.
Чи можна обійтися без GTM взагалі?
Так, якщо платформа сайту сама надсилає події на сервери рекламних систем із дедуплікацією і перевіркою. Тоді GTM лишається зручним для дрібних тегів, але не є обовʼязковим для конверсій.
