Постбэк: что это и как работает

Постбэк — это HTTP-запрос, которым одна система сообщает другой о целевом событии: заявке, регистрации, оплате. В партнёрском маркетинге без него не работает цепочка «рекламодатель — сеть — вебмастер»: постбэк приносит в сеть факт конверсии, а сеть по нему начисляет выплату партнёру. Ниже — как устроен запрос, какие параметры он передаёт, кто кому его отправляет, чем серверный постбэк отличается от пикселя и зачем нужны логи отправок.

Определение

Постбэк (postback URL, S2S-постбэк, server-to-server, callback о конверсии) — запрос, который один сервер отправляет другому по заранее согласованным адресу и формату, когда происходит целевое событие. В документации мобильной аналитики он определён так же: запрос по заданной ссылке, в который передаются параметры конверсии. Общее у всех формулировок одно: уведомление идёт от сервера к серверу и не зависит ни от браузера пользователя, ни от cookies.

Слово пришло из веб-разработки, где postback исторически означал отправку формы обратно на тот же сервер. В CPA-маркетинге за ним закрепилось более узкое значение: уведомление о конверсии, передаваемое между системами. Встречающиеся названия — server ping, серверный постбэк, S2S — обозначают один и тот же механизм.

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

Адрес приёма сеть хранит в виде шаблона с макросами:

https://network.example.com/pb?clickid={clickid}&status={status}&payout={payout}&currency={currency}

В момент события платформа-источник заменяет каждый макрос значением конкретной конверсии:

https://network.example.com/pb?clickid=a1b2c3&status=approved&payout=350&currency=RUB&transaction_id=98421

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

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

Получив постбэк, сеть не записывает выплату немедленно: конверсия сначала проходит сверку с условиями оффера и попадает на холд, и только после подтверждения превращается в начисление. Удержание выплаты до подтверждения — отдельное свойство конверсии, а не сбой, и правила холда сеть задаёт по каждому офферу. Как устроено это подтверждение — в разделе Холды и подтверждение конверсий.

Постбэк стоит рядом с вебхуком: тот же сервер вызывает тот же адрес другого сервера. Разница в договоре. Вебхук — общее уведомление «что-то произошло», из внешнего сервиса в ваш: платёжный шлюз сообщает о платеже, форма — о новой заявке. Постбэк — уведомление о конверсии, привязанное к идентификатору клика, статусу и сумме, то есть к расчёту между сторонами; формат, состав параметров и статусы зафиксированы интеграцией. На практике границы подвижны: приёмник, который умеет принимать постбэки, примет и вебхук платёжной системы — разница в том, какие поля в нём лежат.

Параметры

Постбэк — обычный URL, устроенный по общим правилам URI: схема, домен, путь и необязательная строка запроса после знака вопроса. Стандарт описывает строку запроса как последовательность пар «имя=значение», разделённых амперсандом. Значения с пробелами, кириллицей или служебными символами кодируются процентным кодированием — иначе принимающий сервер не разберёт запрос.

Набор параметров стороны фиксируют при интеграции. Минимальный смысловой набор выглядит так:

• clickid, subid — идентификатор клика. Единственный обязательный параметр: без него конверсию не с чем связать. Имя параметра у каждой сети своё — sub1, aff_sub и другие — его смотрят в документации сети, а не подбирают наугад;
• status — статус конверсии: создана, подтверждена, отклонена. Промежуточное значение «холд» означает, что решение о выплате пока не принято;
• payout и валюта — сумма вознаграждения, по которой сеть рассчитывается с вебмастером;
• transaction_id — идентификатор события или заказа. У повторного наступления того же события он другой, поэтому по нему отсеивают дубли;
• event — название события, если одним адресом принимают несколько типов конверсий: заявка, регистрация, покупка;
• время события — для сверки с собственными записями рекламодателя.

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

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

Статусы HTTP в ответе

