Передача конверсій у Meta CAPI через короткі посилання Elido

Власні рекомендації Meta, опубліковані на сторінці початку роботи з Conversions API (доступ від 2026-05-12), позиціонують браузерний піксель як доповнення до Meta CAPI, а не навпаки. Ця зміна відбулася приблизно з виходом iOS 14.5: App Tracking Transparency погіршив якість сигналу Meta, ITP «відкусив» ще частину, а кількість встановлень блокувальників реклами продовжує зростати. До 2026 року команди, що запускають рекламу в Meta на аудиторії з великою часткою iOS, регулярно спостерігають зникнення 30-40% подій конверсії ще до того, як вони потрапляють у звіти.

Meta CAPI - це серверний канал, який оминає всі ці перешкоди. Ваш сервер спілкується безпосередньо з Meta Graph API. ITP тут не діє. Блокувальники реклами не перехоплюють запити. Коефіцієнт відповідності зростає, тому що ви можете надсилати хешовані email та номери телефонів разом із ідентифікатором кліку; оскільки і події в браузері, і події на сервері мають спільний ключ дедуплікації, Meta зараховує конверсію лише один раз, навіть якщо спрацювали обидва шляхи.

Це покрокова інструкція з налаштування Meta CAPI через короткі посилання Elido. У огляді відстеження конверсій на стороні сервера описана ширша архітектура (GA4, TikTok, Mixpanel, семантика повторних спроб). Повний посібник з UTM варто прочитати першим, якщо ваше маркування кампаній все ще не систематизоване.

Коротко про головне#

• Meta Pixel втрачає 30-40% подій конверсії на трафіку з iOS через ITP та блокувальники реклами; Meta CAPI надсилає ці події безпосередньо з вашого сервера, відновлюючи більшу частину прогалини.
• Ключ дедуплікації - event_id - має бути ідентичним для вашого браузерного пікселя та події Meta CAPI. Відсутність цього призводить до подвійного підрахунку, що порушує розподіл бюджету на оптимізацію Meta.
• Вища щільність ключів відповідності (хешований email, телефон, ідентифікатор кліку fbc, кукі fbp) безпосередньо покращує коефіцієнт відповідності атрибуції; Elido фіксує fbclid у момент кліку та пов'язує його з кожною подальшою конверсією.
• Валідація займає близько 10 хвилин: у Meta Events Manager є панель Test Events, яка показує надходження подій Meta CAPI протягом 30 секунд, задовго до того, як оновиться дашборд коефіцієнта відповідності (що займає 24 години).

Що вам знадобиться перед початком#

Три речі, всі з Meta Business Manager.

Pixel ID. Кожен рекламний акаунт Meta має принаймні один піксель. Знайдіть його в Events Manager у розділі Data Sources. Числовий рядок - наприклад, 1234567890 - це те, що ви вставите в налаштування інтеграції Elido.

System User access token. Це облікові дані, які дозволяють Elido записувати події у ваш піксель. Перейдіть у Business Settings, потім Users, потім System Users. Створіть системного користувача з роллю Standard access, призначте його до пікселя (Manage permissions) і згенеруйте токен із доступами ads_management та business_management. Токен довготривалий; оновлюйте його тоді, коли оновлюєте інші сервісні ключі, а не за розкладом. Зберігайте його як секрет робочого простору - не в сирцевому коді і не в таблиці.

Event source URL pattern. Кожна подія Meta CAPI містить event_source_url, який повідомляє Meta, на якій сторінці відбулася конверсія. Для подій покупки це зазвичай URL-адреса підтвердження замовлення. Для лідів - сторінка відправки форми. Ви не прописуєте їх жорстко; вони надходять із вашого вебхука замовлення або контексту запиту вашого бекенду в момент конверсії.

Ключі відповідності: чому важлива щільність даних#

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

Чотири ключі, які мають найбільше значення:

em (SHA-256 хешований email). Найцінніший сигнал. Якщо у вас є email клієнта в момент конверсії (як це майже завжди буває в e-commerce), надсилайте його. Довідка щодо параметрів інформації про клієнта Meta (доступ від 2026-05-12) визначає правила нормалізації: малі літери, видалення пробілів на початку та в кінці, жодних змін у домені. Хешуйте нормалізований рядок. Хешування [email protected] безпосередньо дасть неправильне значення; хешувати потрібно [email protected].

ph (SHA-256 хешований телефон). Та сама дисципліна нормалізації. Формат E.164: код країни, без пробілів, тире та дужок. +4915123456789 хешується у значення, яке Meta зможе зіставити; 015123456789 - ні.

