23 листопада 2021

Чому Facebook Conversions API це не вирішення проблеми iOS 14.5?

Якщо ви читаєте цю статтю, ймовірно ви вже на собі або своїх клієнтах теж відчули комбо-ефект обмежень відстеження (ATT та PCM) у iOS 14.5, та протоколу Aggregated Event Measurement у Facebook. Ми в Turboweb розуміємо що стоїть за складними словами, як це вплинуло на таргетовану рекламу і розповідаємо про свій досвід роботи в умовах обмежень.

Частина 1. Вступ

У квітні 2021 року виходить велика і жахлива iOS 14.5 з фреймворком App Tracking Transparency (ATT), в рамках якого всі програми, що здійснюють збирання та відправлення даних у треті системи, стали зобов'язані запитувати у користувачів "дозвіл на відстеження їх дій". Що саме означає це загальне формулювання і які наслідки у цих змін?

Для ідентифікації користувача програми використовують IDFA – унікальний номер, за допомогою якого рекламні мережі та сервіси аналітики розпізнають конкретний пристрій та показують його власнику максимально цільову рекламу.

Раніше програми мали доступ до IDFA за замовчуванням, а тепер на пристроях з iOS 14.5 і вище для цього потрібно спочатку отримати дозвіл відстежувати дії користувача. Якщо користувач дає дозвіл (opt-in користувач) – рекламна система отримує доступ до IDFA і може співвідносити події з конкретним пристроєм, а якщо забороняє (opt-out користувач) – рекламна система в рамках протоколу Private Click Measurement (PCM) не отримує даних про його діях зовсім або отримує у знеособленому вигляді.

Протокол PCM, а також нововведення iOS 14.5, працює на основі технології анонімного співвідношення кліків. Його основне завдання забезпечити певний компроміс, завдяки якому стає можливим точний вимір ефективності реклами за збереження анонімності opt-out користувачів. Тобто кількість конверсій з реклами враховується за всіма покупцями, а look-alike і ремаркетинг можна налаштувати лише з тих, хто ділиться даними.

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

Так, у відповідь на оновлення рекламної політики Apple, у Facebook ввели протокол Aggregated Event Measurement, який дозволив зберегти відстеження на iOS хоч у якомусь вигляді. Ми не будемо тут докладно розбирати, що саме змінилося у самому Facebook, а перейдемо безпосередньо до наслідків запроваджених обмежень

 

Частина 2. Що було далі?

Спочатку ми сумнівалися, що обмеження iOS 14.5 будь-яким чином зачеплять наших клієнтів, тому що ми спеціалізуємося на інтернет-магазинах, які як основний торговий майданчик використовують сайт і в них рідко бувають власні мобільні програми. А трекінг подій на сайті, наскільки нам відомо, у тому числі і на мобільних пристроях відбувається за допомогою Cookies, а не IDFA. Більше того, реклама в мобільних додатках Facebook і Instagram відкривається у вбудованому браузері програми, а значить атрибуція могла б, як мінімум, відбуватися на підставі авторизації користувача.

Однак незабаром після того, як користувачі стали оновлюватися до iOS 14.5 і вище, у наших клієнтів з великою часткою користувачів iOS помітно знизилася ефективність реклами у Facebook/Instagram. І чим більше був рекламний бюджет клієнта - тим відчутніше виявлялися ці втрати.

Як і, напевно, всі колеги в рекламній індустрії, якийсь час ми перебували в повній розгубленості і намагалися зібрати крихти доступної інформації на цю тему

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

Якийсь час, начитавшись англомовних форумів, ми навіть сподівалися повністю “обійти” заборони користувачів та відслідковувати події opt-out користувачів за допомогою зв'язки серверних тегів у Google Tag Manager (GTM) та Conversions API.

Серверний контейнер GTM, якщо коротко, це програмне забезпечення Тег менеджера, яке можна встановити на спеціальний власний сервер і привласнити йому піддомен основного сайту. При встановленні трекера на сайті дані про події відправляються не безпосередньо в Google, Facebook або інші рекламні та аналітичні системи, а на власний сервер в рамках одного домену (first party), а значить в обхід всіх браузерних обмежень, таких як ITP, блокувальники реклами , відключені кукіс 3-ї сторони ітд. Далі з серверного контейнера GTM можна налаштувати надсилання подій до третіх систем, наприклад у Facebook Pixel за допомогою технології Conversions API. Таким чином, GTM server-side є сервісом-посередником, який отримує дані в обхід різних браузерних обмежень і вже звідти без будь-яких обмежень відправляє в потрібну систему.

