Postback ломается не в трекере, а в 5 полях, которые заполняют наугад

Postback ломается не в трекере, а в 5 полях, которые заполняют наугад

Postback — это не «галочка для галочки», а связка, по которой трекер сопоставляет клик, лид и аппрув. Если перепутать token, payout, status или sub_id, данные начинают жить отдельно от воронки. Дальше уже бессмысленно смотреть на ROI: декомпозиция профита от клика до финального аппрува разваливается на этапе интеграции.

Проверь базовую схему: — click_id должен передаваться без обрезки; — sub_id прокидываем везде одинаково, без переименований; — payout и currency фиксируем в одном формате; — статусы лида маппим строго по таблице оффера. Трафик не терпит кривых настроек postback-запросов: одна лишняя подмена параметра — и CR в отчетах начинает врать.

Отдельно смотри на дедупликацию. Если партнерка шлет повторный callback, без защиты от дублей ты получишь завышенный аппрув и псевдоположительный eCPA. Лучше сразу прописать окно уникальности по order_id или lead_id и тестировать его на тестовом потоке, а не на боевом бюджете.

Прокидываем sub_id для глубокой аналитики воронки: источник, креатив, плейсмент, оператор, устройство. Потом смотрим на EPC в разрезе сегментов и операторов, сравниваем по статусам и только после этого трогаем ставки. Алгоритм обучается на ваших данных, не мешайте ему шумом.