fbc (Facebook click ID). Коли користувач клікає на рекламу Meta, цільова URL-адреса отримує параметр запиту fbclid. Ваша цільова сторінка або обробник редиректів Elido зчитує та зберігає його. Поле fbc будується з цього: fb.{version}.{creationTime}.{fbclid}, де версія - 1, а час створення - Unix-таймштамп у мілісекундах. Elido фіксує fbclid з URL редиректу в момент кліку та зберігає його в записі про клік. Коли ви робите POST конверсії з click_id, значення fbc вже прикріплене і передається автоматично.

fbp (Facebook browser pixel cookie). Це кукі _fbp, який Meta Pixel JS встановлює на вашому домені. З точки зору вашого домену, це першосторонній кукі (first-party cookie). Ваш сервер зчитує його з заголовків запиту в момент оформлення замовлення і включає в корисне навантаження конверсії. Без нього якість зіставлення Meta для резервного шляху через браузер погіршується.

Практичний пріоритет: em першим (майже завжди доступний), fbc другим (Elido надає його для конверсій, що походять від кліку), fbp третім (зчитується з кукі на сторінці підтвердження), ph останнім (часто не фіксується). Дані з em + fbc будуть зіставлятися значно краще, ніж без них.

Налаштування в Elido#

Інтеграція знаходиться в Workspace Settings, у розділі /integrations, далі Meta CAPI.

Вставте ваш Pixel ID та System User access token. Elido миттєво перевіряє токен через Meta Graph API - помилка 400 тут означає, що токен сформовано неправильно або йому бракує необхідних доступів; перевірте дозволи системного користувача перед продовженням. Після валідації інтеграція стає активною для робочого простору. Усі відстежувані посилання в робочому просторі беруть участь у роботі; окремого перемикача для кожного посилання немає.

Коли користувач клікає на відстежуване посилання, edge-обробник Elido зчитує fbclid з рядка запиту (якщо він є) і записує його в дані про клік. Це відбувається на рівні редиректу, ще до того, як користувач потрапить на ваш сайт, тому фіксація надійна незалежно від того, чи спрацює JavaScript на вашому цільовому сайті.

Коли відбувається подія конверсії, відправте її POST-запитом на /v1/conversions:

curl -X POST \
  https://api.elido.app/v1/conversions \
  -H "Authorization: Bearer $ELIDO_TOKEN" \
  -d '{
    "click_id":   "clk_01HYZ7T8WV6KQX3M",
    "event_name": "Purchase",
    "event_id":   "ord_98231",
    "value":      89.50,
    "currency":   "EUR",
    "user": {
      "email":  "[email protected]",
      "phone":  "+4915123456789"
    }
  }'

Після отримання Elido знаходить запис про клік, зчитує збережений fbclid для створення fbc, нормалізує та хешує email та phone, формує повний пакет даних Meta CAPI і надсилає POST на https://graph.facebook.com/v21.0/{pixel_id}/events. API негайно повертає ID конверсії; передача в Meta відбувається у фоновому режимі, її статус можна перевірити через GET /v1/conversions/{id}.

Сирі дані Meta CAPI, які формує Elido, виглядають так:

{
  "data": [
    {
      "event_name": "Purchase",
      "event_time": 1747047600,
      "event_id": "ord_98231",
      "action_source": "website",
      "event_source_url": "https://shop.example.com/checkout/thanks?order=98231",
      "user_data": {
        "em": ["a3b6e2f4...sha256 of [email protected]"],
        "ph": ["c7d9f1a3...sha256 of +4915123456789"],
        "fbc": "fb.1.1747040000.AbCdEfGhIj",
        "fbp": "fb.1.1747040000.987654321",
        "client_user_agent": "Mozilla/5.0 (iPhone; CPU iPhone OS 17_4 ...)",
        "client_ip_address": "203.0.113.42"
      },
      "custom_data": {
        "currency": "EUR",
        "value": 89.5,
        "content_ids": ["sku-spring-jeans-32-blue"],
        "content_type": "product",
        "num_items": 1
      }
    }
  ],
  "access_token": "EAAxxxxxxx"
}

Поля event_source_url та action_source беруться з цільової URL-адреси запису про клік та параметра source запиту на конверсію (за замовчуванням - website). Якщо ви передаєте конверсії з додатку, вкажіть "source": "app" у тілі POST-запиту.

Дисципліна дедуплікації#

