Як трекати конверсії Facebook-реклами для партнерських офферів

Медіабаєр, який заливає гемблінг-оффер в LATAM, у понеділок вранці відкриває Ads Manager: за вихідні залоговано 40 покупок. Його CRM, яку живлять постбеки партнерської мережі, показує 71 депозит по тій самій кампанії за той самий період. Ніхто не «вкрав» 31 конверсію — Facebook їх просто не побачив. Депозит стався через два дні після кліка, на домені рекламодавця, у сесії, де піксель Meta взагалі не вантажився. Якщо ви намагаєтесь трекати конверсії Facebook-реклами для партнерських офферів і цифри не сходяться — причина майже завжди саме в цьому, і виправляється це правильним нашаруванням сигналу, а не збільшенням бюджету.

Чому Facebook занижує конверсії партнерських офферів

Стандартний Facebook Pixel побудований на припущенні «той самий домен, та сама сесія»: юзер клікає на рекламу, потрапляє на ваш сайт, конвертиться на вашому сайті, піксель спрацьовує на вашому сайті. Афіліат-воронки ламають кожну ланку цього ланцюга. Клік відбувається на вашому преленді або трекінговому домені з фільтрацією трафіку, піксель (якщо він там є) спрацьовує там же, а потім юзера редіректить на домен рекламодавця — казино, дейтинг-платформу, брокера — де і відбувається реальна конверсійна подія (депозит, FTD, підтверджена реєстрація) без жодного трекінгу Meta. У Facebook немає жодного коду на чекауті рекламодавця, у формі депозиту чи в KYC-флоу, тож структурно він не може побачити подію, яка насправді для вас важлива.

Додайте до цього стандартну деградацію браузерного трекінгу, з якою всі й так борються: Safari ITP обрізає час життя кук, адблокери прибивають запити пікселя нахабно, юзери конвертяться з іншого девайсу, ніж той, з якого клікнули. За галузевими оцінками, втрата браузерного сигналу зазвичай складає 10–40% залежно від ГЕО та вертикалі — і це до того, як врахувати крос-доменний розрив, специфічний саме для афіліат-моделі. Складіть обидві проблеми — і цілком типова картина, коли конверсії, задекларовані Facebook, становлять половину або менше від того, що реально зафіксувала ваша CRM.

Наслідок — це не просто незручність у звітності. Алгоритм Facebook оптимізується під той сигнал, який отримує. Якщо він бачить лише 40 з 71 депозиту, він оптимізує ваш бюджет під ту аудиторію, яка принесла саме ці 40 — а це може бути зовсім не ваш найкращий за конверсією сегмент. У підсумку ви платите за масштабування неправильних lookalike-аудиторій, поки ваш реальний трафік з найвищим LTV не отримує жодного алгоритмічного визнання.

Три рівні трекінгу, які вам потрібні

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

Браузерний піксель — дешевий, швидкий, корисний для сигналів на ранніх етапах воронки на кшталт переглядів лендінгу, але сліпий до всього, що відбувається після редіректу, і ненадійний навіть у тому, що технічно може побачити.
Conversions API (CAPI) — надсилає ті самі стандартні події сервер-сервер, відновлюючи заблоковані браузером події для сигналів, які ваш власний домен ще здатен побачити (перегляд сторінки, сабміт лід-форми, початкова реєстрація).
S2S-постбек — спрацьовує напряму з вашого бекенду чи CRM у момент, коли реально змінюється статус далі по воронці, незалежно від будь-якої браузерної сесії, куки чи меж домену. Це єдиний рівень, здатний побачити депозит, який стався через два дні на чужому домені.

CAPI і постбек вирішують різні половини проблеми. CAPI відновлює події, які ваш власний трекінговий домен міг би побачити, але браузер їх втратив. Постбек звітує про події, при яких ваш трекінговий домен взагалі не був присутній, бо вони сталися далі по воронці, у системі рекламодавця. Саме для арбітражу трафіку постбек закриває розрив, який реально коштує вам грошей — депозити, FTD, підтверджені акаунти, — тоді як CAPI прибирає шум навколо стандартних подій.

Якщо хочете глибше розібратися в механіці того, як кожен рівень поводиться під тиском адблокерів і обмежень на куки, дивіться Pixel проти Conversions API проти S2S Postback.

Побудова ланцюга сигналу: від click_id до конверсійної події

Механізм, який зв’язує всі три рівні докупи, — це єдиний стійкий ідентифікатор, який виживає впродовж усього шляху: клік, редірект, домен рекламодавця, конверсія і повернення до Facebook. Ось цей шлях:

