Postback не работает

Введение

??????????? ??? ???????? ?????? ?????, ????? ???????? ??? ????, ?????? ??? CRM ??? ?????? ?????????? callback, ? ??????? ??? ????? ?? ??????????? ????????? ?????????. ??? ?? ????????????? ???????? ? ?? pre-launch QA checklist.

Проблемный production postback означает потерянные выплаты, кривую атрибуцию и эскалации с партнером без общей доказательной базы. Запрос может вообще не выйти из вашей инфраструктуры, может дойти до endpoint и упасть на валидации, а может вернуть 200 и все равно не зачесть конверсию.

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

Смотрите на postback troubleshooting как на production triage с тремя слоями доказательств: исходный клик и идентификатор, событие конверсии внутри трекера или CRM, и исходящий server-to-server callback. Если по какому-то слою нет подтверждения, расследование должно остановиться именно там.

Эта статья должна направить вас в правильную ветку. Если нужно проверить новую интеграцию до запуска, переходите в How to test a postback before launch. Если запрос доходит до партнера, возвращает 200, но конверсия не засчитывается, переходите в Postback Returns 200 but No Conversion. Если payload не совпадает с ожидаемым шаблоном, идите в гайд по сравнению template и live request.

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

Сначала разложите инцидент в один из трех бакетов: delivery, transport или payload. Delivery означает, что трекер вообще не отправил callback. Transport означает, что он пытался отправить, но не смог нормально достучаться до партнера. Payload означает, что запрос дошел, но в нем не хватило полей, формата или авторизации.

Эта классификация важна, потому что команды часто тратят часы на правку шаблонов postback, когда корень проблемы — это paused worker, мертвая очередь, истекший сертификат или IP allowlist у партнера. Production-сбои чинятся быстрее, когда каждый симптом привязан к своему слою.

• Трекер видит конверсию, но нет доказательств, что callback вообще пытались отправить.
• Callback отправляется, но DNS, TLS, firewall, auth или allowlist блокируют доставку.
• Партнер получает запрос, но goal ID, token, payout или click ID отсутствуют или неправильно отформатированы.
• Партнер поменял endpoint, сигнатуры или список допустимых параметров без предупреждения.
• Разные команды меняли шаблон, макросы или routing rules, но никто не обновил общий runbook.

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

Работайте от доказательств, а не от предположений. Подтвердите, что клик был, что конверсия была, что callback пытались отправить, и только потом редактируйте сам запрос. Тикет в стиле "postback не работает" заставляет обе стороны просто гадать.

Результатом расследования должен быть partner-ready набор доказательств: идентификатор клика, timestamp конверсии, callback URL или template, точный запрос, сырой ответ и слой, на котором живет проблема.

1. Докажите, что идентификатор был в момент клика

   Через Redirect Checker и Click ID Extractor подтвердите, что исходный клик действительно нес тот идентификатор, который позже должен появиться в callback.

2. Подтвердите слой конверсии

   Проверьте логи трекера или CRM и зафиксируйте timestamp конверсии, goal, payout и click ID. Если сама конверсия не подтверждается, postback — не первая проблема.

3. Разведите delivery и payload failure

   Поймите, пытался ли трекер автоматически отправить callback. Если нет, сначала разбирайтесь с очередями, worker'ами, background jobs и endpoint config, а не с макросами.

4. Повторите точный callback вручную

   Отправьте production payload через Postback Tester и сохраните response, latency и текст валидационной ошибки. Это сразу отделяет rejection на стороне партнера от проблем автоматической доставки у вас.

5. Передайте расследование в правильный соседний гайд

   Если live payload не совпадает с ожидаемым template, идите в гайд по сравнению шаблона и реального запроса. Если response = 200, но конверсии нет, идите в fix про 200-but-no-conversion. Если корень в потерянном click ID, уходите в click-ID troubleshooting.

Инструменты

Набор инструментов должен повторять набор доказательств. Один инструмент подтверждает клик, другой — идентификатор, третий — переигрывает callback, а четвертый помогает удерживать server-side attribution в согласованном состоянии, когда партнер спрашивает, почему postback и ad-platform events расходятся.

Не выгружайте в тикет все подряд. Передавайте только тот набор артефактов, который уже доказывает, где живет проблема.

Вывод

Postback-инциденты становятся дорогими, когда команда сразу лезет править шаблон, не доказав, вышел ли callback из трекера, дошел ли до партнера и где именно сломалась валидация. Production debugging ускоряется, когда каждый шаг заканчивается доказательством, а не мнением.

После фикса обновите runbook: в какой failure bucket попал инцидент, какое доказательство это подтвердило и какой соседний гайд помог бы сократить путь в следующий раз.

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

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