Conversions API (CAPI) – це інструмент що дозволяє отримувати дані про користувачів які взаємодіяли з рекламою, від серверу клієнта до рекламного кабінету.
Сервер клієнта – для спрощення тут ми будемо ототожнювати це поняття із звичайним сайтом та CRM. Тобто сервер = сайт або CRM, або і те і інше.
В чому різниця CAPI від Meta Pixel?
Pixel збирає дані по подіям користувача на основі браузерних подій і тільки в той момент коли користувач взаємодіє із сайтом/соц. мережами, тобто там де піксель впринципі може працювати. За цими межами піксель не має інформації про користувача та його події.
CAPI дозволяє розширити цю інформацію та отримувати дані не тільки від браузера, але і від нашого серверу + дані з нашої CRM (тому що в ній є інформація про те що відбувається з людиною після того як вона стала лідом)
Для чого передавати дані по CAPI?
Існує щонайменше дві причини передавати дані:
1. Втрата даних, що може відбуватись через:
- Використання людьми плагінів що блокують рекламу
- Баги, помилки на сайті
- Оновлення iOS яке блокує відслідковування даних про користувача
2. Коли нам потрібно оптимізовувати рекламу під продажі, але в нас немає можливості оптимізовуватись під них:
- Коли запускаємо лід-форми, або квізи – ми отримуємо лідів, але кабінет нічого не знає про подальші продажі цим лідам
- Коли запускаємо кампанії на переписки, кабінет також не знає що відбувається далі (так, зараз можна відмічати переписки ярликами, але наприклад цінність продажу там поки передати неможливо, плюс ярлики працюють тільки з моб. застосунку і тут є ряд незручностей для клієнта)
- Коли запускаємо кампанію на конверсії на сайт на якому немає кошика і можливості оплати карткою, є тільки відправка форми
Підсумовуючи, завдяки CAPI можна покращити алгоритм оптимізації реклами за рахунок:
1) Передачі більшої кількості подій
2) Можливості передачі подій про покупку коли піксель може ловити тільки конверсію на заповнення форми, або початку переписки
3) Можливості налаштовувати рекламу на подію покупки, навіть якщо на тому ж сайті немає можливості оплати
Щоб отримати всі ці переваги важливо мати на стороні клієнта CRM систему, яка буде вміти зберігати потрібну технічну інформацію про користувача, та потім за певних умов передавати ці дані в Meta (через CAPI до рекламного кабінету).
Для ecommerce проєктів зазвичай більша частина замовлень проходять через кошик і там ми можемо одразу отримувати інформацію про покупку та її цінність, чи потрібен тут CAPI? Відповідь – так, зайвим не буде, бо як ми розбирали вище, дані можуть втрачатись, CAPI може зменшити їх втрату, а також може передавати ті замовлення які не проходили через кошик, але все одно існують в CRM системі, наприклад замовлення які були зроблені в офлайн магазинах, або прийшли через дзвінок, або були створені вручну.
Як передавати дані з CRM до рекламного кабінету
Ми вже розібрались для чого нам передача даних з CRM, якщо це не зрозуміло повертайтесь читати з самого початку, це важливо. Тепер ми розглянемо що передавати, та як передавати.
Почнемо з того, в яких випадках лід може зʼявитись у CRM, а верніше які випадки нас цікавлять найбільше:
1) Лід потрапив у CRM після заповнення форми на сайті
2) Лід був створений вручну в CRM
3) Лід надійшов через інтеграцію з Instagram direct або месенджера (тобто там була розпочата переписка і потім вона дійшла у CRM)
Для випадку з потраплянням ліда з Сайту до CRM ми як правило будемо мати імʼя людини, її номер телефону, можливо email. В залежності від форми на сайті може бути і інша інформація.
При потраплянні ліда до CRM починається процес обробки ліда менеджером. Після цієї обробки в картці ліда може зʼявитись і інша інформація.
Для нас ключове мати:
- Номер телефону
- Імʼя
- Прізвище
- Сума замовлення – тільки коли по факту лід дійшов до оплати та фактично її здійснив!
Контактні дані користувачів не передаються просто так в звичному нам виді, вони повинні хешуватись, тобто кодуватись в певний набір даних.
Такий email як team@labgramm.com може виглядати як 7b17fb0bd173f625b58636fb796407c22b3d16fc78302d79f0fd30c2fc2fc068
Чи потрібно обовʼязково мати кожен з цих контактних даних? Ні. Але чим більше їх буде, тим краще ми зможемо співставити цю людину з тим користувачем який взаємодіяв з рекламою. Відповідно Meta при отриманні цих даних зможе більш вірогідно ідентифікувати цього користувача в своїй базі.
Коли відбувається передача даних з CRM у Meta?
В момент, коли лід став клієнтом, тобто є факт оплати товару/послуг.
Окрім контактних даних людини на стороні сайту в нашого ліда будуть і інші технічні дані які зберігаються у кукі файлах.
Кукі-файли (cookies) — це невеликі текстові файли, які вебсайти зберігають у браузері користувача. Вони використовуються для збереження інформації про відвідувача та його дії на сайті.
При переході людини з реклами на сайт, важливо щоб на ньому вже стояв піксель, інакше потрібні кукі файли працювати не будуть, хоч це і можна обійти, але технічно реалізовується складніше.
Нам потрібні будуть 2 основних кукі файли, вони створюються автоматично пікселем і в них записується технічна інформація про користувача що перейшов з реклами, це:
- _fbc (ClickID) – клік айді називається так, через те що це по суті ідентифікатор користувача що клікнув по конкрентній рекламі, таким чином можна співставити цей ідентифікатор з користувачем Meta, відповідно це поєднує дані між сайтом, рекламним кабінетом та креативом
- _fbp – схожий ідентифікатор, він фіксує id користувача яке зберігається за конкретним браузером користувача, щоб в подальшому можна було ідентифікувати його якщо він повернеться на сайт не клікавши по рекламі
Задача розробника забирати ці ідентифікатори з кукі та передавати разом із лідом в CRM систему. В момент коли лід стає клієнтом, ці дані повертаються до рекламного кабінету разом з усією іншою інформацією (контактні дані, сума замовлення, технічні параметри).
Що передається назад із CRM до рекламного кабінету:
- Контактні дані - розібрались
- Дані про замовлення (сума) - розібрались
- Валюта - якщо ми передаємо подію покупки, то обовʼязково потрібно передавати інформацію про валюту (USD, UAH...)
- Ідентифікатори з кукі файлів fbc, fbp – розібрались
- Параметри:
- "event_name": "Purchase" – назва події (стандартизована для події покупки, якщо передаємо щось інше, значить потрібно називати подію інакше)
- "event_time": 1712248396 – (час події в форматі UNIX)
- "action_source": "system_generated" – (інформація звідки згенерована подія, у випадку з передачею даних із CRM обовʼязково обирається саме "system_generated")
Чи це остаточний набір даних і він повинен бути тільки таким? Ні. Ми зібрали мінімальний мінімум щоб мати змогу повʼязати дані з CRM та рекламним кабінетом. У Meta є величезна кількість інших параметрів та подій які можна передавати.
Дізнатись деталі можна в документації Meta:
https://developers.facebook.com/docs/marketing-api/conversions-api/parameters
В результаті готовий технічний код що надсилається з CRM до Meta може мати приблизно такий вид:
{
"data": [
{
"event_name": "Purchase",
"event_time": 1712248396,
"action_source": "system_generated",
"user_data": {
"fbc": "fb.1.1554763741205.IwAR2F4-dbP0l7Mn1IawQQGCINEz7PYXQvwjNwB_qa2ofrHyiLjcbCRxTDMgk",
"em": ["7b17fb0bd173f625b58636fb796407c22b3d16fc78302d79f0fd30c2fc2fc068"],
"ph": ["6069d14bf122fdfd931dc7beb58e5dfbba395b1faf05bdcd42d12358d63d8599"],
},
"custom_data": {
"currency": "USD",
"value": "142.52"
}
}
]
}
Щоб погратись із параметрами та подивитись як формується код є спеціальний інструмент.
Інструмент побудови подій Payload Helper:https://developers.facebook.com/docs/marketing-api/conversions-api/payload-helper
В цьому інструменті можна створити тестову подію і потім відправити її на реальний піксель.
Зробити таку відправку можна в інструменті Graph API Explorer:
https://developers.facebook.com/tools/explorer
Тобто перший інструмент дозволяє побудувати код з потрібних параметрів, а другий відправити цей код як тест і подивитись як це фактично працює.
На цьому базовий огляд Meta Conversions API закінчено. Якщо ви потребуєте подібних налаштувань – звертайтесь до нашої команди.