Клік потрапляє на ваш трекінговий домен. Ваш трекер генерує click_id (або еквівалент, похідний від fbclid) і логує клік з кампанією, групою оголошень, оголошенням та будь-якими сабпараметрами, потрібними для сегментації.
click_id передається рекламодавцю. Він їде як URL-параметр через увесь ланцюг редіректів до лендінгу оффера, а потім переноситься крізь їхній флоу реєстрації/депозиту — зазвичай через приховане поле, subid-параметр чи афіліат-токен трекінгу, який система рекламодавця вже підтримує.
Рекламодавець стріляє постбеком при конверсії. У момент, коли депозит проходить або лід кваліфікується, бекенд рекламодавця викликає ваш postback URL з click_id і статусом.
Ваш трекер зіставляє click_id з початковим кліком, відновлюючи повний ланцюг атрибуції: яке оголошення, який креатив, яке ГЕО, який плейсмент реально принесли цей депозит.
Facebook отримує подію CAPI, позначену тим самим event_id, що використовується для дедапу, і несе будь-який сигнал ідентифікації, який у вас є (хешований email, external ID, fbc/fbp на момент кліку, якщо їх зафіксовано), щоб механізм зіставлення Meta зміг прив’язати її назад до початкового показу реклами.

Приклад postback URL з макросами, які ваш трекер очікує заповненими системою рекламодавця:

https://track.yourdomain.com/postback?click_id={click_id}&status=deposit&payout={payout}&currency={currency}&event_id={click_id}_deposit

А ось CAPI payload, який ваш бекенд надсилає одразу після приходу постбека, використовуючи той самий event_id для дедапу проти всього, що ще може вистрелити браузерний піксель:

{
  "data": [
    {
      "event_name": "Purchase",
      "event_time": 1751980800,
      "event_id": "abc123click_deposit",
      "action_source": "website",
      "user_data": {
        "em": "9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08",
        "external_id": "abc123click"
      },
      "custom_data": {
        "currency": "USD",
        "value": 45.00
      }
    }
  ]
}

Саме event_id запобігає подвійному підрахунку, якщо браузерний піксель також встиг зловити легший сигнал раніше в тій самій сесії — Facebook дедапить будь-яку подію з однаковим ID між надсиланнями пікселя і CAPI.

Мапінг статусів конверсії на події Facebook

У партнерських вертикалях рідко буває одна конверсія — там є ціла воронка статусів, і кожен з них може або не може заслуговувати на те, щоб потрапити до Facebook як окрема оптимізаційна подія. Реєстрація — це не депозит, а депозит — це не ребіл. Надсилання всіх їх у Facebook як загальних подій Purchase знищує здатність алгоритму відрізнити лід за $2 від FTD за $200.

Статус воронки	Типова подія Facebook	Надсилати у Facebook?
Перегляд лендінгу	`PageView`	Опційно — низька цінність, великий обсяг
Сабміт форми / реєстрація	`Lead` або `CompleteRegistration`	Так — ранній сигнал для оптимізації
Перший депозит (FTD)	`Purchase`	Так — основна ціль оптимізації
Ребіл / повторний депозит	Кастомна подія, напр. `Rebill`	Іноді — корисно для біддингу з урахуванням LTV, але не змішуйте з FTD
Чарджбек / рефанд	Не надсилається, або звіряється лише через CRM	Ні — у Facebook немає нативного флоу для негативних подій

Цей мапінг має жити як конфігурація, а не як код — кожен новий статус, який вводить ваша вертикаль (статус KYC-verified, віха другого депозиту), повинен призначатися на назву події Facebook без тікета інженеру. Саме цей розрив закриває налаштування пікселів DarkCore: мапінг подій налаштовується по статусу, по пікселю, тож deposit може мапитися на Purchase для одного оффера і на кастомну подію для іншого — без правок постбек-темплейту щоразу, коли запускається нова вертикаль.

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

Надсилання кожного статусу постбека як Purchase. Це зводить реєстрації, депозити й ребіли в один сигнал, що ламає здатність Facebook оптимізуватися саме на цінних юзерів. У підсумку алгоритм женеться за обсягом замість якості депозитів.
Пропуск дедапу event_id між пікселем і CAPI. Без спільного event ID та сама конверсія рахується двічі — раз від того, який сигнал вистрелив у браузері, і раз від серверної події — це роздуває звітні конверсії й непомітно спотворює математику ROAS.
Втрата click_id при редіректі на домен рекламодавця. Якщо партнерська мережа чи рекламодавець не переносять надійно ваш ідентифікатор кліку крізь власний флоу реєстрації/депозиту, то постбек, який зрештою прилетить, немає з чим зіставити, і конверсія лишається без атрибуції, хоча технічно ваш бекенд її отримав.
Сприйняття CAPI як заміни постбеку. CAPI відновлює лише події, при яких був присутній ваш власний домен. Він не може відзвітувати про депозит, який стався повністю всередині системи рекламодавця через кілька днів — цей розрив закривається лише реальним S2S-постбеком від рекламодавця чи мережі.
Надсилання подій CAPI без урахування затримки. Депозит, який стався через 3 дні після кліку, все одно повинен атрибутуватися до початкового показу реклами. Якщо ваша логіка таймстемпа події чи вікна атрибуції припускає конверсію в тій самій сесії, Facebook може відхилити подію як низькоякісну або взагалі не зіставити її з початковим кліком.

