Facebook Pixel дозволяє відстежувати активність користувачів на вашому вебсайті, збирати аудиторії remarketing та створювати lookalike аудиторії. При правильній реалізації Facebook Pixel передає релевантну інформацію алгоритмам машинного навчання Facebook (FB ML), які використовують ці дані для показу вашої реклами людям з найвищою ймовірністю конверсії.
Протягом кількох років ми відстежували події на наших вебсайтах за допомогою коду JavaScript, SDK Facebook у додатках або завантаженням офлайн-подій. Але як відстежувати користувачів із блокувачами реклами, моніторити події за межами вашого вебсайту або продовжити термін дії cookies? Цього можна досягти, впровадивши Facebook Conversions API або Facebook Conversions API Gateway.
У цій статті ми розглянемо API API конверсії Facebook і покажемо, як налаштувати API конверсії Facebook через Google Tag Manager Server Container. Ви можете отримати більше інформації про Facebook Conversions API Gateway в нашому блозі. До речі, ознайомтеся з попередньо налаштованими шаблонами Stape для Meta CAPI. Тепер налаштувати ваш сетап простіше, ніж будь-коли: все вже зроблено і все готово для вас!
Давайте подивимося, що таке Facebook Conversions API і як ми можемо використовувати його для покращення відстеження подій, атрибуції та збору даних у Facebook. Facebook Conversions API дозволяє надсилати будь-які події з вашого сервера на сервер Facebook.
Facebook CAPI має ту саму мету, що й Facebook Pixel, але базується на іншій технології. Політики та обмеження навколо FB CAPI роблять його більш придатним для потреб сучасного середовища відстеження. На відміну від Facebook Pixel, Conversions API не покладається на браузер користувача для надсилання інформації відстеження; все обробляється через хмарний сервер, підвищуючи безпеку та точність даних.
Якщо ми уважніше подивимося на посилання рекламних оголошень Facebook, то побачимо, що в кінці майже будь-якої URL-адреси FB додає свій додатковий параметр fbclid. Піксельний код на цільовій сторінці зберігає значення цього параметра у файлі cookie, а потім надсилає його разом з будь-якою подією Facebook. Поряд з ідентифікатором кліка (fbclid) Facebook використовує ідентифікатор браузера (fbp). Файли cookie fbp і fbc допомагають FB визначити, який користувач потрапив на ваш сайт і хто з них здійснив конверсію.
FB може зіставляти користувачів за допомогою інших параметрів, таких як електронна адреса, номер телефону, ім’я/прізвище тощо. Чим більше даних користувачів ви надсилаєте до Facebook Conversions API, тим вище коефіцієнт відповідності ви отримуєте.
Відстеження на стороні сервера Facebook, або Facebook Conversions API, доступне вже кілька років. Однак починаючи з 2021 року, Facebook почав активніше просувати Conversions API. Якщо у вас є виділений представник Facebook, який керує вашим рекламним акаунтом, він, найімовірніше, порекомендує налаштувати Facebook Conversions API.
Ось найважливіші причини розглянути впровадження Facebook Conversions API. Деталі дивіться нижче.
Інтегрувавши Conversions API разом із Meta Pixel, Ray-Ban змогла значно покращити свої рекламні результати. Поєднання призвело до збільшення охоплення на 36% у Facebook та Instagram порівняно з використанням лише Meta Pixel.
Крім того, бренд зафіксував зниження вартості за 1 000 переглядів на 19% та зниження вартості за конверсію на 7%, що демонструє ефективність Conversions API в оптимізації кампаній та досягненні кращих результатів.
Meta Conversions API Gateway — це найшвидше рішення для впровадження відстеження на стороні сервера Meta, яке не потребує спеціальних знань.
Stape пропонує хостинг для Conversions API Gateway за ціною $10 за піксель на місяць або $100 за 100 пікселів на місяць. Крім того, усі користувачі отримують 7-денний безкоштовний пробний період.
Один із найдоступніших способів — використання серверного Google Tag Manager (sGTM). З допомогою sGTM компанії можуть надсилати дані клієнтів безпосередньо на сервери Facebook.
Плюси налаштування Facebook CAPI через sGTM:
Мінуси налаштування Facebook CAPI через sGTM:
У цій статті ми зосередимося на налаштуванні відстеження на стороні сервера Facebook через серверний GTM.
Ми використовуватимемо серверний GTM для налаштування Facebook Conversions API. Для налаштування Facebook Conversions API вам знадобиться наступне:
У нас також є публікація в блозі про серверний контейнер Tag Manager та його переваги в нашому блозі.
Це відео показує, як налаштувати Facebook Conversions API за допомогою Google Analytics 4.
2. Надішліть дані в серверний GTM-контейнер. Це можна зробити, налаштувавши серверний Google Analytics 4 або Data Tag/Data Client.
3. Перейдіть до серверного контейнера Google Tag Manager. Додайте тег Facebook Conversions API з Галереї шаблонів.
4. Створіть тег Facebook Conversions API всередині sGTM. Виберіть Tag → Натисніть New → Оберіть тег Facebook, який ви додали у попередньому кроці.
Додайте ваш Facebook Pixel ID та Facebook API Access Token (ми рекомендуємо додати його як змінну, оскільки ці значення знадобляться для кожної події Facebook, яку ви хочете відстежувати). Якщо ви не знаєте свій Facebook API Access Token, зверніться до документації Meta.
5. У вас є 2 варіанти налаштування нашого тегу Facebook Conversions API:
6. Якщо ви обрали варіант override, вам потрібно буде використовувати події в GA4 або Data Tag/Data Client для запуску серверних подій Facebook. Подія pageview Facebook повинна спрацьовувати за кастомною подією page_view, заявленою певним клієнтом (наприклад, якщо ви обрали GA4 як джерело даних для серверного GTM, то потрібно використовувати подію page_view, коли ім'я клієнта дорівнює GA4).
Щоб налаштувати інші події, перейдіть у режим попереднього перегляду sGTM, виконайте дію на вашому вебсайті, яку хочете відстежувати у Facebook, та перевірте назву події, яку GA4 або Data Tag надсилає у ваш серверний контейнер.
На скриншоті нижче ми хочемо налаштувати подію Facebook ViewContent, коли хтось відкриває сторінку продукту на нашому вебсайті. Переконайтеся, що ви також надсилаєте разом із подією GA4 / Data Tag з веб-контейнера будь-які додаткові дані, які хочете використати для серверної події. У наведеному нижче прикладі також використовуються стандартні параметри Facebook eCommerce та дані користувача.
Для цього ми створили новий тег всередині серверного контейнера, встановили його на override, обрали стандартну подію ViewContent, додали API Access Token та Facebook Pixel ID. Ми також додали User Data та створили новий тригер із назвою події, що дорівнює view_item, та Client Name, що дорівнює GA4.
7. Ви можете передавати кастомні параметри через поля Server Event Data Override, User Data та Custom Data. Ви можете надсилати дані користувача для збільшення показника збігу у Facebook через поле User Data. Зверніть увагу, що інформація про користувача, яку ви хочете надіслати у Facebook Conversions API, повинна бути хешованою. Наш тег Facebook автоматично хешує необхідні дані.
Ви також можете увімкнути Event Enhancement для використання HTTP-only secure cookie (gtmeec) з метою збагачення даних події. Коли ця функція увімкнена, тег зберігає дані користувача в cookies та збагачує події даними користувача, коли вони недоступні. Таким чином, ви можете підвищити якість збігу подій, що може покращити атрибуцію конверсій до кампаній.
8. Після завершення налаштування всіх подій Facebook відкрийте режим відлагодження Google Tag Manager та перевірте, чи правильно працюють події Facebook. Ви також можете перейти до тегу Facebook всередині серверного контейнера та додати Facebook test ID. Знайти test ID можна в Meta Events Manager на вкладці Test Events.
9. Після того, як ви налаштували та переконалися, що Facebook Conversions API працює правильно, вам потрібно видалити відстеження браузера FB або налаштувати дедуплікацію подій. Інакше ваші події будуть дублюватися.
Перший крок у тестуванні відстеження на стороні сервера Facebook такий самий, як і для Google Analytics. Вам потрібно переконатися, що події спрацьовують за правильними тригерами. Відкрийте інструмент відлагодження GTM, перейдіть по сторінках вашого вебсайту та виконайте події, які хочете протестувати. Після цього перейдіть на вкладку відлагоджувача Tag Manager та перевірте результати.
Спочатку переконайтеся, що базовий піксель FB спрацьовує при перегляді сторінки. Якщо ви бачите статус тегу Fail, перевірте вихідні запити, які повинні вказати, чому тег не спрацював.
Якщо ви використовуєте наш тег відстеження на стороні сервера FB, у вас є два варіанти надсилання подій FB:
Відкрийте Events Manager у вашому Facebook Business Manager та натисніть Test Events. Ви побачите код тестової події, який потрібно додати до тегу Facebook всередині Google Tag Manager. Цей код дозволить вам тестувати серверні події Facebook в реальному часі.
Після додавання test ID відкрийте ваш вебсайт та виконайте дії, які запускають ваші події FB. Потім поверніться до інструменту тестування Facebook та перевірте відображені події. У стовпці Received From ви повинні побачити Server. Ви можете натиснути на подію, щоб переглянути записані параметри.
Зверніть увагу, що плагін Chrome Facebook Pixel Helper, який ви використовували для перевірки браузерних подій Facebook, не працюватиме для Conversions API. Тому вам потрібно перевіряти все в інструменті тестування.
| Примітка: cookies будуть продовжені лише при використанні кастомного піддомену в URL тегування. Наприклад, якщо URL вашого вебсайту example.com, то кастомний домен для URL тегування повинен виглядати як gtm.example.com. |
Третій крок аналогічний тому, що ми робили раніше, але з деякими відмінностями. Щоб перевірити дату закінчення cookies Facebook, спочатку потрібно їх згенерувати. Для цього відкрийте ваш вебсайт та додайте fbclid.
Після цього відкрийте інструменти розробника, перейдіть до Storage та натисніть Cookies. Перевірте, що _fbc та _fbp були продовжені.
За допомогою Stape ви можете підвищити точність відстеження та покращити результати кампанії за допомогою тегів на стороні сервера.
Залежно від платформи, яку ви використовуєте, ви можете швидко та ефективно налаштувати відстеження за допомогою наших кастомних шаблонів. Дотримуйтесь покрокових інструкцій, щоб налаштувати Meta CAPI за допомогою серверного GTM для:
Незабаром з'являться шаблони та посібники для Wix, Shopware, Prestashop та інших. Дайте нам знати, якщо вам потрібен шаблон для іншої CMS.
Facebook рекомендує використовувати і Pixel, і Conversions API для відстеження подій, але без дедуплікації подій дубльовані дані з браузера та сервера можуть спотворити результати. Дедуплікація гарантує збереження лише однієї події за рахунок використання унікальних ID подій, спільних для обох джерел. Правильне налаштування вимагає генерації та синхронізації цих ID між браузерними та серверними подіями, що можна перевірити в Events Manager Facebook.
Крім того, надсилання даних користувача через Conversions API покращує якість збігу та показники збігу подій, підвищуючи ефективність реклами. Дані користувача в ідеалі повинні надходити з data layer та відповідати політикам конфіденційності. Інструменти, такі як плагіни Stape, спрощують інтеграцію даних користувача для кращої оптимізації кампаній Facebook.
Для зіставлення користувачів, які відвідують ваш вебсайт, з їхньою базою даних Facebook використовує User Data для Conversions API.
Facebook вимагає хешувати деякі параметри перед надсиланням, але вам не потрібно про це турбуватися; тег Facebook автоматично хешує всі дані перед надсиланням.
Чим більше параметрів користувача ви надсилаєте у Facebook, тим вищі шанси на збіг з користувачем, що призводить до вищого показника збігу подій.
Надсилання параметрів користувача з вашого вебсайту у Facebook — це делікатна тема, оскільки ви ділитиметеся даними користувача зі стороннім сервісом. Тому перед надсиланням цих даних у Facebook переконайтеся, що вони відповідають вашій політиці конфіденційності.
В ідеалі дані користувача повинні бути додані до data layer. Якщо це неможливо, спробуйте зібрати їх зі сторінки за допомогою кастомного коду JavaScript та надіслати разом із конверсіями або подіями, які вас цікавлять.
Наприклад, усі плагіни Stape для CMS (для Facebook CAPI для Shopify, відстеження на стороні сервера для WordPress, Magento 2 Google Tag Manager, додаток GTM для BigCommerce) додають data layer, який також містить дані користувача.
Ви можете легко отримати дані з data layer та додати їх до подій Facebook у веб-контейнері.
Потім перенесіть необхідні дані до серверного контейнера (у payload GA4 або Data tag, залежно від того, що ви використовуєте).
Нарешті, додайте ці дані до вашої серверної події Facebook.
Таким чином, ви досягнете кращої якості збігу ваших подій Facebook, потенційно покращуючи ефективність ваших рекламних кампаній, оскільки Facebook краще зрозуміє вашу аудиторію та оптимізує ваші рекламні кампанії.
Ви можете бачити всі домени, що надсилають дані у ваш Facebook Pixel. Якщо Facebook виявить трафік з нового піддомену або домену, він надішле вам попередження. Ви можете додати домени до білого або чорного списку, використовуючи цю функцію для блокування трафіку з ваших тестових вебсайтів або технічних URL.
Найімовірніше, ви також побачите трафік з gtm-msr.appspot.com. Це може статися при запуску контейнера відлагодження/публікації або коли користувачі відвідують ваш вебсайт з вимкненим JavaScript (деякі боти).
Щоб створити списки дозволених або заблокованих доменів, відкрийте Events Tool у Business Manager → натисніть Settings → прокрутіть вниз до Traffic Permissions.
Це друга за частотою помилка Facebook CAPI за нашим досвідом. Ця помилка вказує на те, що ви не надсилаєте деякі ключі дедуплікації для ваших серверних подій. Facebook використовує ці ключі дедуплікації: event name, event ID, _fbp та external ID.
За нашим досвідом, відсутність параметра Event ID спричиняє цю помилку у 80% випадків. Перевірте, чи надсилаєте ви event ID як для Facebook Pixel, так і для Facebook Conversions API. Цей event ID повинен бути однаковим для браузерних і серверних подій, дозволяючи Facebook розпізнавати однаковий event name та event ID для дедуплікації.
Наприклад, для подій PageView надсилайте однаковий event ID та event name як з Facebook Pixel, так і з Facebook CAPI.
Щоб протестувати event ID, відкрийте інструмент тестування подій Facebook. Якщо все вірно, ваш результат повинен виглядати аналогічно скриншоту нижче. Так Facebook показує, що записав події PageView як з браузера, так і з сервера, які мали однаковий event ID, що вказує на обробку браузерних подій та дедуплікацію серверних подій.
Але можуть бути ситуації, коли ви бачите браузерні та серверні події, що спрацьовують хаотично. У цьому випадку перевірте event ID Facebook; найімовірніше, вони не ідентичні. Ви можете використати нашу кастомну змінну для веб-контейнера для налаштування event ID Facebook. Докладніше про дедуплікацію подій Facebook читайте у розділі вище.
Іноді ця помилка може виникнути, якщо ви не видалили Facebook test ID та опублікували теги Facebook CAPI у продакшн-середовищі. Ми рекомендуємо налаштувати Test ID як змінну таблиці пошуку, яка працює лише при увімкненому режимі відлагодження, для вирішення цієї проблеми.
Тут Facebook попереджає вас, що значення, які надсилаються з сервера, не є унікальними або неправильно відформатовані. Наприклад, ви можете надсилати IP користувача, що містить символи окрім цифр, або обрали неправильну змінну, наприклад, надіславши номер телефону в полі email.
Щоб визначити проблему, відкрийте режим попереднього перегляду серверного та веб-контейнера Google Tag Manager (якщо ви використовували GTM для налаштування Facebook Conversions API). Ви повинні побачити, які параметри користувача були надіслані у Facebook та чи правильно вони відформатовані. Протестуйте подію, натисніть на тег у режимі відлагодження та перевірте значення.
Ця помилка також може вказувати на те, що ви забули включити параметр або він неправильно відформатований.
Наприклад, був клієнт, який хотів надсилати країну та місто користувача на основі його IP-адреси. Facebook очікував отримати реальні дані адреси користувача, введені на вебсайті, а не автоматично витягнуті з IP. Це налаштування призвело до помилки про недійсні параметри ключа.
Ця помилка зазвичай стосується браузерних подій та вказує на те, що Facebook виявив дані користувача в URL. Деякі CMS та інструменти, такі як Calendly або PayPal, надсилають дані користувача в URL після реєстрації або покупки.
Цю помилку важко усунути, і вона потребує уваги ваших розробників. Вони повинні покращити параметри запиту URL та видалити всю інформацію про користувача з URL. Також ви можете слідувати інструкціям з видалення персональних даних (PII) та спробувати виправити проблему в GTM. Інший варіант — перейти виключно на відстеження Facebook на стороні сервера. Це дозволить змінити URL перед надсиланням у Facebook.
Для кожної серверної події, надісланої у Facebook, генерується оцінка якості збігу подій. Ця оцінка залежить від обсягу даних користувача, які ви надсилаєте у Facebook.
Якщо ви використовуєте кастомний піддомен для вашого сервера тегування, у Facebook CAPI надсилаються лише User IP, browser ID, _fbp та _fbс. Надсилання лише цих параметрів користувача призводить до оцінки якості збігу приблизно 4 з 10.
Для досягнення високої оцінки якості вкрай важливо надсилати якомога більше параметрів. Facebook використовує ці дані для зіставлення користувачів на вашому вебсайті з користувачами у своїй базі даних. Але перш ніж продовжити, переконайтеся, що надсилання даних користувача у Facebook відповідає політиці конфіденційності вашого вебсайту та відповідним нормативним вимогам. Технічно надсилання більшої кількості параметрів є корисним, оскільки це призводить до точніших даних про аудиторію та конверсії, надає алгоритмам Facebook конкретну інформацію про ваших користувачів та покращує ефективність кампаній.
Як можна підвищити оцінку якості збігу подій? Відповідь проста: надсилайте більше даних користувача. Однак реалізація може бути складною. Спочатку перевірте, чи реалізований data layer на вашому вебсайті та чи містить він усі дані користувача. Наприклад, якщо користувачі можуть увійти на ваш вебсайт, переконайтеся, що дані користувача надсилаються до data layer при вході.
Якщо data layer не встановлений, доручіть вашим розробникам його налаштування.
Далі переконайтеся, що ви передаєте всі параметри користувача з вебу до серверного контейнера.
Крім того, нова функція Data Tag може допомогти підвищити якість збігу. Ми додали можливість збереження даних користувача. Наприклад, якщо користувач надсилає контактну форму на вебсайті, ви можете використати Data Tag для збереження даних користувача в локальному сховищі та їх використання на інших сторінках.
За замовчуванням тег намагається зіставити стандартні події GA зі стандартними подіями Facebook. Якщо зіставлення неможливе, буде використано необроблену назву події з клієнта GA. Наприклад, якщо ви надсилаєте назву події на кшталт: gtag(‘event’, ‘UserLikedProduct’), ви побачите подію UserLikedProduct у менеджері подій Facebook.
Нижче наведено схему зіставлення подій GA з подіями Facebook, яку ми використовуємо в цьому тезі за замовчуванням:
| page_view | PageView |
| add_payment_info | AddPaymentInfo |
| add_to_cart | AddToCart |
| add_to_wishlist | AddToWishlist |
| sign_up | CompleteRegistration |
| begin_checkout | InitiateCheckout |
| generate_lead | Lead |
| purchase | Purchase |
| search | Search |
| view_item | ViewContent |
| contact | Contact |
| customize_product | CustomizeProduct |
| donate | Donate |
| find_location | FindLocation |
| schedule | Schedule |
| start_trial | StartTrial |
| submit_application | SubmitApplication |
| subscribe | Subscribe |
Щоб спростити міграцію вашого веб-тегу Facebook GTM до серверного контейнера, ми зіставили всі дані, отримані клієнтом GA, з подією Facebook без необхідності додаткового налаштування з вашого боку. Це також підтримує зіставлення подій GA Enhanced eCommerce, і, звісно, тег може перевизначити будь-які параметри подій, що надсилаються у Facebook.
Наприклад, якщо тег визначить, що тип події — Purchase, ми визначимо список продуктів, валюту та вартість.
У наступних розділах ми опишемо, як саме дані зіставляються в кожній групі параметрів.
1. Користувач у Спільноті помітив, що після переходу на відстеження на стороні сервера Facebook його аудиторія ретаргетингу була значно меншою за трафік GA4 (приблизно 15% match rate). Проблема полягала не в несправному відстеженні, а в нереалістичних очікуваннях: Facebook не може надійно зіставляти користувачів, використовуючи лише IP та User Agent. Рішенням стало дотримання рекомендованого Meta гібридного налаштування (браузер + сервер з дедуплікацією) та надсилання всіх доступних даних користувача (таких як email або ім'я, коли це можливо). Цей підхід покращує якість збігу та розмір аудиторії, тоді як чисто серверне відстеження обмежує потенціал ретаргетингу.
2. Багато користувачів у цій темі стикаються з проблемами відстеження на стороні сервера Facebook та зіставлення FBP/FBC, особливо при використанні сторонніх чекаутів. Використання шаблону Facebook CAPI від Stape на власному піддомені, запуск ключових подій на основному домені, впровадження гібридних браузерних+серверних подій для дедуплікації та, за потреби, використання webhooks вирішує більшість проблем. Завжди перевіряйте дані через мережеві інструменти браузера, а не покладайтеся виключно на Tag Assistant.
Ось і все. Ми сподіваємося, що ви успішно перенесли відстеження Facebook на серверну сторону. Facebook Conversions API — це потужний інструмент для розуміння ваших клієнтів, відстеження їхнього шляху до конверсії та надання більшої кількості даних для оптимізації алгоритмів машинного навчання Facebook.
Ми можемо допомогти. Дізнайтеся, скільки це буде коштувати! Отримайте розцінку за 24 години. Так, ми це маємо на увазі.
Коментарі