Якщо Meta Ads показує 127 покупок, а трекер — 103, це ще не доводить поломку. Системи можуть рахувати різні події, використовувати різні attribution windows, timezone та дати звіту. Але пояснення «Meta моделює» теж недостатнє: розбіжність треба розкласти на вимірювані причини.
Мета reconciliation — не змусити два інтерфейси показати однаковий total, а зв’язати platform-attributed event, отриманий callback і підтверджену бізнес-транзакцію.
Спочатку визначте, що порівнюєте
Зафіксуйте event semantics, період, timezone, click-time чи conversion-time, attribution window, click/view-through правила, modeled events, raw/pending/approved status, зміст value та account/campaign/GEO/device filters.
Карта причин
| Причина | Зазвичай більше в Meta | Зазвичай більше в трекері | Як довести |
|---|---|---|---|
| View-through/modeling | ✓ | Attribution breakdown | |
| Різні вікна | ✓/— | ✓/— | Один cohort і window |
| Різні timezone | ✓/— | ✓/— | Перерахунок у UTC |
| Pixel + CAPI без dedup | ✓ | Звірити event_id | |
Втрачено fbclid/fbc | ✓ | Click record і CAPI payload | |
| Не прийшов postback | ✓ | CRM order є, callback немає | |
| Різні status filters | ✓/— | ✓/— | Raw → canonical mapping |
| Organic/direct | ✓ | Немає paid click ID | |
| Пізній reject/refund | ✓ | Історія статусів | |
| Duplicate callback | ✓ | Transaction ID і duplicate log |
1. Вирівняйте час
Депозит о 23:30 UTC може потрапити в різні календарні дні. Експортуйте timestamps, приведіть до UTC і збережіть original timezone. Перевірте й дату групування: Meta може віднести конверсію до дня рекламної взаємодії, а CRM — до дня транзакції.
2. Порівнюйте однакову атрибуцію
Трекер зазвичай має детермінований click ID. Платформа може додавати власні click/view windows і modeled signals. Почніть зі строгого спільного шару: обидві системи бачили paid click, подія всередині однакового вікна, event type/status збігаються, organic і test traffic виключені.
Тримайте окремі поля tracker_attributed, meta_attributed, business_confirmed.
3. Перевірте fbclid → fbc → CAPI
Збережіть Meta click context через landing, PWA та offer redirect. Паралельно зберігайте internal click ID для власного postback. Якщо fbclid губиться, трекер може отримати депозит, але Meta матиме слабший match. Ролі описані в Click ID, Sub ID, fbclid, fbc і ttclid.
4. Перевірте Pixel + CAPI dedup
Одна purchase часто надсилається Browser Pixel і Conversions API. Обидві копії мають описувати ту саму подію й мати узгоджений event_id.
Типові помилки: різні IDs у browser/server, один ID для всіх покупок, новий ID на кожен retry, різні event names або повторний Purchase після approve. Перевіряйте Events Manager і власний delivery log; queued ще не означає accepted. Детальніше — Pixel vs CAPI vs Postback і офіційна довідка Meta CAPI.
5. Звірте семантику статусів
Мережа може надсилати registration, deposit, approved, rejected. Якщо Meta отримує Purchase на FTD, а tracker report фільтрує лише approved після hold, Meta закономірно буде вищою до maturation.
| Raw event | Internal status | Meta event | Revenue |
|---|---|---|---|
reg | Registration | Lead | 0 |
ftd | First deposit | Purchase | payout/value |
approved | Approved | Не дублювати Purchase | confirmed |
rejected | Rejected | Policy-dependent correction | 0 |
Мапінг залежить від бізнесу, але має бути явним і versioned.
6. Розділіть втрату callback і platform feedback
Network/CRM → postback → tracker → CAPI → Meta- Order є в CRM, але немає в трекері: postback, click ID, статус.
- Подія є в трекері, але немає в Meta: policy, payload, token,
fbc/fbp, event ID, API response. - Meta бачить подію, яку CRM пізніше відхилила: потрібна історія статусів, а не видалення факту.
Для першої межі використайте чекліст діагностики постбека.
7. Відрізніть duplicate від repeat purchase
| click_id | transaction_id | event | Результат |
|---|---|---|---|
c101 | tx900 | purchase | accepted |
c101 | tx900 | purchase | duplicate |
c101 | tx901 | purchase | accepted |
Dedup лише за click ID видалить справжню tx901; відсутність dedup подвоїть tx900.
Transaction-level reconciliation
З’єднайте matured cohort за transaction ID:
| transaction_id | click_id | event_at UTC | tracker status | Meta accepted | business status | value |
|---|---|---|---|---|---|---|
tx900 | c101 | 12:04 | FTD | yes | approved | 45 |
tx901 | c102 | 12:11 | FTD | no | approved | 30 |
tx902 | — | 12:19 | — | modeled/unknown | approved | 55 |
Призначте кожному mismatch reason code: TIMEZONE_SHIFT, WINDOW_MISMATCH, CLICK_ID_LOST, POSTBACK_MISSING, STATUS_FILTERED, CAPI_REJECTED, PIXEL_CAPI_DUPLICATE, ORGANIC_OR_UNATTRIBUTED, MODELED_PLATFORM_EVENT, BUSINESS_REJECTED.
Тоді gap стає розподілом причин, які можна пріоритезувати.
Надійний порядок звірки
- Беріть cohort, де hold уже переважно завершений.
- Зафіксуйте report settings.
- Обмежте один account/GEO/campaign cohort.
- Порівнюйте transaction-level export, не лише totals.
- Події без deterministic match рахуйте окремо.
- Не додавайте modeled events у confirmed CRM revenue.
- Перевіряйте fix на новому cohort.
FAQ
Який відсоток розбіжності нормальний?
Універсальної межі немає. Навіть малий gap може бути системною втратою дорогого GEO. Оцінюйте reason codes і бізнес-вплив.
Кому вірити?
Meta відповідає за власну attribution та optimization, трекер — за детермінований маршрут кліку, CRM/payment system — за факт і фінальний статус транзакції. Звірка пов’язує всі три шари.
Чому після CAPI стало більше конверсій?
Це може бути кращий matching або Pixel+CAPI duplicates. Перевірте event IDs, transaction mapping і Events Manager response до висновку про uplift.
Підсумок
Починайте з data contract: один click record, один transaction ID, явний status mapping і журнал доставки в Meta. DarkCore Analytics та Finance пов’язують source context із підтвердженою виручкою та дають export для повторної перевірки.