Серверна передача конверсій: як увімкнути та не отримати подвійний облік

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

Коротко

• Серверна передача конверсій доповнює піксель, а не замінює його повністю.
• Подвійний облік виникає, коли та сама подія надсилається двома каналами без дедуплікації.
• У Meta (Facebook) та Google Ads дублювання прибирають через налаштування тегів і параметрів дедуплікації.
• Перевірка даних у рекламному кабінеті після налаштування — обов'язковий крок.
• Без серверної передачі ви втрачаєте до 20-30% даних про конверсії через блокувальники реклами.

Що таке серверна передача конверсій і чим вона відрізняється від пікселя

Серверна передача конверсій (Server-Side Tracking, SST) — це відправка даних про дії користувача з вашого сервера або сервера посередника безпосередньо в рекламну систему через API. Класичний піксель працює в браузері відвідувача: він зчитує подію (наприклад, клік на кнопку «Купити») і передає її в Meta або Google. Якщо користувач вимкнув JavaScript, використовує блокувальник реклами або браузер із посиленим захистом від стеження, піксель просто не спрацьовує — і ви не бачите конверсію.

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

Різниця між підходами не лише в технічній реалізації, а й у точності даних:

Більшість рекламних кампаній використовують обидва методи одночасно. Серверна передача конверсій у цій схемі — страховий поліс, який підхоплює події, втрачені пікселем.

Як увімкнути серверну передачу конверсій для Meta (Facebook)

Налаштування серверної передачі конверсій для Meta починається зі створення пікселя Meta, якщо його ще немає. Піксель — це ідентифікатор, який пов'язує ваш сайт із рекламним кабінетом. Без нього API не матиме куди надсилати дані. Далі процес виглядає так:

1. У рекламному кабінеті Meta перейдіть у розділ «Події менеджера» (Events Manager).
2. Виберіть ваш піксель або створіть новий.
3. У налаштуваннях пікселя знайдіть пункт «Налаштування конверсій» і оберіть «Використовувати Conversions API».
4. Згенеруйте токен доступу — це ключ, який дозволяє серверу надсилати дані у ваш кабінет.
5. Додайте токен доступу в код вашого сайту або в налаштування платформи, через яку ви передаєте дані (наприклад, Google Tag Manager, сервіс аналітики чи CRM).
6. Налаштуйте передачу подій: Purchase, Lead, AddToCart та інші, які ви відстежуєте.
7. Перевірте статус підключення в Events Manager — він має показувати «Активно».

Після підключення Meta почне отримувати події з двох джерел: з пікселя та з API. Щоб уникнути подвійного обліку, у налаштуваннях подій увімкніть опцію дедуплікації. Meta автоматично порівнює події за параметрами event_id та event_name і відкидає дублікати. Але для цього кожна подія має мати унікальний ідентифікатор.

Як налаштувати дедуплікацію подій у Meta

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

На практиці це означає, що вам потрібно:

• Згенерувати унікальний event_id для кожної події на сайті (наприклад, номер замовлення або випадковий набір символів).
• Передавати цей самий event_id і в пікселі, і в API-запиті.
• Використовувати однакову назву події (event_name) в обох каналах.

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

Як увімкнути серверну передачу конверсій для Google Ads

У Google Ads серверна передача конверсій реалізується через Google Tag Manager (GTM) із використанням тегу Google або через пряму інтеграцію з API. Найпоширеніший спосіб — налаштувати передачу даних через GTM, оскільки він дозволяє керувати тегами без змін у коді сайту.

1. Створіть конверсію в Google Ads: перейдіть у розділ «Цілі», натисніть «Нова конверсія» та оберіть тип «Веб-сайт».
2. Отримайте ідентифікатор конверсії та мітку конверсії — вони знадобляться для налаштування тегу в GTM.
3. Відкрийте Google Tag Manager і створіть новий тег типу «Google Ads Conversion Tracking».
4. Вкажіть параметри конверсії та налаштуйте тригер, який спрацьовуватиме на потрібну дію (наприклад, на сторінці подяки після замовлення).
5. Додайте другий тег типу «Google Ads Conversion Tracking» із параметром «Server-side» — він відповідатиме за передачу даних через сервер.
6. Опублікуйте зміни в GTM і перевірте, чи надходять дані в Google Ads.

Подвійний облік у Google Ads виникає за тим самим принципом, що й у Meta: якщо браузерний тег і серверний тег надсилають одну й ту ж конверсію. Google рекомендує використовувати для дедуплікації параметр conversion_id, який має збігатися в обох тегах. У GTM цей параметр можна передати через змінну, яка генерує унікальний ідентифікатор для кожної події.

Налаштування серверного контейнера GTM

Щоб серверна передача конверсій у Google Ads працювала коректно, потрібен серверний контейнер GTM. Це окреме середовище, яке розміщується на вашому домені або на хмарному сервері. Воно приймає дані від браузерного контейнера, обробляє їх і передає в Google Ads.

Створення серверного контейнера вимагає домену з SSL-сертифікатом. Ви можете використати піддомен вашого основного сайту, наприклад, sst.yourdomain.com. Після створення контейнера вам потрібно:

1. Налаштувати серверне середовище (наприклад, через Google Cloud, Amazon Web Services або спеціалізований хостинг).
2. Встановити серверний контейнер на ваш домен.
3. У браузерному контейнері GTM додати тег, який надсилатиме дані на серверний контейнер.
4. У серверному контейнері створити тег для Google Ads Conversion Tracking.
5. Перевірити, що дані надходять без затримок і без дублікатів.

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

Чому виникає подвійний облік і як його виявити

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

