Офлайн-конверсія Facebook за допомогою серверного GTM

Рекламодавці Facebook завжди шукають способи підвищити ефективність своїх кампаній. Один із способів зробити це — покращити відстеження переходів, що було непростим завданням останніми роками.

Зі збільшенням обмежень щодо відстеження впровадження Facebook Conversion API (який надсилає дані на сервери FB з вашого сервера) є найпопулярнішим способом покращення відстеження FB. У нас уже є докладна публікація в блозі про те, як налаштувати FB CAPI.

Ви також можете використовувати старий спосіб надсилання серверних подій у Facebook – офлайн-перетворення. Це рішення покладається на дані першої сторони, на які не можуть вплинути обмеження відстеження або короткочасні файли cookie.

У цьому гайді ми показуємо, як надсилати офлайн-події з вашої CRM або POS до контейнера server Google Tag Manager через вебхуки, а потім передавати їх у Meta через Conversions API.

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

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

У наш час послідовність конверсії є складною та включає багато точок (як за кліками, так і за переглядами). З цієї причини деякі маркетологи обирають офлайн-конверсії як другий кут аналізу під час оцінки результатів кампаній у Facebook, як офлайн, так і онлайн.

Існує кілька способів підходу рекламодавців до налаштування FB офлайн-конверсій:

• Завантаження вручну за допомогою файлу CSV
• Вбудована спеціальна інтеграція
• Конектори як наприклад Zapier

Кожен із цих методів має свої недоліки. Щоб реалізувати індивідуальну інтеграцію, вам потрібно найняти розробників, які створять конектор для вашої CRM (або POS тощо) і FB офлайн-конверсії. За допомогою таких інструментів, як Zapier, це може бути легко налаштувати, але ціна буде високою, особливо якщо подій багато. Під час завантаження вручну потрібно виконати багато роботи під час підготовки файлу CSV.

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

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

Перш ніж налаштовувати теги ss за допомогою sGTM, потрібно виконати дві важливі речі: створити серверний контейнер GTM та доставити дані до sGTM (є кілька способів надсилання даних, є налаштування серверного GA4, DataTag/DataClient, Webhooks тощо). 

Може бути кілька причин використовувати офлайн-конверсії Facebook.

• Вимірюйте події точніше
• Створюйте якісні індивідуальні та схожі аудиторії
• Оптимізуйте кампанії для отримання найефективніших оголошень і наборів оголошень
• Збільште ROAS кампаній у FB

Але якщо ви вже впровадили FB CAPI? Чи варто вам розглядати реалізацію офлайн-конверсій FB за допомогою sGTM?

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

Як щодо офлайн-конверсій FB і обмежень відстеження iOS? Немає офіційної документації про те, як офлайн-конверсії FB впливає на тих, хто відмовився від відстеження на своїх мобільних телефонах. Нижче я опишу свою думку про те, як FB обробляє такі дані.

У цьому гайді використовуватиметься вебхук CRM для активації тегів офлайн-конверсій FB. Коли користувач на пристроях iOS, який відмовився від відстеження, робить покупку, FB pixel не буде фіксувати цю подію (принаймні, вони не повинні відстежувати її відповідно до правил політики конфіденційності користувача).

Після того як користувач робить покупку, CRM надсилає вебхук до sGTM з усією інформацією про деталі замовлення та інформацію про користувача. Як тільки sGTM отримує ці дані, він надсилає запит до FB офлайн-конверсій. У даних вебхука не буде ідентифікації того, чи дозволив/не дозволив користувач FB відстежувати їх. Теоретично це означає, що якщо FB може зіставити цього користувача з особою, яка побачила вашу рекламу, офлайн-конверсія буде зарахована до результату кампанії FB.

Ще одна величезна перевага офлайн-конверсій FB полягає в тому, що воно все ще відповідає вимогам для 28-денного вікна атрибуції. У той час як у FB pixel або FB CAPI максимум, який ви можете отримати, це 7-денна атрибуція.

1. Відкрийте попередній перегляд контейнера sGTM -> натисніть три крапки у верхньому правому куті -> натисніть Надіслати попередній перегляд вручну -> скопіюйте X-Gtm-Server-Preview HTTP header.

2. Увійдіть у свій обліковий запис stape -> відкрийте контейнер sGTM -> перейдіть на вкладку Power-Ups -> натисніть config HTTP Header Config -> вставте значення, яке ви скопіювали з попереднього перегляду серверного контейнера Google Tag Manager -> натисніть Save.

Щойно ви додасте заголовок HTTP, ви зможете побачити веб-хуки в попередньому перегляді sGTM.

Не забудьте вимкнути заголовок HTTP Preview після завершення налаштування.

3. На цьому кроці я налаштую вебхуки, які надсилатимуть дані до sGTM. Перейдіть до своєї CRM (у моєму випадку це WordPress). Додайте назву та URL-адресу веб-хуку. Використовуйте URL-адресу свого сервера тегування як URL-адресу веб-хука + настроюваний шлях (ви можете знайти URL-адресу сервера тегування в налаштуваннях контейнера sGTM на stape). Налаштуйте дані вебхуку, які потрібно надіслати.

