Postback ломается не в API, а в несогласованности параметров между трекером и сетью

Postback ломается не в API, а в несогласованности параметров между трекером и сетью

Разберем технический флоу: где именно мы теряем трафик на этапе postback-событий? Чаще всего ошибка не в самом запросе, а в трех точках:
— разные названия идентификаторов click_id/sub_id;
— несовпадение типа события lead/sale/approve;
— отсутствие дедупликации, из-за чего один и тот же конверт улетает дважды.

Перед интеграцией проверьте, что трекер и офферная сеть одинаково трактуют источник клика. Если сеть шлет Postback только на подтвержденный лид, а трекер ждет событие сразу после сабмита, отчеты начнут врать уже на первом этапе. Для SOI и DOI это критично: один и тот же lead может быть принят, но не подтвержден, и без корректной карты статусов вы не увидите реальный DOI rate 📊

Отдельно настройте передачу макросов: click_id, payout, currency, status. Если хотя бы один параметр теряется по пути, аналитика становится неполной, а оптимизация — бессмысленной. Логируйте тестовые запросы и сверяйте ответ сервера не по “успешно”, а по факту записи события в трекере.

Практика простая: сначала делайте одну связку “клик → сабмит → постбек → отчет”, и только потом масштабируйте на новые источники. Оптимизация — это не только креатив, но и математика удержания пользователя внутри воронки.