Postback ломается не в оффере, а в 3 местах трекинговой цепочки

Postback ломается не в оффере, а в 3 местах трекинговой цепочки

Postback — это не «поставил и забыл», а связка: клик → sub_id → конверсия → callback в TDS. Если хоть один идентификатор теряется по пути, атрибуция расползается, EPC становится шумом, а оптимизация опирается на фантомные лиды.

Базовая схема простая: на клик прокидываем уникальный click_id, в оффере сохраняем его в hidden-поле или параметре, а в postback возвращаем в том же формате. Имена параметров должны совпадать символ в символ: cap_id, sub_id, txid — не «примерно похоже», а один и тот же ключ на всех этапах.

Дальше проверяем источники потерь:
— редиректы режут параметры при кривой склейке URL;
— оператор или сеть может отправлять postback только при финальном аппруве, а не на всех статусах;
— TDS иногда принимает запрос, но не матчится по валюте, статусу или неверному макросу.
Трафик не терпит кривых настроек postback-запросов, поэтому каждый шаг нужно логировать отдельно.

Перед масштабированием делайте тест: один клик, одна конверсия, один callback, сверка по sub_id и времени события. Если postback приходит, но в кабинете пусто — ищите расхождение в макросах, дубль запросов или фильтр по статуса́м. Сплит-тест — единственный объективный судья в арбитраже.

Итог: сначала добейтесь полной трассировки цепочки, потом уже смотрите на CR и ROI; без этого любая «оптимизация» работает на искажённых данных.