Postback без ошибок: как не терять конверсии между TDS, CPA и CRM

Postback без ошибок: как не терять конверсии между TDS, CPA и CRM

Postback — это не «галочка в трекере», а цепочка, где любой сбой ломает атрибуцию. Если в URL потерян sub_id, не совпадает token или источник шлёт событие не в тот статус, вы видите ложный CR и мусорный EPC.

Проверяйте базу:
— один и тот же click_id должен проходить от источника до партнёрки без изменений;
— статусы должны быть согласованы: lead, approve, reject, hold;
— payout и currency лучше передавать явно, чтобы не считать профит по фантазии.

Дальше смотрим на технику запроса. Трафик не терпит кривых настроек postback-запросов: кодировка, обязательные параметры, GET/POST, дублирование событий. Если postback может прилететь повторно, ставьте дедупликацию по conversion_id, иначе алгоритм обучается на шуме, а не на факте продажи.

Для глубокой аналитики прокидываем sub_id на каждом уровне: источник, кампания, крео, плейсмент, оператор. Тогда можно разложить декомпозицию профита: от клика до финального аппрува и увидеть, где проседает воронка. Смотрим на EPC в разрезе сегментов и операторов — именно там всплывают скрытые потери.

Если нет жёсткой проверки связки click_id → postback → status → payout, любые сплиты бесполезны. Сплит-тест — единственный объективный судья в арбитраже, но он работает только на чистых данных.