Postback ломается не на трекере, а на кривой передаче событий и дедупликации

Когда лиды есть, а в трекере пусто или дубли растут, проблема обычно в цепочке: клик → landing → форма → postback → аналитика. Проверять нужно не “в целом интеграцию”, а каждый параметр отдельно: clickid, status, payout, currency, event_name. Один битый параметр уже дает расхождение между кабинетом, трекером и CRM.

Что я смотрю первым:
— совпадает ли clickid в URL, в логах сервера и в postback;
— не режется ли строка при редиректе или маскировании ссылок;
— одинаково ли трактуются статусы: lead, approved, rejected, duplicate;
— есть ли дедуп по одному и тому же событию, а не по разным источникам.

Дальше — синхронизация времени и окон атрибуции. Если трекер пишет событие с задержкой, а аналитика закрывает окно раньше, вы получите ложный минус по ROI. Анализ данных говорит сам за себя: сначала сверяем сырые логи, потом уже смотрим отчеты в кабинете. Иначе оптимизируете не трафик, а ошибку интеграции.

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

Когда цепочка чистая, расхождение между системами становится управляемым. В текущих реалиях 2026 года это работает так: сначала лог, потом атрибуция, и только затем решения по масштабированию.