Как сравнить шаблон постбека с реальным запросом

Введение

Шаблон постбека сам по себе ничего не доказывает. Для диагностики важно подтвердить, совпадает ли реальный callback с тем, что должно было уйти после подстановки макросов, кодирования URL и отправки на endpoint партнера.

Этот сценарий нужен для частой серой зоны: сеть говорит, что шаблон верный, endpoint отвечает 200, но конверсия все равно не появляется или лог принимающей стороны показывает другой payload.

Как работает концепция

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

Относитесь к сравнению как к структурированному QA. Проверять нужно не только факт запроса, а имена параметров, подстановку макросов, кодировку, формат payout, event name и любые auth/signature-поля.

Типичные проблемы

Большинство споров по постбекам возникает из-за тихих отличий между шаблоном и фактическим запросом. Макрос может остаться буквальным, click ID может уйти в другой параметр, а трекер может добавить лишнее поле, из-за которого партнер по-другому парсит callback.

Поскольку многие endpoint'ы все равно отвечают 200 на некорректный payload, команды часто останавливаются на транспортном успехе и пропускают бизнес-ошибку, которая и ломает атрибуцию.

• В live-request используется другое имя параметра, чем в утвержденном шаблоне.
• Макрос раскрывается в пустое значение или остается буквальным токеном.
• Из-за URL-кодировки партнер читает другое итоговое значение.
• Payout, status или goal в проде форматируются не так, как в QA.
• Endpoint отвечает 200, но в логе партнера неверный click ID или не хватает обязательных полей.

Пошаговый разбор

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

Идите по порядку: сначала подтверждайте шаблон, затем воспроизводите live-request и только после этого исправляйте найденные отличия. Так путь диагностики остается коротким и доказательным.

Если нужно повторно отправить callback в контролируемом виде, используйте Postback Tester, а для более глубокого разбора ответа держите рядом Postback Debugger.

1. Зафиксируйте утвержденный шаблон

   Скопируйте точный шаблон из трекера или документации партнера вместе с именами параметров, макросами, placeholder'ами, подписью и правилами кодировки.

2. Снимите реальный callback

   Возьмите фактический запрос из лога трекера, сети или Postback Debugger, чтобы сравнивать с live-payload, а не с реконструкцией по памяти.

3. Сравните поля по одному

   Проверьте click ID, payout, status, goal, sub ID, auth-поля и URL-кодировку по отдельности. Если структура уже выглядит подозрительно, сначала прогоните URL через Postback URL Checker.

4. Повторите запрос в контролируемом тесте

   Отправьте исправленную или подозрительную версию через Postback Tester и сохраните полный ответ, headers и latency, чтобы команда видела, что именно изменилось.

5. Переведите расхождение в правильный fix-path

   Если макросы остались буквальными, переходите к Postback Macro Not Replaced. Если endpoint отвечает 200, но конверсия не засчитывается, переходите к Postback Returns 200 but No Conversion.

Инструменты

Для такого аудита не нужен большой стек. Используйте postback-инструменты как цепочку: проверьте структуру callback URL, посмотрите live-request, воспроизведите payload и только потом переходите к fix-guide по подтвержденному типу ошибки.

Такой порядок удерживает ревью шаблона в зоне фактов, а не предположений по скриншотам и названиям полей в интерфейсе трекера.

Вывод

Сравнение постбека завершено только тогда, когда команда может назвать точное поле, которое разошлось между шаблоном и live-request. Это убирает догадки из эскалаций к партнерам и сокращает число тупиковых расследований с ответом 200.

Храните вместе утвержденный шаблон, реальный запрос и результат повторного теста. Такой небольшой evidence pack ускоряет и новые запуски, и разбор будущих инцидентов.

Похожие проблемы

• Макросы в postback не подставляются
• Postback Returns 200 but No Conversion