Дієві поради щодо покращення атрибуції конверсій у Facebook

Належна атрибуція конверсій у Facebook має важливе значення для компаній, які хочуть отримати всі переваги від платної реклами. Хоча деякі компанії все ще покладаються на відстеження браузера, перехід на відстеження на стороні сервера може забезпечити більш точні дані. Тегування на стороні сервера забезпечує прямий зв'язок з вашим сервером і сервером Facebook, надаючи якісні сторонні дані та використовуючи сторонні файли cookie.

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

Однією з головних переваг тегування s2s є те, що воно забезпечує підвищену точність порівняно з методами відстеження на стороні клієнта. Це пов'язано з тим, що тегування між серверами не може бути заблоковано, оскільки комунікація відбувається на рівні сервера. Такі інструменти, як AdBlocker або інші механізми запобігання відстеженню, не можуть отримати доступ до даних, що надсилаються через сервер.

Коли ви вмикаєте інтеграцію FB s2s, ваш сервер зв'язується безпосередньо з серверами Facebook. Він надсилає достовірні дані про події та користувачів, які відвідали ваш сайт, що допомагає FB точно пов'язувати ваших користувачів з їхніми профілями у FB, що означає якісну звітність та вищі шанси на успішний таргетинг.

Найпопулярнішим способом server-to-server відстеження Facebook є налаштування Facebook conversion API за допомогою серверного контейнера Google Tag Manager. Але існує кілька підходів до налаштування FB CAPI в sGTM. У цьому гайді я хочу описати різні способи налаштування FB CAPI, як кожен з них впливає на атрибуцію FB і як поліпшити атрибуцію. 

Ці поради ґрунтуються на досвіді компанії stape та на відгуках клієнтів stape. 

Facebook рекомендує налаштовувати CAPI за допомогою методу браузер+сервер. Коли відстеження браузера заблоковано, серверне відстеження все одно буде надсилати дані користувача до Facebook. Коли спрацьовує і браузерне, і серверне відстеження, FB використовує ім'я події та ідентифікатор події для дедуплікації подій. Він відкидає одну подію і зберігає іншу, щоб запобігти надмірному відстеженню.

У нас в блозі є стаття, в якій описано, як налаштувати Facebook CAPI за допомогою сервера GTM. 

FB надає вищий пріоритет подіям браузера. Коли вони бачать і події браузера, і події сервера, їх алгоритм дедуплікації, ймовірно, відкидає події сервера і записує події браузера. Таким чином, якщо ви відправляєте більше даних з подією сервера, FB не зможе прочитати ці дані. Вони також не об'єднують параметри веб-подій та подій сервера. 

Важливий аспект налаштування FB CAPI за допомогою гібридних методів через Google Tag Manager з'являється, коли ви використовуєте GA4 (або будь-який інший тег GTM) для доставки даних з веб на сервер GTM. У випадках, коли AdBlocker блокує GA4, він не надає дані на sGTM, тобто теги FB CAPI також не спрацьовують. Отже, в цьому сценарії події браузера не спрацьовують, так само як і серверні теги.

Щоб вирішити цю проблему, компанія Stape створила Custom Loader power-up. Цей power-up робить ваш GTM і GA4 скрипт стійким до блокувань AdBlocker. Таким чином, коли AdBlocker використовує свої максимальні можливості і блокує gtm.js або збирає запити, Custom Loader приховує їх і запобігає їх блокуванню. Таким чином, коли піксель FB не працює, ваш тег GA4 все одно буде доставляти дані в контейнер sGTM, а sGTM буде відправляти події FB CAPI в Facebook, тобто дії користувача відстежуються.

Ознайомтеся з цією статтею, щоб дізнатися більше про ввімкнення Custom Loader і про те, як зробити Web GTM і Google Analytics 4 стійкими до AdBlockers. 

Переваги:

• FB рекомендує налаштувати метод браузер+сервер.

Недоліки:

• Відстеження сервера може бути заблоковано, якщо ви не використовуєте power-up від stape Custom Loader (випадок використання описаний раніше в цьому блозі).
• Більш повна реалізація, якщо не використовувати web GTM для налаштування FB пікселів.
• Коли користувач на пристрої iOS відмовляється від відстеження, як веб-події, так і події сервера не будуть відправлятися. (Про це я розповім пізніше в блозі).

Хоча Facebook не рекомендує надсилати лише серверні події, це може бути хорошим рішенням, якщо у вас більше даних про користувачів або події в серверному контейнері Google Tag Manager, ніж у веб-контейнері. Або використовуйте будь-яку техніку для збагачення ваших серверних даних. У нас вже є два пости в блозі про те, як можна розширити дані sGTM за допомогою Firestore або Google Sheets.

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