Ответ принимающего сервера — часть договора, и коды ответа означают разное. Стандарт HTTP описывает 200 OK как успешный обычный ответ; 400 — запрос с ошибкой, который не стоит повторять в том же виде; 401 и 403 — доступ без действительного секрета или прав; 404 — адрес не найден; 408 — истёкшее время ожидания; 409 — конфликт с тем, что уже записано, так часть систем отвечает на дубль; 500 — ошибка на принимающей стороне, после которой повтор уместен. Отсюда практическое правило обеих сторон: сообщать о приёме кодом 200 только после того, как конверсия записана, а не «по факту получения письма». Преждевременный «ок» превращает сбой записи в молчаливую потерю события: отправитель получил подтверждение и повторов не делает.

Макросы

Шаблон с плейсхолдерами — общепринятый способ передать данные конверсии без ручной интеграции каждого оффера. Синтаксис макросов у платформ различается: где-то подстановка в фигурных скобках, где-то со знаком доллара, решёткой или в квадратных скобках. При интеграции синтаксис копируют из документации сети: подстановка «по аналогии» доходит до приёмника как буквальный текст, и конверсия теряется ещё на отправке.

Чаще постбэк отправляют методом GET — все параметры помещаются в адрес. Метод определён стандартом HTTP как получение информации, и постбэк ему соответствует: получатель только записывает данные, состояние конверсии он не меняет ничем, кроме самой записи. Встречается и POST: тогда значения подставляются не в адрес, а в тело запроса, обычно в JSON. Правила те же: имя макроса в фигурных скобках внутри тела заменяется данными клика и события при отправке. POST выбирают, когда параметров много или приёмник принимает только тело.

Если значение макроса определить не удалось, параметр уходит пустым — так описано в документации мобильных метрик. Принимающая система должна переживать пустое значение, не разваливая весь запрос: отсутствие поля значит «данных нет», а не «запрос неверный».

Имена параметров у отправителя и приёмника не обязаны совпадать: у сети клик живёт в sub1, у трекера вебмастера — в click_id, и шаблон как раз их связывает. Эта связка — маппинг — делается один раз при интеграции: слева имя параметра принимающего адреса, справа макрос отправляющей системы. Ошибка маппинга коварна тем, что запрос выглядит правильно: параметры заполнены, сервер отвечает 200, но идентификатор клика лежит не в том поле, и конверсия не привязывается к источнику. Поэтому после интеграции проверяют не «дошёл ли запрос», а «записалась ли конверсия с нужными значениями».

Кодирование значений

Значения параметров попадают в URL только в закодированном виде: пробел превращается в %20, кириллица — в последовательности вида %D0%B0. Отсюда практика машиночитаемых статусов: вместо «конверсия подтверждена» в параметре передают approved, вместо отклонения — declined. Человекочитаемые подписи к этим значениям держат на стороне приёмника, в справочнике статусов, а не в самом запросе.

Подлинность и дубли

Адрес приёма открыт из интернета, поэтому подлинность запроса не сводят к секретности адреса. В параметры добавляют подпись — хеш от данных конверсии с секретным ключом, известным только сторонам, — либо проверяют статический секрет в отдельном параметре. Запрос без подписи принимающая сторона вправе отклонить, и такое отклонение тоже попадает в журнал.

Дубли отсеивают по идентификатору события: повторный запрос с тем же transaction_id не должен создавать вторую конверсию. Чтобы это работало, идентификатор должен быть уникален на стороне источника — им становится номер заказа или транзакции в биллинге, а не счётчик отправок. Подпись дополняют меткой времени: запрос, подписанный спустя часы после события, приёмник вправе отвергнуть — так закрывается повторная отправка перехваченного запроса.

Кто кому шлёт

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

Главное в этом звене то, что отправку инициирует сервер рекламодателя, а не страница. Пока уведомление о конверсии отдаётся скрипту на странице «спасибо», оно зависит от того, дошёл ли пользователь до этой страницы и выполнил ли браузер скрипт. Постбэк ставят на бэкенд, рядом с обработкой платежей и заявок, — тогда уведомление уходит при самом событии, а не при показе страницы.