• Піксель і серверна передача працюють одночасно, але не мають спільного ідентифікатора події.
• Подія надсилається з різними назвами: наприклад, піксель передає «Purchase», а сервер — «purchase» або «buy».
• Один і той самий скрипт ініціалізує подію кілька разів через помилку в коді або через те, що сторінка перезавантажується.

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

Інший спосіб — переглянути лог подій у Events Manager (для Meta) або в звітах Google Ads. Там видно, скільки подій надійшло від пікселя, скільки від API і скільки було відхилено як дублікати.

Як перевірити, чи немає дублікатів

Найнадійніший спосіб перевірки — налаштувати тестову подію. Створіть тестове замовлення на сайті, дочекайтеся, поки дані обробляться, і порівняйте:

1. Скільки разів подія відобразилася в рекламному кабінеті.
2. Чи збігається час події з часом вашого тестового замовлення.
3. Чи відображаються параметри замовлення (сума, ID, email) коректно.

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

Чек-лист налаштування без подвійного обліку

Перш ніж запускати серверну передачу конверсій у продакшн, пройдіться по цьому списку:

• Кожна подія має унікальний event_id, який генерується один раз і використовується в усіх каналах передачі.
• Назви подій однакові в пікселі та в API (регістр літер також має збігатися).
• Піксель і серверна передача налаштовані через один інструмент або через інструменти, які синхронізують дані між собою.
• У Meta увімкнена дедуплікація в налаштуваннях подій.
• У Google Ads тег конверсії не спрацьовує двічі на одній сторінці.
• Дані в рекламному кабінеті збігаються з даними CRM або аналітики з похибкою не більше 5-10%.
• Перевірено роботу після оновлення сайту або зміни коду.

Цей чек-лист не гарантує, що дублікати не з'являться пізніше, але він покриває 90% типових помилок.

Як вибрати спосіб передачі даних: через GTM, CRM чи спеціалізований сервіс

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

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

Пряма інтеграція через CRM або платформу електронної комерції (наприклад, Shopify, WooCommerce) — найпростіший варіант. Багато CRM мають готові модулі для серверної передачі конверсій, які підключаються за кілька кліків. Мінус — менше контролю над даними, складно налаштувати нестандартні події.

Спеціалізовані сервіси (наприклад, Stape, Hyros, OWOX) беруть на себе технічну частину: хостинг, оновлення, моніторинг. Вони коштують грошей, але економлять час і знижують ризик помилок при налаштуванні. Деякі сервіси також допомагають із налаштуванням рекламних операцій для агентств, що може бути корисним, якщо ви ведете кампанії для клієнтів.

Що робити, якщо серверна передача конверсій не працює

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

• Неправильний токен доступу або ідентифікатор пікселя.
• Подія не спрацьовує через помилку в тригері або коді.
• Сервер не може зв'язатися з API рекламної системи через мережеві обмеження.

У Meta перевірте статус підключення в Events Manager. Якщо він показує «Помилка» або «Неактивно», перегляньте логи API-запитів — там буде вказано, який саме параметр не пройшов валідацію.

У Google Ads скористайтеся режимом налагодження в GTM (Preview mode). Він показує, які теги спрацьовують на сторінці та які дані передаються. Якщо тег не активується, перевірте тригер і змінні, які він використовує.

Ще одна часта причина — використання тестового режиму замість бойового. У Meta є Test Events Tool, який дозволяє перевіряти події до запуску. Але якщо ви забули вимкнути тестовий режим, реальні події не надходитимуть у кабінет.

Наступний крок: перевірте налаштування на реальних даних

Після того як серверна передача конверсій увімкнена, не запускайте одразу масштабні кампанії. Дайте системі 2-3 дні на збір даних, а потім порівняйте конверсії в рекламному кабінеті з фактичними замовленнями. Якщо розбіжність перевищує 10%, поверніться до чек-листа та перевірте налаштування дедуплікації.

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

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

Чи можна використовувати лише серверну передачу конверсій без пікселя? Технічно так, але не рекомендується. Піксель передає дані в реальному часі та дозволяє Meta і Google краще оптимізувати показ реклами. Серверна передача без пікселя працює повільніше, а в деяких випадках рекламна система може не використовувати такі дані для оптимізації.

Скільки коштує налаштування серверної передачі конверсій? Якщо ви робите все самостійно через GTM, витрати будуть лише на хостинг серверного контейнера — зазвичай від 5 до 30 доларів на місяць. Послуги спеціалізованих сервісів коштують від 30 до 200 доларів на місяць залежно від обсягу подій. Робота фахівця з налаштування оцінюється окремо.

Як довго перевіряти роботу серверної передачі після налаштування? Мінімум 2-3 дні. За цей час накопичиться достатньо даних, щоб порівняти їх із CRM. У Meta дані з API можуть з'являтися із затримкою до кількох годин, тому перевірка одразу після налаштування може показати нульові результати.

Чи впливає серверна передача конверсій на швидкість завантаження сайту? Прямого впливу немає, оскільки дані надсилаються із сервера, а не з браузера. Але якщо ви додаєте додаткові скрипти для збору даних (наприклад, для генерації event_id), це може трохи сповільнити роботу сторінки. Зазвичай це непомітно для користувача.

Що робити, якщо подвійний облік уже виник? Видаліть дублікати вручну в рекламному кабінеті, якщо це можливо, або скоригуйте дані в звітах. Потім виправте налаштування дедуплікації та перевірте, чи нові події надходять коректно. Старі дані виправити неможливо, тому важливо виявити проблему якомога раніше.

Усі матеріали блогу

Читайте також

• Що про компанію говорять відповіді ШІ: перевірка за 5 кроків

Подивитися, як це влаштовано в ADS Beast: серверна передача конверсій.