Что такое постбэк
и как он передаёт конверсии.

Постбэк — это серверное уведомление01

Постбэк (postback) — HTTP-запрос, которым одна система автоматически сообщает другой о событии: новой заявке, покупке или смене статуса. Запрос уходит от сервера к серверу, без участия браузера посетителя. Поэтому такой обмен ещё называют S2S, server-to-server.

Встречаются оба написания — «постбэк» и «постбек». Это одно и то же слово, калька с английского postback. В документации трекеров и CPA-сетей также пишут «постбэк-ссылка», «postback URL» и «серверный постбэк».

Зачем он нужен. Клик по партнёрской ссылке фиксирует трекер, а заявка появляется в CRM или на сайте рекламодателя — в другой системе и часто через несколько дней. Постбэк связывает эти события. Трекер узнаёт, что клик закончился целевым действием, и может начислить вознаграждение нужному партнёру по нужному офферу. Без постбэка результаты пришлось бы сверять вручную по таблицам.

Постбэк — основа учёта в модели оплаты за действие. Если вы только знакомитесь с ней, начните с руководства что такое CPA.

Как работает постбэк02

Схема почти одинакова во всех системах. Её ключ — click_id, уникальный идентификатор клика. В разных системах его называют по-своему: click ID, transaction ID, subid. Смысл один: по этому значению конверсию можно связать с переходом.

1. Клик получает click_id. Посетитель переходит по партнёрской ссылке. Трекер записывает переход — партнёра, оффер, метки, время — и присваивает ему идентификатор.
2. click_id передаётся в ссылке. Трекер перенаправляет посетителя на сайт рекламодателя и добавляет идентификатор в адрес страницы параметром.
3. Система рекламодателя сохраняет его вместе с заявкой. Сайт забирает click_id из адреса и передаёт в CRM вместе с формой: скрытым полем или через cookie.
4. При смене статуса уходит запрос на postback URL. Заявка создана, подтверждена или отклонена — сервер рекламодателя отправляет запрос трекеру и подставляет в него click_id и статус.
5. Платформа находит клик, партнёра и оффер. По click_id трекер находит исходный переход и обновляет статистику и начисления.
6. Партнёру может уйти свой постбэк. Если у партнёра собственный трекер, платформа отправляет уведомление дальше — уже со своим набором параметров.

Самое уязвимое место схемы — шаг 3. Если сайт не сохранил click_id или CRM его потеряла, постбэку нечего передать, и конверсия не найдёт свой клик.

Как click_id попадает в заявку

Обычно скрипт на посадочной странице читает параметр из адреса и записывает его в скрытое поле формы или в cookie. При отправке формы значение уходит в CRM вместе с остальными полями и хранится в карточке заявки. Если заявку оформляют позже, например после звонка, менеджеру не нужно ничего вводить: идентификатор уже есть в карточке.

Проверьте путь заранее. Параметр может потеряться, если посадочная страница перенаправляет посетителя на другой адрес, форма находится на другом домене или заявка приходит по телефону. Для каждого такого случая нужно своё решение, иначе часть конверсий останется без клика.

Как выглядит postback URL03

Postback URL — адрес, на который система рекламодателя отправляет уведомление. Его выдаёт принимающая сторона: трекер или партнёрская платформа. Упрощённо он выглядит так:

https://tracker.example.com/postback?click_id={click_id}&status={status}&payout={payout}

Иллюстрация, не адрес API Affelora. Имена параметров и макросов берутся из документации систем.

• https://tracker.example.com/postback — адрес обработчика у принимающей стороны. Он должен быть доступен из интернета, лучше по https.
• click_id={click_id} — идентификатор клика. В фигурных скобках — макрос: перед отправкой система подставит вместо него реальное значение, сохранённое с заявкой.
• status={status} — статус события: создано, подтверждено, отклонено. Названия статусов у двух систем обычно разные, поэтому их сопоставляют заранее.
• payout={payout} — сумма: вознаграждение или стоимость заказа, если ставка зависит от суммы.

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

Часто в адрес добавляют секретный токен. По нему принимающая сторона понимает, что запрос пришёл от известной системы, а не от постороннего.

Входящий и исходящий постбэк

В CPA-схеме обычно два постбэка. Входящий отправляет рекламодатель в партнёрскую платформу: он сообщает о заявке и её статусе. Исходящий отправляет платформа партнёру: партнёр указывает в кабинете адрес своего трекера, а платформа при каждом событии вызывает его и подставляет свои макросы.

Исходящий постбэк нужен партнёру, чтобы видеть конверсии в своей системе рядом с расходами на трафик. В нём передают click_id партнёра, статус и сумму вознаграждения. Внутренние данные рекламодателя туда не попадают.