Прочитайте документацію Meta щодо дедуплікації подій (доступ від 2026-05-12) перед тим, як запускати живий трафік. Коротка версія така: Meta зіставляє події браузерного пікселя та події Meta CAPI за допомогою пари event_id + event_name протягом вікна у 48 годин. Якщо обидві події мають однакову пару, друга просто ігнорується.

Звідси випливає операційна вимога: подія Purchase вашого браузерного пікселя та серверна подія Meta CAPI повинні мати однаковий event_id. Найнадійніший вибір - це ID замовлення: обидві сторони його бачать, він стабільний і не перегенерується при повторних спробах.

Де це ламається на практиці: сервер генерує UUID у момент передачі замість використання ID замовлення. Або браузерний піксель використовує одну схему ID (ord_98231), а бекенд - іншу (order-98231). Обидві події приймаються. Жодна не дедуплікується. Кількість конверсій у звітах подвоюється. Алгоритм Meta виділяє завеликий бюджет на кампанію на основі роздутих цифр. Аналіз бюджету через три тижні показує, що «наш ROAS чомусь у 2.5 рази перевищує фактичний дохід», і наслідки цього розбору дуже неприємні.

Діаграма послідовності нижче показує, як event_id проходить через систему:

Виклик пікселя в браузері відбувається на стороні клієнта, коли завантажується сторінка підтвердження. Передача через Meta CAPI з сервера відбувається, коли спрацьовує ваш вебхук замовлення. Обидва повинні видати event_id: ord_98231 (або інший ваш ідентифікатор замовлення). Різниця в часі між ними не має значення, поки обидва надходять протягом 48 годин.

Якщо ви не використовуєте браузерний піксель (видалили його для відповідності GDPR або тому, що ваша аудиторія масово використовує блокувальники), дедуплікація не потрібна. Надсилайте дані тільки через Meta CAPI. Але більшість команд використовують обидва методи; браузерний піксель забезпечує резервний сигнал для користувачів, де події Meta CAPI не можуть містити ключі відповідності (email не отримано, fbclid відсутній).

Валідація#

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

Крок перший: встановіть код тестової події. У налаштуваннях інтеграції Meta CAPI в Elido є поле для коду тестової події. Отримайте код у Meta Events Manager у розділі Test Events. Вставте його. Поки цей код встановлено, кожна подія Meta CAPI, яку надсилає Elido, спрямовується на тестову панель - вона ніколи не потрапляє у звітність.

Крок другий: запустіть тестову конверсію. Клікніть на одне з ваших відстежуваних посилань у браузері (це зафіксує fbclid, якщо URL посилання прийшло з реклами Meta або якщо fbclid було додано вручну для тестування). Відправте POST-запитом конверсію для цього click_id з реальним ID замовлення, вартістю та адресою електронної пошти.

Крок третій: перевірте Test Events. У Meta Events Manager тестова подія має з'явитися протягом 30 секунд. Переконайтеся, що event_name збігається з тим, що надсилає ваш браузерний піксель. Перевірте, що event_id - це саме ID замовлення, а не UUID. Переконайтеся, що em, fbc або fbp з'явилися в розділі user_data - хоча б один ключ відповідності має бути присутнім.

Крок четвертий: видаліть код тестової події. Після підтвердження очистіть поле коду тестової події та збережіть. Почнуть надходити реальні події. Дашборд коефіцієнта відповідності в Events Manager оновиться змістовними даними через 24 години.

На що звернути увагу через 24 години: коефіцієнт відповідності вище 60% - це прийнятно; вище 75% - добре; вище 85% означає, що щільність ключів відповідності висока і атрибуція буде надійною. Якщо ви бачите нижче 60%, найімовірнішою причиною є відсутність fbc (fbclid не було в цільовому URL) або помилка нормалізації хешування.

Типові помилки#

Відсутній event_source_url. Події Meta CAPI без цього поля приймаються, але штрафуються в логіці зіставлення Meta. Поле має містити URL-адресу сторінки, на якій відбулася конверсія - вашу сторінку підтвердження замовлення, сторінку лід-форми або аналог у додатку. Elido бере його з цільової адреси запису про клік, якщо не вказано інше; передавайте його явно в POST-запиті конверсії, якщо ваша сторінка підтвердження відрізняється від адреси редиректу.

