Meta Conversions API для коротких посилань

Elido сьогодні не пересилає конверсії в Meta Conversions API. Якщо ви потрапили сюди зі списку інтеграцій і чекали перемикача, його немає, і краще сказати це одразу, ніж повести вас шляхом налаштування, що нікуди не веде. Далі йдеться про те, що Elido таки записує, чого вимагає документація Meta (дата звернення 2026-10-25) і як самостійно побудувати серверний виклик, з коротким посиланням на шляху чи без нього.

Коротко: Elido дає кліки за кожним посиланням і, для Shopify та Stripe, дохід за кожним посиланням. Meta потрібна подія з event_id, хешовані дані клієнта і, в ідеалі, ID кліку fbc. Це ви збираєте самостійно.

Що Elido робить і чого не робить для Meta сьогодні

Ось стан коду, перевірений у репозиторії 2026-10-25:

• ID пікселя Meta: робочий простір може його зберігати. Він використовується для браузерного пікселя на splash- та проміжних сторінках Elido. Це тег на стороні браузера, а не CAPI.
• Серверний виклик Meta: у конвеєрі кліків є код для Meta, який надсилав би PageView з IP та user agent. Він запускається, лише коли є і ID пікселя, і токен доступу, а налаштування токен не зберігають ніколи, тож виклик не спрацьовує.
• Конверсії: замовлення надходять лише через вебхуки Shopify і Stripe та прив'язуються до посилання за значенням elido_link_id, яке ви передаєте. Публічного ендпоінта конверсій, заголовка чи cookie з ID кліку немає.
• fbclid: Elido його не захоплює і не пересилає.

Сторінка функції відстеження конверсій описує ту саму модель вебхуків. Будь-який старіший текст, що обіцяє пересилання в Meta одним викликом, вважайте описом плану, а не продукту.

Демо-робочий простір із синтетичними прикладами даних, а не результати клієнтів.

Цей екран корисний і поруч із Meta. Дохід за кампаніями за вашими власними замовленнями перевіряє те, що заявляє Ads Manager. Два показники рідко збігаються до цента.

Як працює Conversions API від Meta

Згідно з документацією Meta Conversions API (дата звернення 2026-10-25), ви надсилаєте POST на https://graph.facebook.com/{API_VERSION}/{PIXEL_ID}/events з токеном доступу. У прикладі поточної документації використано v26.0. Кілька обмежень, які варто знати до того, як писати код:

• Один запит може містити до 1000 подій.
• event_time може бути давнішим щонайбільше на 7 днів. Якщо будь-яка подія в пакеті старша, Meta відхиляє весь запит.
• Надсилайте event_id з кожною подією. Якщо Meta бачить той самий event_id і event_name двічі, вона залишає першу копію, тому повторні спроби безпечні.

Щодо токена, посібник для початку роботи (дата звернення 2026-10-25) радить згенерувати його в Events Manager: оберіть піксель, відкрийте Settings і натисніть "Generate access token" у розділі Conversions API. Це посилання бачать лише користувачі з правами розробника для бізнесу. Тримайте токен у серверному секреті.

Побудуйте самостійно, крок за кроком

Кроки однакові, чи клік прийшов із короткого посилання, QR-коду, чи з прямої реклами.

1. Збережіть ID кліку. Посібник Meta про fbp і fbc (дата звернення 2026-10-25) радить читати fbclid з посадкового URL на сервері, якщо він є, і форматувати його як fb.1.<час створення в мс>.<fbclid>. Збережіть це як значення fbc разом із сесією відвідувача, а потім скопіюйте його в замовлення. Збережіть також значення cookie _fbp, якщо його встановив піксель.
2. Оберіть ID події. Використайте ID замовлення і той самий рядок у виклику браузерного пікселя (eventID) та серверній події (event_id). Два різні формати для одного замовлення, як-от ord_98231 і 98231, не пройдуть дедуплікацію.
3. Нормалізуйте й хешуйте. За параметрами інформації про клієнта (дата звернення 2026-10-25), пошту обрізають по краях і переводять у нижній регістр, потім хешують SHA-256. З телефонів прибирають символи, літери та початкові нулі, а перед хешуванням вони мають містити код країни. fbc, fbp і client_ip_address ніколи не хешуються.
4. Надішліть подію, коли замовлення оплачено, зі свого бекенда або обробника вебхука замовлень.
5. Перевірте в Test Events, потім приберіть тестовий код.

