Серверний трекінг без GTM: навіщо потрібен і як впровадити
Що дає серверний трекінг, чим відрізняється від пікселя, як налаштувати конверсії для Meta і Google Ads без GTM та як перевірити дедуплікацію.
Редакція ADS BeastОпубліковано 8 хв читання
Серверний трекінг передає події з вашого сервера напряму до API рекламної площадки, минаючи браузер. Він потрібен, коли піксель губить покупки й заявки через блокувальники, обмеження скриптів або перехід на сторінку подяки. Впровадити його можна без Google Tag Manager: код пише розробник, а аналітик звіряє події зі звітами площадки.
Коротко
- Піксель працює в браузері й залежить від згоди на скрипти та блокувальників; серверна подія йде з вашого бекенду до API площадки.
- Серверний трекінг не скасовує браузерний: частину сигналів передають з обох боків, а дублі прибирають за спільним ідентифікатором.
- Для Meta піксель і Conversions API дедуплікуються за назвою події та event_id, окремого перемикача немає.
- Для Google Ads шляхи інші: імпорт конверсій із GA4 або пряма передача через Google Ads API чи Data Manager. Measurement Protocol надсилає події в GA4, а не в Google Ads.
- Запуск без тестових відправок ламає дедуплікацію, і площадка може зарахувати одну дію двічі або не зарахувати зовсім.
Що таке серверний трекінг і чим він відрізняється від пікселя
Серверний трекінг - це передача події з вашого сервера до API рекламної площадки замість запиту з браузера користувача. Браузерний піксель і серверна подія вирішують одну задачу різними шляхами, і різниця між ними визначає, скільки конверсій ви взагалі побачите.
Піксель виконується в браузері. Якщо користувач заблокував скрипти, не дав згоду або закрив вкладку до спрацювання запиту, подія не дійде. Серверний трекінг такої залежності не має: подію формує ваш бекенд у момент, коли покупка або заявка справді відбулася, і надсилає її площадці самостійно.
Звідси практичний висновок: серверний трекінг не замінює піксель повністю. Площадці потрібні і клік, і серверне підтвердження, тому частину сигналів усе одно варто передавати з браузера. Питання не «або-або», а як зібрати обидва потоки і не порахувати одну дію двічі.
Навіщо серверний трекінг бізнесу
Серверний трекінг потрібен, коли рішення про бюджет упирається в неповні дані. Якщо ви бачите менше покупок, ніж є в CRM, ви не знаєте, яка кампанія працює, і не можете чесно порівняти канали.
Друга причина - якість сигналу. Серверна подія несе те, що є у вас у базі: суму замовлення, статус оплати, підтверджений лід. Площадка отримує точніший опис результату, а ви - підставу оптимізувати кампанію на реальні гроші, а не на клік по кнопці.
Третя - стійкість до змін у браузерах. Обмеження сторонніх скриптів і блокувальники з'являються незалежно від ваших планів. Серверний потік від них не залежить, тому частка втрачених подій падає.
І окремо про очікування. Серверний трекінг не створює конверсій, яких не було, і не гарантує покращення показників. Він робить облік повнішим, а отже, і рішення про бюджет точнішим. Наскільки саме - залежить від вашої воронки, частки блокувань і того, чи збігаються події з реальними оплатами.
Коли серверний трекінг не потрібен або зашкодить
Серверний трекінг зайвий, якщо у вас мало подій і ви не бачите розбіжностей між кабінетом і CRM. Витрати на розробку й підтримку не окупляться, а складність зросте.
Він також зашкодить, якщо запустити його без єдиного правила ідентифікаторів. Дві події про одну покупку без спільного ID площадка сприйме як дві покупки. Це гірше за неповні дані: ви почнете оптимізувати кампанію на подвоєний результат.
Третя ситуація - коли ніхто не відповідає за звірку. Серверний потік живе в коді, і без регулярної перевірки він тихо ламається після зміни в оформленні замовлення. Якщо в команді немає людини, яка раз на місяць звіряє події з CRM, краще спершу налагодити облік, а вже потім ускладнювати передачу.
Як впровадити серверний трекінг без GTM: покроково
Впровадження без GTM означає, що код пише ваш розробник і розміщує його на сервері, а не в контейнері. Це більше роботи для бекенду, зате ви контролюєте, що саме і коли надсилається.
- Складіть перелік подій, які мають значення для бізнесу: покупка, оформлене замовлення, підтверджений лід, реєстрація. Для кожної події визначте, де вона виникає у вашій системі.
- Домовтеся про ідентифікатор. Для замовлення це transaction або order ID, для події Meta - event_id. Один і той самий ID має піти і з браузера, і з сервера.
- Опишіть, які поля ви передаєте: сума, валюта, статус, час події. Перелік залежить від площадки, тож звіряйте його з її документацією, а не зі статтями.
- Реалізуйте відправку на бекенді. Подія формується в момент підтвердження дії, а не в момент кліку.
- Налаштуйте повторні спроби та журнал відправок. Без журналу ви не зможете відповісти, чи дійшла подія і з яким ID.
- Проженіть тестові відправки, зіставте їх у звітах площадки та у власній аналітиці.
- Лише після збігу вмикайте потік на весь трафік.
Окремо про дзвінки. Якщо заявка часто народжується з телефонного дзвінка, серверна подія має бути прив'язана до кампанії, інакше ви передасте площадці лід без джерела. Як це влаштовано, розібрано в матеріалі про відстеження дзвінків і зв'язок із кампанією.
Серверні конверсії для Meta без GTM
Для Meta серверний трекінг означає роботу з Conversions API поряд із пікселем. Дедуплікація між ними відбувається за збігом назви події та event_id. Окремого перемикача «увімкнути дедуплікацію» немає: або ідентифікатори збігаються, або одна покупка зарахується двічі.
Практична схема така: ви генеруєте event_id на своєму боці в момент події, передаєте його і браузерним пікселем, і серверним запитом, а назву події в обох каналах пишете однаково. Якщо браузерна частина не спрацювала, серверна подія все одно дійде, і площадка побачить рівно одну дію.
Що варто знати заздалегідь. Зміна кількості конверсій після впровадження сама по собі не доводить, що дедуплікація працює. Числа могли зрости з іншої причини, а могли й вирівнятися випадково. Спершу перевіряйте самі події, їхні ідентифікатори та джерела, і лише потім робіть висновки про бюджет.
Серверні конверсії для Google Ads без GTM
Для Google Ads є два окремі шляхи передачі, і їх не можна змішувати в один. Перший - імпорт конверсій із GA4: ви налаштовуєте подію в GA4 і позначаєте її як конверсію, а Google Ads забирає її звідти. Другий - пряма передача через Google Ads API або Data Manager, коли подія йде з вашого сервера безпосередньо в кабінет.
Measurement Protocol у цій схемі надсилає серверні події в GA4, а не в Google Ads. Тому його не можна називати налаштуванням конверсийної дії Google Ads: він годує GA4, а вже звідти дані потрапляють у рекламний кабінет, якщо ви обрали шлях імпорту.
З дедуплікацією все визначає ідентифікатор. Повтор однієї конверсійної акції з тим самим transaction або order ID Google дедуплікує. Але однаковий ID не об'єднує різні конверсійні акції: якщо ви завели дві акції на одну покупку, кожна рахуватиме своє. Узгоджений ID потрібен і для браузерної, і для серверної відправки.
Окремо варто пам'ятати про налаштування самих акцій. Поділ на основні й додаткові визначає, що потрапляє в «Конверсії» і впливає на ставки, а що видно лише в «Усіх конверсіях». Дві акції на одну покупку можуть спотворити підсумок, хоча сама наявність двох джерел ще не означає подвійного зарахування. Детальніше про те, чому цифри в кабінетах розходяться, є окремий розбір: GA4 та рекламний кабінет: чому цифри розходяться.
Порівняння підходів до передачі конверсій
| Підхід | Звідки йде подія | Від чого залежить | Де ламається |
|---|---|---|---|
| Браузерний піксель | Браузер користувача | Згода на скрипти, блокувальники, швидкість переходу | Вкладка закрита до відправки, запит заблоковано |
| Серверний трекінг через API площадки | Ваш бекенд | Коректність коду, наявність ID, журнал відправок | Помилка в назві події або ідентифікаторі |
| Піксель плюс серверна подія | Обидва канали | Збіг назви події та event_id | Немає спільного ID, подія рахується двічі |
| Імпорт конверсій із GA4 у Google Ads | GA4 | Налаштування події в GA4 і зв'язок кабінетів | Подія не позначена як конверсія |
| Пряма передача в Google Ads | Ваш сервер | Google Ads API або Data Manager, transaction ID | Різні акції на одну покупку |
Як перевірити, що серверний трекінг працює
Перевірка починається з тестових подій, а не зі звітів за місяць. Надішліть кілька контрольних відправок із відомими ID, знайдіть їх у площадці та у власній аналітиці, зіставте суми й час.
Далі перевірте дедуплікацію. Для Meta це означає, що браузерна і серверна подія з одним event_id дали одну дію. Для Google Ads - що повтор із тим самим transaction ID не подвоїв конверсію в межах однієї акції.
Потім порівняйте джерела. Якщо кабінет показує більше покупок, ніж CRM, шукайте причину в подіях та ідентифікаторах, а не підганяйте звіт. Розбіжність - це діагностичний сигнал, і поки ви не знаєте її причини, змінювати бюджет на основі цих чисел ризиковано.
І останнє: перевіряйте установку лічильників окремо від серверного потоку. Помилка в базовому коді псує будь-яку серверну надбудову. Швидка перевірка описана в матеріалі встановлення лічильників: перевірка за п'ять хвилин.
Типові помилки під час впровадження
Найчастіша помилка - різні назви однієї події в браузері та на сервері. Площадка не зіставить їх і зарахує обидві.
Друга - ID генерується на сервері заново, хоча браузер уже надіслав свій. Спільного ідентифікатора немає, дедуплікація не працює.
Третя - подія надсилається в момент кліку, а не підтвердження. Тоді ви передаєте намір, а не результат, і кампанія оптимізується на те, чого не сталося.
Четверта - відсутність журналу відправок. Коли числа розійдуться, ви не зможете відтворити, що саме пішло і з яким ID.
П'ята - запуск на весь трафік без тестових подій. Помилку в цьому випадку виявить не тест, а звіт за минулий період, коли бюджет уже витрачено.
Наступний крок
Перш ніж писати код, визначте дві речі: перелік подій, які мають значення для бізнесу, і правило генерації ідентифікаторів для кожної з них. Далі надішліть кілька тестових подій і звірте їх у площадці та у своїй аналітиці. Якщо хочете бачити серверні конверсії зі стадій CRM поруч із кампаніями в одному місці, подивіться, як працює трекінг і серверні конверсії в ADS Beast.