4. Відкрийте попередній перегляд контейнера sGTM і протестуйте вебхук. Ви повинні побачити відповідний запит у налагоджувачі sGTM.

5. Давайте налаштуємо клієнта в sGTM, який буде приймати запит, надісланий вебхуком. Для цього необхідно імпортувати Data Client до свого sGTM. Додавши клієнта даних до шаблону клієнта sGTM, перейдіть до розділу «Клієнти» в sGTM -> клацніть новий клієнт -> виберіть клієнт даних і прокрутіть униз до параметрів прийнятого шляху -> додайте шлях запиту вашого вебхука. Збережіть клієнт.

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

До липня 2023 року для надсилання даних про офлайн-конверсії Facebook використовувався Offline Conversions API. Але тепер все стає набагато простіше завдяки оновленню Facebook Conversions API.

Якщо ви використовуєте Stape's Facebook Offline Conversion Tag, який зараз застарів, у липні 2023 року ваші події могли перестати надходити, і під час налагодження ви отримаєте помилку, подібну до цієї:

Оскільки API офлайн-конверсій незабаром буде повністю припинено, ми рекомендуємо відразу перейти до звітності через оновлений стандартний API конверсій, тим більше, що він став простішим і логічнішим.

Раніше ви надсилали офлайн-конверсії в окремий офлайн-набір даних, в цьому більше немає необхідності, оскільки замість стандартних FB-пікселів у вас тепер, ймовірно, є "набір даних" (Dataset), що, по суті, одне і те ж, і більшість пікселів були автоматично перетворені в набір даних, чого ви, можливо, навіть не помітили :)

Отже, для звітності FB Offline тепер обов'язковим є використання саме Dataset, а не Pixel. У більшості випадків, якщо ви зайдете на свій піксель і перевірите - ви побачите, що він вже став Dataset.

Найпростіший спосіб перевірити це - просто зайти в налаштування і переконатися, що у вас стоїть "Dataset ID" замість "Pixel ID" (число залишається незмінним):

Якщо у вашому випадку у вас залишився піксель - ви можете знайти інструкції про те, як конвертувати FB Pixel в Dataset або створити новий Dataset тут.

Отже, ми переконалися, що у вас вже є Dataset, тепер залишилося налаштувати відправку офлайн-подій, що фактично нічим не відрізняється від налаштування стандартних FB-подій.

Раніше ми додали оновлення до тегу Facebook Conversion API для серверного контейнера. Окрім переходу на нову версію API, в інтерфейсі також з'явився пункт з можливістю вибору джерела дії:

І так, щоб відправити подію в офлайн - все, що вам потрібно зробити, це вибрати Фізичне сховище в Джерелі дії.

Отже, уявімо, що у нас є CRM-система, в якій зберігаються клієнти компанії. Деякі продажі відбуваються на сайті, і у нас вже налаштована розсилка онлайн-конверсій, але також деякі продажі відбуваються через електронну пошту, телефон або у фізичному магазині. Для таких продажів користувач не проходить через стандартний онлайн-потік, тому єдиний варіант для нас - попросити розробників налаштувати веб-хук у форматі JSON, який буде надсилатися на наш серверний GTM-контейнер, коли, наприклад, картка клієнта переходить у статус "Завершено", що означає, що транзакція закрита.

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

Повний список даних користувачів, які приймає Facebook, та їхній формат можна знайти тут.

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

Для налагодження веб-хуків вам потрібно використовувати Stape Power-UP 'Http header', ми описували, як надсилати і налагоджувати веб-хуки в sGTM раніше в цьому блозі.

Подальше налаштування нічим не відрізняється від налаштування стандартної події.

1) Перенесіть дані з Event Data у формат, який вимагає Facebook.

2) Додайте відповідні змінні до тегу Facebook і виберіть Action Source: Physical Store (саме цей пункт і переведе подію в тип offline).

3) Додайте правильний тригер.

У моєму прикладі я використовую Data Client для отримання веб-хуків (і рекомендую вам зробити так само).

Data Client має зручну опцію - додатковий шлях. Я завжди використовую його для веб-хуків, щоб переконатися, що не буде хибних спрацьовувань від інших тегів. Я використовую шлях /webhook для вебхуків, що означає, що розробники надсилають вебхуки до мого контейнера https://gtm.example.com/webhook.

І, відповідно, я можу використовувати простий тригер для моєї події з додатковою валідацією:

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

Згодом ви побачите події з типом "Офлайн" у вашому наборі даних як у загальному списку, так і в деталях події:

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

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

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

Використовуючи вебхуки разом із тегом Facebook Conversions API у контейнері server Google Tag Manager, ви можете налаштувати офлайн-конверсії з меншими ручними зусиллями. Щоб підвищити ефективність налаштувань, дотримуйтесь найкращих методів офлайн-конверсій.

Якщо вам потрібна допомога з налаштуванням тегів ss, ми тут, щоб допомогти!