Мінімальний приклад на Node:

import { createHash } from "node:crypto";

const sha256 = (v) => createHash("sha256").update(v).digest("hex");

const event = {
  event_name: "Purchase",
  event_time: Math.floor(Date.now() / 1000),
  event_id: order.id, // same string the browser pixel uses as eventID
  action_source: "website",
  event_source_url: order.thankYouUrl,
  user_data: {
    em: [sha256(order.email.trim().toLowerCase())],
    fbc: order.fbc,
    fbp: order.fbp,
    client_ip_address: order.ip,
    client_user_agent: order.userAgent,
  },
  custom_data: { currency: "EUR", value: 89.5 },
};

await fetch(
  `https://graph.facebook.com/v26.0/${PIXEL_ID}/events?access_token=${TOKEN}`,
  {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ data: [event] }),
  },
);

Додайте test_event_code до тіла запиту на час тестування. Не логуйте повний URL у продакшені, бо в ньому є токен.

Дедуплікація і Test Events: дві пастки

Посібник Meta з дедуплікації (дата звернення 2026-10-25) описує зіставлення за event_id разом із event_name: eventID пікселя порівнюється з event_id сервера в межах 48 годин. Там сказано, що це працює здебільшого тоді, коли першою приходить подія з браузера, а за нею серверна. Також сказано, що дедуплікації немає взагалі, якщо ви використовуєте лише одне джерело.

В інструменті Test Events є пастка. test_event_code призначений лише для тестування, але на сторінці про використання API Meta зазначає, що події з ним не відкидаються: вони потрапляють в Events Manager і використовуються для таргетингу та вимірювання. Тож "нешкідлива" тестова покупка на 500 EUR усе одно враховується. Надішліть кілька невеликих тестових подій і приберіть код із продакшн-запиту.

Після початку надсилання, за словами Meta, перевірити події можна приблизно за 20 хвилин в огляді Events Manager. Переконайтеся, що назва події збігається з тією, яку надсилає піксель, і що подія показує зіставлені дані користувача.

Де тут коротке посилання

Коротке посилання не змінює того, як працює CAPI. Воно важливе у двох місцях, і лише у двох.

Перше - ID кліку. Meta додає fbclid до адреси призначення, яку ви вказали в рекламі. Якщо це коротке посилання, параметр приходить саме на нього. У шляху редиректу Elido я не знайшов коду, що переносить вхідний рядок запиту на адресу призначення. Тому для реклами Meta я б спрямовував оголошення на кінцевий посадковий URL з UTM, а короткі посилання лишив для email, SMS, QR-кодів і органічних дописів. Якщо ж коротке посилання в рекламі потрібне, спершу перевірте його з тестовим ?fbclid=test і подивіться, що отримає ваша посадкова сторінка.

Друге - звітність. Позначайте оформлення замовлення Shopify чи Stripe значенням elido_link_id. Тоді звіт конверсій Elido показує дохід за посиланнями й кампаніями за вашими власними замовленнями. Про сторону вебхуків розповідає покрокова інструкція для Shopify. Ширшу картину того, чому підрахунок лише в браузері губить події, дивіться в серверному відстеженні конверсій і поясненні атрибуції без cookie.

Згода та приватність

Хешування - це не анонімізація. SHA-256-хеш адреси електронної пошти все одно є персональними даними за GDPR, бо Meta може зіставити його зі своїми записами. У ЄС потрібна правова підстава, для вимірювання реклами це зазвичай згода, і серверний виклик має поважати той самий вибір, який відвідувач зробив у вашому банері. Питання згоди й передавання даних розглянуто в матеріалах про Consent Mode v2 для відстеження та Schrems II і пікселі відстеження. Якщо відвідувач відмовився, не надсилайте нічого.

Чого бракує в Elido

Пересилання покупок у Meta одним викликом, захоплення fbclid на редиректі та поле токена доступу в налаштуваннях Meta - усе це ще не створено. Вони враховані в беклозі продукту, і цей текст зміниться, коли їх випустять. До того чесне налаштування таке, як вище: ваш сервер надсилає подію, а Elido постачає навколо неї дані про кліки й дохід на рівні посилань.

Читайте також у блозі

• Серверне відстеження конверсій
• ID кліків: gclid і fbclid
• Відстежуйте UTM наскрізно
• Ретаргетинг через посилання: пояснення
• Скорочувач URL для Shopify