Постбек може повернути 200 OK і не створити конверсію. Він може з’явитися в трекері, але не дійти до рекламної платформи. А повторний callback інколи виглядає як ще один продаж, хоча це лише retry партнерської мережі.
Тому питання «чи прийшов постбек» надто загальне. Перевіряйте чотири незалежні шари: доставку запиту, пошук кліку, інтерпретацію події та запис результату. Цей порядок знаходить точну межу збою.
Для ролей параметрів відкрийте гайд про Click ID, Sub ID і макроси, а для контрольного callback використайте Postback URL Builder.
Як виглядає справний ланцюжок
- Трекер створює унікальний внутрішній click ID.
- ID передається в офер через погоджене sub-поле.
- Партнерська система зберігає значення без змін.
- Під час конверсії вона розкриває свій postback-макрос.
- Трекер знаходить початковий клік і нормалізує статус.
- Стабільний transaction ID не дає retry подвоїти виручку.
- Потрібна подія надсилається в Meta, TikTok або іншу платформу.
Pass/fail-чекліст
| Ділянка | Очікування | Доказ | Pass? |
|---|---|---|---|
| Вхідний клік | Створено один унікальний click ID | Raw click record | ☐ |
| URL офера | ID потрапив у потрібне sub-поле | Фінальний URL після redirect | ☐ |
| Зберігання | Мережа зберегла значення побайтно | Click/conversion log | ☐ |
| Callback URL | Макроси розкриті, дужок немає | Сирий URL запиту | ☐ |
| HTTP | Запит дійшов до правильного endpoint | Код, час, response body | ☐ |
| Пошук кліку | Трекер знайшов початковий ID | Ingress result | ☐ |
| Статус | Сире значення стало потрібною подією | Таблиця мапінгу | ☐ |
| Гроші | Payout і currency мають узгоджений зміст | Запис мережі | ☐ |
| Dedup | Повтор не додає конверсію | Повторіть той самий transaction | ☐ |
| Feedback | Платформа прийняла правильну подію | CAPI/Events API log | ☐ |
1. Зафіксуйте один контрольний клік
Не діагностуйте на тисячах live-переходів. Створіть один клік і запишіть точний час із timezone, internal click ID, campaign, stream, offer, повний outbound URL і поле мережі для ID.
Click ID — непрозорий рядок. Не обрізайте його, не переводьте в число, не змінюйте регістр і не збирайте заново.
2. Перевірте передачу вперед
Якщо мережа приймає довільне значення в aff_sub:
https://network.example/offer?aff_sub={click_id}після redirect має бути реальне значення:
https://network.example/offer?aff_sub=dc_01K2A7M9X4Літеральні {click_id} або %7Bclick_id%7D означають, що макрос не розкрився. Якщо ID зникає на проміжному redirect, спочатку виправте forward-path.
3. Аналізуйте сирий callback
Збережений шаблон не доводить, який запит реально відправила мережа. Порівняйте шаблон:
https://track.example/p?click_id={aff_sub}&status={status}&payout={payout}із фактичним запитом:
https://track.example/p?click_id=dc_01K2A7M9X4&status=dep&payout=45.00&txid=7719Переконайтеся, що макроси розкриті, click ID збігається, символи URL-encoded, а endpoint належить потрібному workspace. Діагностичний гайд Adset також виділяє сирі макроси, змінений ID, неправильні статуси й авторизацію як типові причини.
4. 200 OK не дорівнює записаній конверсії
HTTP success доводить лише транспорт. Endpoint може так само відповісти на невідомий click ID, дубль або пропущений статус. У журналі потрібен результат на кшталт accepted, duplicate, click_not_found, status_unmapped, invalid_payout або unauthorized.
Якщо raw log немає, використайте request catcher лише для контрольного тесту. Не передавайте туди production-токени чи персональні дані.
5. Мапте статус окремо
Знайдений клік ще не означає правильну бізнес-подію:
| Сирий статус | Внутрішній статус | Відправляти в платформу? | Revenue? |
|---|---|---|---|
reg | Registration | За policy оптимізації | Ні |
dep | First deposit | Так | Так |
approved | Approved | Не дублювати purchase | Так |
rejected | Rejected | Ні або correction | Ні |
DarkCore керує цим у Conversion Statuses. Не зводьте реєстрацію і депозит до одного Lead.
6. Перевірте payout і correction
payout=45 може означати комісію, дохід рекламодавця або суму замовлення. Узгодьте семантику, передавайте currency окремо й перевірте десятковий роздільник. Зміна статусу або суми має оновити ту саму транзакцію, а не створити новий sale.
7. Проведіть duplicate test
Відправте ідентичний callback двічі. Перший має створити подію, другий — отримати результат duplicate. Кількість конверсій, revenue і downstream feedback не повинні зрости.
Dedup робіть за transaction ID плюс тип події. Один click ID недостатній, якщо клік може дати registration, FTD і repeat deposit.
8. Трекер бачить, а Meta або TikTok — ні
Перевірте policy відправки статусу, збереження fbclid/fbc чи ttclid, access token, відповідь API та спільний event_id для Browser Pixel і серверної копії. Ролі каналів розібрані в Pixel vs CAPI vs Postback. TikTok офіційно описує TTCLID як параметр landing URL для атрибуції та вимірювання (TikTok Ads Help).
Симптоми
| Симптом | Що перевіряти першим |
|---|---|
У запиті залишилися {...} | Точний синтаксис макроса відправника |
click_not_found | Forward-поле і значення click ID |
| Є registration, немає deposit | Окремий callback і dep/ftd mapping |
| Revenue подвоюється | Transaction ID та idempotency |
| Трекер бачить, Meta ні | Platform ID, token, policy, API log |
| Meta показує більше | Вікно, modeling і Pixel+CAPI dedup |
FAQ
Чому ручний postback працює, а реальний — ні?
Ручний тест часто має правильно підставлений ID, а production-шаблон надсилає порожнє значення або буквальний макрос. Порівняйте сирі URL побайтно.
Чи можна тестувати через браузер?
Можна перевірити доступність GET-endpoint. Браузер не доводить, що мережа розкриває макроси, додає авторизацію і виконує retry policy.
Коли проблему закрито?
Після end-to-end тесту: контрольний клік → офер → перший callback → точний повтор → зміна статусу/суми → platform feedback. Результатом має бути заповнена pass/fail-таблиця.