Postback ломается не в API, а в несогласованности трекера и источника

Postback ломается не в API, а в несогласованности трекера и источника

Разберем технический флоу: где именно мы теряем трафик на этапе postback-событий? Обычно проблема не в самом запросе, а в трех слоях: неверный callback URL, потерянный click_id и расхождение в типах конверсий между трекером и партнеркой.

Проверьте базовую схему: click_id должен создаваться на входе, прокидываться в лендинг, сохраняться в сессии и возвращаться в postback без преобразований. Если один и тот же идентификатор меняет регистр, обрезается или кодируется дважды, атрибуция разваливается. Отдельно контролируйте макросы: источник должен отдавать именно тот параметр, который ожидает трекер, а не «похожее» поле.

Дальше смотрите логи на уровне событий: accepted, lead, sale, approved, rejected. Если трекер получает только финальный статус, вы не видите, где падает воронка. Для DOI-флоу критично передавать два события: регистрация и подтверждение email; иначе CR на верификации становится невидимым, а оптимизация идет вслепую.

Последняя проверка — дедупликация. Один конверт не должен прилетать повторно из API и pixel одновременно без правил приоритета. Настройте сверку по transaction_id и тестовый прогон через sandbox или отдельную тестовую кампанию. Оптимизация — это не только креатив, но и математика удержания пользователя внутри воронки.