Второе звено — от сети к вебмастеру. Приняв конверсию, платформа уведомляет партнёра тем же способом: GET-запросом на его postback URL с идентификатором клика, суммой и типом конверсии. Вебмастер видит событие в своём трекере в момент события, без ручной выгрузки отчётов. Браузер в обоих звеньях уже не участвует — он закончил работу на этапе клика и целевого действия. Отсюда название server-to-server: данные идут между серверами, cookies не нужны.

Правила отправки настраиваются. Постбэк включают на весь аккаунт или только на отдельный оффер; выбирают, о каких типах конверсий и каких статусах сообщать; настраивают ретрансляцию партнёру — например, передавать вебмастеру только подтверждённые конверсии. Фильтр по статусам — отдельный договор: одному вебмастеру ретранслируют события сразу в статусе «создана», чтобы он видел заявки в реальном времени, другому — только подтверждённые, потому что его закупка оплачена по подтверждённому объёму. Глобальный шаблон принимающей стороны экономит работу: один адрес принимается со всех офферов сети, отдельные шаблоны добавляют там, где нужен особый набор параметров.

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

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

Серверный и пиксель

Зафиксировать конверсию можно двумя способами. Пиксель — фрагмент кода на странице «спасибо»: браузер пользователя сам сообщает трекеру о событии. Способ не требует доступа к серверу рекламодателя и ставится за минуты, поэтому его выбирают для быстрого запуска и проверки оффера.

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

Серверный постбэк от этого свободен. Запрос идёт между серверами, cookies и браузер не участвуют, поэтому оплата, событие в приложении и офлайн-конверсия в точке продаж доходят так же, как обычная заявка. Данные, которые стоят за постбэком, первичны: это записи биллинга и платёжных систем, а счётчик на странице — производная величина. Для расчёта выплат между рекламодателем, сетью и вебмастером используют именно S2S-постбэки; пиксель остаётся для быстрых проверок гипотез и маркетинговых событий, где ошибка на одну конверсию не стоит денег.

На практике способы совмещают: пиксель даёт мгновенный черновой подсчёт, постбэк приносит подтверждённые данные для денег. Расхождение между двумя счётчиками — полезная диагностика: если пиксель насчитал заметно меньше, чем пришло постбэками, часть пользователей теряется между кликом и страницей «спасибо» — виноваты блокировщики, сломанный код страницы или переходы между устройствами.

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

Логи

Постбэк — сетевой запрос, а любой запрос может не дойти: таймаут, недоступность сервера, опечатка в адресе, макрос, который не заменился значением. Поэтому доставкой считают не «отправил», а «принято»: отправка успешна, когда принимающий сервер ответил кодом 200. На любой другой ответ платформа повторяет отправку — в мобильной аналитике повторные попытки идут каждые 5–10 минут в течение суток после события.

Логи постбэков — журнал, где по каждой попытке записаны время, полный URL с параметрами, код ответа и результат: принято, повтор, отклонено. Журнал нужен в трёх случаях. При разборе споров: рекламодатель утверждает, что отправил, а сеть конверсии не видит — журнал показывает, пришёл ли запрос и каким был ответ. При отладке макросов на новом оффере: видно, чем заполнился каждый параметр. При поиске дублей: одно и то же событие приходит дважды, и по идентификатору в журнале видно, какая из попыток создала конверсию.

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

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

То же самое спрашивает с сети и вебмастер, у которого конверсии пропали: дошёл ли постбэк, каким был ответ, не изменился ли формат. Когда обе стороны смотрят в журналы, разбор занимает минуты вместо переписки.

Формат постбэка в Recca совместим с конвенцией Affise — привычные макросы называются и работают так же, а вместе с постбэками платформа ведёт и их логи; механика настройки описана в разделе S2S-постбэки.

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

Если запускаете собственную CPA-сеть, оставьте заявку на подключение на странице тарифа «CPA-сеть».