Какие параметры передают04

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

Телефон, email, имя и другие персональные данные клиента в постбэке не нужны. Для учёта достаточно технических идентификаторов. Адреса с параметрами попадают в журналы серверов и сторонних систем, поэтому лишнее в них лучше не отправлять.

S2S-интеграция, пиксель и API05

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

Отсюда ответ на частый вопрос, чем S2S-интеграция отличается от постбэка. S2S — принцип обмена: данные идут напрямую между серверами, без браузера. Постбэк — уведомление о событии, отправленное по этому принципу. API — более широкий обмен: через него можно не только сообщить о конверсии, но и создать заявку, запросить статусы или получить справочники.

Пиксель встречается, когда у рекламодателя нет доступа к серверной части сайта. Но для учёта вознаграждений постбэк надёжнее. Он не зависит от того, дождался ли посетитель загрузки страницы и не заблокировал ли браузер сторонний код. А смену статуса через несколько дней пиксель передать не может вовсе: посетителя на сайте уже нет.

Статусы, повторы и отмены06

Одна заявка может породить несколько постбэков: при создании, при подтверждении, при отмене. Чтобы учёт сходился, правила обработки согласуют заранее.

• Повтор не должен давать второе начисление. Сервер может отправить один и тот же запрос дважды, например после таймаута. Принимающая сторона узнаёт повтор по ID заявки или транзакции и не создаёт новое действие.
• Смена статуса обновляет существующее действие. «Создана» и «подтверждена» — это одна заявка в двух состояниях, а не две конверсии.
• Отмена после подтверждения. Клиент вернул товар или не прошёл проверку — рекламодатель отправляет новый статус. Что происходит с начислением, если сверка уже прошла, определяют правила программы.
• Порядок прихода. Запросы могут прийти не в том порядке, в каком их отправили. Поздний «создана» не должен откатить уже полученный «подтверждена».
• Часовой пояс. Время события передают с указанием пояса или в едином поясе. Иначе заявки на границе суток попадут в разные дни у разных систем.
• Срок жизни клика. Системы хранят связь клика с партнёром ограниченное время. Если заявка оформлена позже согласованного окна, постбэк может не найти клик. Срок фиксируют в условиях оффера.

Отдельный риск — ложные конверсии и перехват чужих. Если обработчик постбэков не защищён токеном, событие может прийти не от вашей системы. А партнёр может подложить свой клик перед действием, которое произошло бы и без него. О таких схемах — в руководстве о мотивированном трафике и фроде, раздел про подмену атрибуции.

Как проверить постбэк07

Успешный ответ сервера ещё не значит, что конверсия учтена правильно. Проверяйте результат там, где его видят люди: в кабинетах и отчётах.

Для разбора нужен журнал с обеих сторон. В нём полезно хранить время запроса, полный адрес с параметрами, код ответа и текст ответа сервера. Без журнала спор «мы отправили — мы не получили» решить нельзя.

Если что-то не сходится, чаще всего причина в одном из пунктов ниже.

• Макрос не подставился. В журнале видно имя макроса вместо значения: система не нашла поле или макрос написан с ошибкой.
• Неверный статус. CRM отправляет одно значение, а платформа ждёт другое. Событие не распознаётся или попадает не в тот статус.
• Редирект или http вместо https. Часть серверов не следует за перенаправлениями при отправке запросов, и уведомление теряется по дороге.
• Фильтр по IP. Принимающая сторона разрешает запросы только с известных адресов, а сервер рекламодателя сменил адрес.
• Часовой пояс. Событие пришло, но легло в другой день, и сверка за период не сходится.
• click_id потерялся по дороге. Параметр отрезало перенаправление, форма не передала скрытое поле или посетитель вернулся на сайт позже по другой ссылке.

Тот же сценарий стоит пройти до выбора платформы. Как проверить поставщика до договора, включая проверку повторного постбэка на демонстрации, разобрано в руководстве по выбору CPA-платформы.

Постбэки в Affelora08

В Affelora переход связывается с результатом через партнёрские ссылки, метки sub1–sub5 и Click ID, а события передаются через API и постбэки (S2S). При подключении проверяем идентификатор, соответствие статусов, повторную отправку, отмену решения, часовой пояс и журнал ошибок. Проверка идёт сквозным тестом: смотрим не только ответ API, но и результат в кабинетах — партнёра, оффер, статус и начисление.

Настройка готовых подключений и постбэков входит в часы сопровождения по тарифу. Совместимость с вашей CRM проверяем по её API и документации: обещания готовой интеграции с любой системой нет. Подробности — на странице трекинг, subID и постбэки в Affelora.

Частые вопросы09