Facebook CAPI deduplication не дає порахувати одну реальну конверсію двічі, коли її надсилають browser Pixel і server-side Conversions API. Базовий контракт: у browser і server копій однієї події збігаються event name та event_id.
Не змішуйте чотири різні ідентифікатори:
fbclid/fbc— Meta click context;fbp— browser context;- внутрішній
click_id— візит у вашому трекері; event_id— одна conversion, доставлена двома каналами.
Що вирішує дедуплікація
| Проблема | Механізм |
|---|---|
| Pixel і CAPI надіслали один Purchase | Однакові event name і event_id |
| Network повторила postback | Stable transaction ID / tracker idempotency |
| Registration і deposit на одному click | Різні event types та IDs |
| Meta має зіставити event із рекламним кліком | fbc/fbclid, fbp та дозволені match keys |
| Tracker має знайти початковий візит | Внутрішній click ID із postback |
Поточний контракт звіряйте з офіційною документацією Meta.
Коректна пара подій
Browser Pixel:
<script>
fbq("track", "Purchase", {value: 42.50, currency: "USD"}, {
eventID: "purchase_conv_98211"
});
</script>
Server CAPI для того самого Purchase:
{
"event_name": "Purchase",
"event_time": 1786957000,
"event_id": "purchase_conv_98211",
"action_source": "website",
"custom_data": {"value": 42.50, "currency": "USD"}
}
Browser SDK використовує eventID, API payload — event_id, але значення має збігатися.
Як створювати event ID
ID має бути стабільним для повторної доставки однієї event та унікальним між різними business events. Хороший seed — transaction ID мережі:
Purchase:network_conv_98211
Якщо transaction ID немає, створіть ID один раз у джерелі події, збережіть у conversion record і повторно використайте в Pixel/CAPI. Не генеруйте два random IDs незалежно.
Не можна використовувати:
- один event ID на все життя користувача;
- campaign ID як event ID;
- незалежні timestamp-only IDs;
- один click ID для registration, deposit і всіх purchases без event scope.
Event name також має збігатися
Однаковий ID не виправить таку пару:
browser: Purchase / purchase_conv_98211
server: Lead / purchase_conv_98211
Спочатку задайте conversion registry: який raw postback status стає Lead, CompleteRegistration, Purchase або custom event. Якщо два канали навмисно надсилають різні етапи funnel, дедуплікувати їх не можна.
Роль fbclid, fbc і fbp
Ці значення допомагають Meta пов’язати server event із рекламним контактом. Вони не визначають, чи є Pixel і CAPI payloads дублікатами.
click_id → наш точний візит
fbc/fbp → Meta matching context
event_id → одна conversion в одному чи кількох каналах
tx_id → одна partner/business transaction
Докладніше — у мапі Click ID та Sub ID.
Межа postback → CAPI
В affiliate traffic deposit часто відбувається в advertiser/network. Postback спочатку має повернути подію трекеру:
https://tracker.example/postback?click_id={aff_sub}&status=deposit&payout={payout}&transaction_id={conversion_id}
Лише після перевірки click, status і transaction формуйте server event для Meta. Інакше unknown click, unmapped status або retry перетворюються на хибний рекламний signal.
Повний маршрут описано в статті як повертати affiliate conversions у Facebook, а межі систем — у Pixel vs CAPI vs postback.
Pass/fail таблиця
| Тест | Умова pass |
|---|---|
| Browser payload | Правильний event name і непорожній ID |
| Server payload | Та сама подія використовує те саме ім’я й точний ID |
| Event data | Value і currency збігаються |
| Click context | fbc/fbp присутні, якщо були легітимно captured |
| Tracker event | Server event створено з відомої conversion і click |
| Partner retry | Та сама transaction не створює другу tracker event |
| Meta diagnostics | Event прийнято без unresolved duplicate |
| Підсумок | Одна бізнес-конверсія залишилася однією Meta-конверсією |
Не приймайте роботу лише за totals в Ads Manager. Потрібна controlled event із доступними browser payload, server request, platform response і tracker conversion.
Головне правило: спочатку створіть і валідуйте одну business conversion record, потім доставляйте її в Pixel і CAPI. Обидві копії посилаються на один запис і природно отримують спільний identity.