Щоб перевірити гіпотезу про обхід обмежень iOS 14.5 за допомогою серверного GTM, ми провели такий експеримент:

  1. Налаштували відстеження подій сайту в серверному контейнері з власним піддоменом
  2. У контейнері створили тригер, який спрацьовує лише при відвідуванні певної сторінки з офісної ip-адреси, щоб тільки ми могли її спровокувати
  3. При спрацьовуванні тригера налаштували передачу кастомної події у Facebook
  4. У Facebook при початку цієї кастомної події налаштували відстеження спеціально налаштованої конверсії
  5. Запустили рекламу на маленьку аудиторію, в якій були наші співробітники з opt-out девайсами
  6. Побачивши цю рекламу, співробітники з opt-out налаштуваннями у програмах Instagram і Facebook виконали цільову дію тригера, щоб спровокувати облік спеціально налаштованої конверсії в результатах рекламної кампанії.
  7. Зачекали 3 дні (події, надіслані через сервер, можуть оброблятися до 72 годин)
  8. У підсумку – , кастомні події співробітників відобразилися у статистиці подій пікселя, але конверсії не були співвіднесені з рекламною кампанією
  9. Для чистоти експерименту ми виконали пункт 6 ще раз на девайсі з opt-in налаштуванням програми Instagram, і конверсія коректно відобразилася в результатах відповідної рекламної кампанії

Далі ми провели додатковий експеремент:

  1. У Facebook Pixel включили Розширений пошук збігів по email та телефону
  2. Співробітники з opt-out налаштуванням програми Instagram перейшли по рекламі з попереднього експерименту та виконали умови для спрацювання спеціально налаштованої конверсії
  3. Далі ми внесли подію (замовлення) в CRM-систему і звідти з номером телефону покупця передали до Pixel через Conversions API (номер телефону відповідав прив'язаному до профілю Instagram)
  4. Подія відобразилася в пікселі, але конверсії так і не були співвіднесені з рекламною кампанією

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

Тобто, навіть якщо за допомогою Conversions API відправляти події opt-out користувачів у Facebook Pixel “насильно”, вони будуть отримані пікселем, але не будуть співвіднесені з рекламною кампанією, що спровокувала їх.

Частина 3. Компенсаційна модель

В умовах де прямий обхід обмежень iOS 14.5 неможливий, ми стали шукати інші можливості компенсувати втрату даних opt-out користувачів, використовуючи можливості Conversions API.

Ще до релізу iOS 14.5 дані про події з сайту були неповними. Проблеми відстеження подій лише через піксель на сайті можна розділити на 2 типи:

  1. Різні види обмежень браузерного відстеження, у тому числі iOS 14.5, ITP, блокувальники реклами та вимкнені Cookies
  2. Події, які відбуваються поза сайтом, наприклад, замовлення по телефону, в месенджерах або в офлайні.

Перший тип проблеми

Перший тип проблеми – обмеження браузерного відстеження, (за винятком opt-out користувачів iOS 14.5) – вирішується за допомогою відстеження подій через серверний контейнер GTM або новий інструмент Facebook Conversions API Gateway, принцип роботи якого аналогічний серверному контейнеру GTM. При цьому налаштування серверного відстеження не означає, що браузерне відстеження через піксель слід відключити - Facebook рекомендує одночасно використовувати обидва способи одночасно. Особливу увагу при такому наслаштуванні слід приділити дедуплікації подій. Для коректного обліку результатів рекламних кампаній, піксель повинен бачити, що отримує не 2 різні події, а те саме подія з браузера і сервера. Для цього всім подіям надається параметр ID, при збігу якого пара з браузерної та серверної події дедуплікується, тобто враховується як одна.

Другий тип проблеми

Відсутність обліку подій поза сайтом – вирішується за допомогою інтеграції CRM-системи та Conversions API (бізнес без CRM може використовувати Google-таблицю). На практиці, у сфері інтернет-магазинів, ми надсилаємо до Facebook замовлення з CRM.

Атрибуція таких замовлень відбувається за номером телефону та іншими даними покупця (email, ПІБ, місто доставки, дата народження тощо). За допомогою інтеграції Conversions API з CRM також можна збирати коректніші/додаткові дані про подію, залежно від специфіки бізнесу. Наприклад, відправляти в Facebook тільки оплачені замовлення, замість суми замовлення відправляти маржу – особливо корисно за наявності товарів з різною маржинальністю та/або РК зі стратегією Мінімальна окупність витрат на рекламу.

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

Висновки

Conversions API не є прямим рішенням обмежень iOS 14.5, а лише дозволяє побічно компенсувати втрату даних opt-out користувачів. При цьому Conversions API не спосіб збору даних, а лише інструментом/способом їх передачі у Facebook Pixel. Збір даних для Conversions API можна організувати різними способами - використовувати готові рішення, розробити індивідуальну інтеграцію для ваших систем або найняти агентство, яке вже:

  1. досконально розібралося в цьому та поставило на потік
  2. швидко налаштує оптимальну комбінацію інструментів Conversions API для ваших потреб

Автор статті

Данііл Бондарчук

Product Manager