Хешований ключ не в нижньому регістрі або з пробілами. [email protected] та [email protected] дають різні значення SHA-256. Сервери Meta хешують канонічну форму, що зберігається в їхньому графі користувачів. Якщо ваш хеш не збігається, подія залишиться незіставленою. Вимога до нормалізації стосується і номерів телефонів: видаляйте варіанти форматування коду країни, використовуйте E.164. Передача через ендпоінт Elido /v1/conversions означає, що нормалізація виконується за вас; ви передаєте чистий email та телефон, Elido хешує їх за специфікацією.

Невідповідність action_source. Конверсії з вебу використовують "action_source": "website". Конверсії з мобільних додатків - "app". Якщо ви передаєте покупку, що відбулася у вашому додатку для iOS, але надсилаєте action_source: "website", модель атрибуції Meta може погіршити сигнал. Використовуйте "source": "app" у POST-запиті Elido для подій у додатках.

Відсутність fbc, бо fbclid не було в URL. Це стається, коли цільовий URL оголошення не містить fbclid - або тому, що в кампанії не ввімкнено «Auto-advanced matching», або тому, що URL було створено вручну без нього, або користувач прийшов через шлях ретаргетингу, який не містив цього параметра. Коли fbc відсутній, конверсія все одно передається, але коефіцієнт відповідності падає лише до email/телефону. Перевірте налаштування кампанії в Meta Ads Manager; fbclid має з'являтися в цільових URL для стандартних рекламних кампаній.

Різні схеми event_id. Браузерний піксель та подія Meta CAPI використовують різні формати для одного і того ж ID замовлення. Це майже завжди трапляється, коли різні команди відповідають за конфігурацію тегів на фронтенді та інтеграцію вебхука замовлень на бекенді. Узгодьте канонічний формат до запуску. ID замовлення як рядок (ord_98231) працює. Тільки цифри також працюють. Але якщо піксель видає "ord_98231", а сервер - "98231", вони вважатимуться різними подіями і не будуть дедупліковані.

Практичний результат#

E-commerce бренд із ЄС, що запускає рекламу Meta в Німеччині та Австрії, повідомив про 38% коефіцієнта відповідності при відстеженні лише через піксель. Safari на iOS складав приблизно 45% трафіку сайту; рівень відмови від ATT у демографічній групі 25-44 роки становив близько 72%.

Після налаштування Meta CAPI через Elido з використанням em + fbc як основних ключів відповідності, коефіцієнт відповідності зріс до 76% протягом першого тижня. Параметр fbc тепер був присутній у кожній конверсії, що походила від кліку на рекламу Meta (Elido фіксує fbclid на рівні редиректу, а не в браузері), а передача хешованого email забезпечила другий шлях зіставлення для конверсій, де термін дії кукі _fbp закінчився.

CPA знизився на 18% протягом наступних чотирьох тижнів. Показник ROAS зріс з 2.1 до 2.6. Зниження CPA на 18% відображає кращу атрибуцію, а не кращу ефективність кампанії: кампанії завжди працювали з ROAS 2.6, просто піксель занижував показники.

Місце в системі атрибуції#

Meta CAPI - це лише один канал у ширшій системі передачі даних на стороні сервера. Огляд відстеження конверсій на стороні сервера охоплює GA4 Measurement Protocol та TikTok Events API з такою ж деталізацією, як цей допис для Meta. Пояснення атрибуції без кукі варто прочитати, якщо ви хочете зрозуміти першопричини - ITP, захист від відстеження в посиланнях та зміни моделей атрибуції, що відбулися після цього.

Що стосується продукту: розділ функції відстеження конверсій описує повний API, включаючи події повернення коштів, моделі мультиканальної атрибуції та семантику повторних спроб/очікування. Рішення для маркетологів показує, як ці елементи поєднуються в робочому процесі кампанії.

Налаштування, описане вище, можна виконати за один ранок. Основна інвестиція часу - це валідація: 30 хвилин у Meta Test Events перед запуском реального трафіку. Ці 30 хвилин того варті; альтернатива - виявити неправильну конфігурацію через три дні, коли алгоритм уже почав діяти на основі хибних цифр.

Джерела

• Meta Conversions API: Getting Started. developers.facebook.com/docs/marketing-api/conversions-api/get-started/ (доступ від 2026-05-12)
• Meta Conversions API: Deduplicate Pixel and Server Events. developers.facebook.com/docs/marketing-api/conversions-api/deduplicate-pixel-and-server-events/ (доступ від 2026-05-12)
• Meta Conversions API: Customer Information Parameters. developers.facebook.com/docs/marketing-api/conversions-api/parameters/customer-information-parameters/ (доступ від 2026-05-12)