Надёжный S2S-постбэк строится не на “настройках”, а на дисциплине передачи данных

Надёжный S2S-постбэк строится не на “настройках”, а на дисциплине передачи данных

Если цепочка оффер → трекер → партнерка собрана криво, вы теряете атрибуцию, ловите дубли и не понимаете, где ломается воронка. База простая: один click_id на клик, один conversion_id на конверсию, единый формат передачи параметров. Любой лишний редирект или ручная подмена полей — это уже источник расхождений.

Проверяйте 4 узла:
— трекер генерирует уникальный ID до отправки трафика;
— оффер/ленд сохраняет этот ID в cookie, localStorage или hidden field;
— партнерка возвращает postback по серверному каналу без участия браузера;
— трекер принимает событие и сопоставляет его с исходным кликом по ключу, а не по IP или User-Agent.

Слабые места почти всегда одни и те же: потеря параметра в редиректе, несовпадение названий макросов, дубли postback’ов, отсутствие дедупликации по conversion_id. Если есть несколько источников трафика, разделяйте их по subID и не смешивайте в одном payload. Для логов держите отдельный endpoint и фиксируйте статус ответа: 200 не значит, что событие корректно сматчилось.

Перед запуском делайте тестовый клик и тестовую конверсию на каждом связующем сегменте: трекер → лендинг → оффер → партнерка → postback → трекер. Чистим логи, проверяем постбэки. Data-driven подход или работа вслепую — выбор за тобой.