Налаштування структури рекламного кабінету під відкладений сигнал

Коли ланцюг постбек-CAPI вже запущений, виникає проблема другого порядку: структура вашого рекламного кабінету повинна витримувати затримку між витратами і підтвердженим сигналом. Якщо депозити приходять через 2-5 днів після кліку, кампанії, оптимізовані на однодобове вікно атрибуції, завжди виглядатимуть гірше, ніж є насправді, а автоматичні правила Facebook — які бачать тільки піксельні дані на стороні FB — можуть поставити на паузу чи притримати кампанію, яка насправді добре працює за вашою CRM.

Практичні коригування:

Встановлюйте вікна атрибуції в Ads Manager відповідно до вашого реального медіанного часу до депозиту, а не дефолту платформи.
Не дозволяйте власним автоматичним правилам Facebook приймати бюджетні рішення тільки на основі піксельних даних, якщо ваша реальна конверсійна подія знаходиться глибоко у воронці й затримується — ці правила не бачать того, що вже підтвердила ваша CRM.
Тримайте достатньо історичних витрат у кожній групі оголошень перед тим, як оцінювати результативність; кампанія, яка виглядає холодною в перший день, бо депозити ще не зайшли, може виглядати геть інакше на четвертий день, коли постбеки наздоженуть.

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

Як перевірити, що налаштування реально працює

Перш ніж довіряти цифрам, перевірте кожну ланку ланцюга окремо:

Зробіть тестовий клік через свій трекінговий лінк і переконайтесь, що click_id залогований з правильними ID кампанії/групи оголошень/оголошення.
Вручну ініціюйте (або дочекайтеся) тестовий постбек від рекламодавця/мережі та перевірте, що ваш трекер зіставляє його з початковим кліком, а не з випадковою чи незіставленою конверсією.
Перевірте Events Manager Facebook на предмет відповідної події CAPI — переконайтесь, що назва події, значення й event_id прийшли як очікувалося, і що якість зіставлення (покриття email/external ID) не позначена як низька.
Порівняйте задекларовані Ads Manager конверсії за певний день з підтвердженими конверсіями вашої CRM для тієї самої когорти кількома днями пізніше, коли відкладені події встигнуть зайти. Стійкий великий розрив після цього вікна означає, що якась ланка ланцюга — зазвичай передача click_id — досі зламана.

Часті запитання

Чи замінює CAPI Facebook Pixel повністю?

Ні. CAPI призначений працювати паралельно з пікселем, із дедапом на основі event_id, щоб перекривні події не рахувались двічі. Піксель усе ще цінний для дешевих, високооб’ємних сигналів на ранніх етапах воронки; завдання CAPI — відновлювати те, що втрачає браузер, а не заміняти браузерний рівень.

Чи можу я надсилати події депозиту у Facebook, якщо рекламодавець не підтримує S2S-постбек?

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

Яким має бути вікно атрибуції Facebook для партнерських офферів з відкладеними депозитами?

Встановіть його так, щоб покривати ваш реальний медіанний час до депозиту, який можна взяти прямо з таймстемпів «клік-конверсія» вашого трекера. Однодобове вікно кліку на оффері, де депозити зазвичай приходять на 2-3 день, систематично недоатрибутовуватиме — незалежно від того, наскільки добре налаштовані ваші CAPI й постбек.

Які мінімальні дані ідентифікації потрібні CAPI, щоб добре зіставити подію?

Як мінімум — хешований email або external ID, прив’язаний до початкового кліку. Додавання IP, user agent і браузерних ID fbc/fbp, зафіксованих на момент кліку (якщо у вас взагалі була якась браузерна присутність), суттєво покращує рівень зіставлення, особливо для подій, які спрацьовують через кілька днів після завершення початкової сесії.

Як повернути собі повну картину

Усе це не потребує екзотичної інфраструктури — потрібно лише прийняти, що дашборд Facebook ніколи не побачив би вашу повну воронку самостійно, бо конверсія, яка приносить вам гроші, відбувається там, куди піксель Facebook ніколи не запрошували. Постбек відновлює подію, CAPI повертає її в Meta зі збереженим дедапом, а мапінг статусів тримає алгоритм в оптимізації саме на ті депозити, які реально важливі, замість зведеної загальної «purchase». Стрім і налаштування пікселя DarkCore обробляють цей ланцюг за замовчуванням — передача click_id, роутинг постбеків по статусах і дедап CAPI зшиті разом, а не вручну. Якщо цифри вашого Ads Manager і CRM давно не сходяться, варто спершу перевірити ланцюг, а вже потім бюджет — пишіть нам у Telegram.