Атрибуція FB конверсії користувачів iOS, які відмовилися від відстеження, є ще однією тривалою і суперечливою дискусією. В офіційній документації FB стверджує, що FB CAPI не допомагає відстежувати користувачів, які відмовилися від відстеження. Хоча деякі тематичні дослідження та наш експеримент показують, що одним із способів відстежити людей, які відмовилися від відстеження на iOS, є відправка тільки серверних подій через FB CAPI.

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

Переваги:

• Покращуйте атрибуцію конверсії, якщо у вас є більше даних в sGTM.
• Реалізація займає менше часу, оскільки не потрібно налаштовувати дедуплікацію пікселів та подій FB.
• Ви можете відстежувати користувачів, які відмовилися від відстеження.

Недоліки:

• FB не рекомендує використовувати цей метод.
• Вам потрібно буде вручну відправити fbp, оскільки ідентифікатор браузера не буде згенерований пікселем FB. Якщо ви використовуєте тег FB CAPI, ви можете легко включити цю опцію.

Налаштування FB CAPI через веб-хуки аналогічно відправці подій FB тільки через сервер. Єдина відмінність полягає в тому, як ви доставляєте дані з сервера Google Tag Manager. У методі №2 (відстеження тільки через сервер) ви відправляєте дані з web GTM на sGTM за допомогою GA4, UA або Data Tag. За допомогою цього методу ви можете запускати події FB CAPI на основі даних, які ви відправляєте через Webhooks.

Найпопулярніші CMS мають функціонал, який дозволяє легко налаштовувати веб-хуки. За допомогою power-up від stape Preview Header можна налагоджувати вхідні веб-хуки в sGTM. У нас вже є стаття в блозі про те, як відправляти вебхуки в sGTM.

Веб-хуки можуть бути чудовим джерелом даних для sGTM, оскільки вони несуть повну інформацію про замовлення та користувачів.

Основна перевага використання веб-хуків для відправки подій FB CAPI полягає в тому, що ці події не можуть бути заблоковані. Деякі клієнти вважають за краще тестувати відправку однієї і тієї ж події через браузер + сервер в порівнянні з веб-хуком (тільки сервер). Таким чином, вони можуть провести спліт-тест і порівняти, який метод має більш високий відсоток збігів і краще впливає на атрибуцію конверсії.

Переваги:

• Покращення атрибуції конверсій, оскільки веб-хуки містять цінні дані про користувача та замовлення
• Ви можете відстежувати користувачів, які відмовилися від відстеження на пристроях iOS.
• Дає чудову можливість для спліт-тестування відстеження web+сервер проти відстеження сервером через web GTM проти відстеження сервером через webhooks.

Недоліки:

• Налаштування може зайняти більше часу, оскільки вам потрібно буде налаштувати веб-хуки.

Команда Stape створила новий тег sGTM, розроблений спеціально для відправки FB офлайн-конверсії з sGTM. Використовуючи цей тег, ви можете автоматично відправляти події офлайн-конверсії в FB. Раніше вам доводилося або створювати власну інтеграцію, або завантажувати офлайн вручну через CSV. 

Основна перевага офлайн-подій FB полягає в тому, що їх можна вимірювати паралельно з піксельними та CAPI-подіями FB. Ви можете провести спліт-тест, якщо події конверсії веб+сервер, тільки сервер або FB офлайн працюють більш точно з точки зору атрибуції.

Крім того, наші експерименти показали, що, використовуючи веб-хуки як джерело даних для офлайн-конверсій FB, FB може відстежувати людей, які відмовилися від відстеження на пристроях iOS. Основна причина в тому, що офлайн-конверсії вважаються даними першої сторони, якими ви ділитеся з FB.

Ще однією значною перевагою є збільшене вікно атрибуції офлайн-подій FB. Є 28-денне вікно атрибуції кліків порівняно з 7-денним максимумом для FB CAPI або пікселя.

Нещодавно ми почали рекомендувати клієнтам stape налаштувати конверсію FB Offline паралельно з відстеженням FB CAPI. Основна причина полягає в тому, що він дає вам більше інформації для оцінки ефективності кампаній, а налаштування FB Offline conversion не займе багато часу, якщо ви вже впровадили FB CAPI.

Переваги:

• Він може відстежувати ефективність кампанії паралельно з пікселем FB або CAPI. Все, що вам потрібно зробити, це налаштувати стовпці в Ads Manager.
• Офлайн-конверсії FB мають вікно атрибуції 28 днів.
• Високий шанс, що він відстежуватиме користувачів, які відмовилися від відстеження на пристроях iOS 14/15.

Недоліки:

• На налаштування потрібен додатковий час.

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

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

Ми тут, щоб допомогти, якщо вам потрібна допомога в налаштуванні відстеження або усуненні будь-яких проблем. І обов’язково перевіряйте його регулярно, оскільки ми продовжуватимемо оновлювати наш блог останніми новинами та інформацією про цифровий маркетинг. До наступного разу!