Conversions API Meta — це пряме передавання маркетингових подій із сервера, сайту, застосунку або CRM до Meta для вимірювання й оптимізації реклами.
Одна покупка може піти до Meta двома дорогами. Pixel повідомляє про неї з браузера. Сервер надсилає ту саму подію через CAPI. Це не дві покупки, а два свідчення однієї дії. Якщо їх не навчити впізнавати одне одного, резервний канал перетвориться на подвійний рахунок.
Тому головне запитання під час налаштування — не «чи бачимо Server», а «чи зберігається ідентичність події від бізнес-дії до обох каналів».
Pixel, дзеркало і справжнє серверне джерело
Під назвою CAPI ховаються різні реалізації. Вони відрізняються не логотипом інтеграції, а місцем, де народжується серверна подія.
Подія від Pixel
- виникає у браузері
- бачить контекст сторінки
- залежить від виконання клієнтського коду
- зручна для швидкої діагностики
Подія від сервера
- виникає в бекенді або CRM
- може підтверджувати бізнес-результат
- не потребує повторного завантаження сторінки
- вимагає явного мапінгу й контролю доступу
Найпростіша інтеграція може взяти браузерний сигнал і переслати його серверним маршрутом. Це корисно для швидкого старту, але такий маршрут не поверне подію, якої браузер узагалі не створив. Партнерська інтеграція платформи вже може спиратися на оформлене замовлення. Власне з’єднання з бекендом або CRM дає найбільший контроль і найбільшу відповідальність за дані.
Документація Meta охоплює не лише сайт: джерелом можуть бути застосунок, бізнес-листування чи офлайн-результат. Отже, CAPI варто проєктувати від факту, який бізнес може підтвердити, а не від набору подій, що вже є у Pixel.
Дедуплікація: одна дія, один ідентифікатор
Meta рекомендує надсилати важливі вебподії через Pixel і CAPI як резервну пару. Для кожної дії обидва канали мають отримати ту саму назву та той самий унікальний ідентифікатор.
У браузерному виклику параметр називається eventID, у серверному — event_id. Написання відрізняється, значення — ні. Так само має збігатися event_name. Якщо браузер надсилає Purchase, а сервер — власну назву тієї самої дії, система не має рекомендованої пари для дедуплікації.
Ідентифікатор повинен позначати подію, а не користувача. Номер замовлення часто придатний для покупки, якщо він унікальний і доступний обом маршрутам. Для ліда потрібен інший стабільний ключ. Використовувати електронну адресу як event_id не слід: одна людина може здійснити кілька різних дій, а персональні дані мають окремі правила передавання.
Meta описує й альтернативне зіставлення через external_id та fbp, але однакові назва події й event_id — рекомендований і найпрозоріший маршрут. Простота тут важлива: помилку можна відтворити на одній контрольній дії.
Які поля несуть зміст, а не просто проходять перевірку
Серверний запит має відповісти на кілька окремих запитань: що сталося, коли, звідки прийшла дія, як її впізнати та яку цінність вона мала. Формально прийнятий запит ще може бути слабким сигналом.
| Критерій | Що перевірити | Що ламається |
|---|---|---|
| Ідентичність | event_name та event_id | дубль або окрема подія |
| Час | фактичний час дії | хибна послідовність шляху |
| Джерело | action_source і URL для вебподії | неправильний контекст |
| Зіставлення | допустимі дані клієнта | слабкий зв’язок із взаємодією |
| Цінність | сума та валюта з бізнес-системи | неправильна окупність |
| Згода | дозволений обсяг даних | порушення вибору користувача |
Meta вимагає action_source для серверних подій, а для подій сайту — також event_source_url. Обов’язковість поля не гарантує правильності його значення.
Дані клієнта використовуються для зіставлення, але більше полів не завжди означає краще. Передавати слід лише те, що законно отримано, доречне для події та правильно нормалізоване. CAPI — не обхід згоди. Серверна природа маршруту не змінює рішення людини щодо використання її даних.
Цінність теж має надходити з надійного місця. Якщо браузер бере суму зі сторінки подяки, а сервер — із замовлення після знижки, розбіжність треба вирішити на рівні визначення події. Подія Purchase повинна означати одну й ту саму бізнес-дію в обох каналах.
Перевірка після запуску
У Events Manager можна побачити спосіб підключення, свіжість подій та стан дедуплікації. Перевірка має пройти не на випадковому трафіку, а на контрольній дії з відомими параметрами.
Спочатку підтвердьте отримання браузерної та серверної версій. Потім знайдіть спільний ідентифікатор. Переконайтеся, що після обробки вони рахуються як одна подія. Перевірте затримку: подія, яка приходить надто пізно, може бути технічно прийнята, але менш корисна для оперативної оптимізації. Нарешті, звірте суму, валюту та джерело дії.
Не оцінюйте запуск лише за загальним зростанням кількості конверсій. Раптове зростання може бути не поверненням сигналу, а дублюванням. Спочатку потрібна правильність на рівні окремої події, потім — стабільність потоку, і лише після цього — оцінка впливу на кампанії.
Загальну послідовність перевірки аналітики до запуску реклами зібрано в чеклісті аналітики, але для CAPI критерієм приймання завжди залишається пара «одна дія — один підсумковий запис».
Якщо серверна подія не має власного підтвердженого джерела, спільного event_id і перевіреної дедуплікації, напис Server у кабінеті ще не означає, що CAPI виконує свою роботу.