Postback в арбитраже: как конверсия возвращается в трекер

В кабинете партнёрской программы появился депозит, а в трекере его нет. Расходы продолжают расти, кампания выглядит убыточной, автоматические правила снижают ставки. Через несколько часов вебмастер обнаруживает, что сама конверсия никуда не пропадала. До трекера просто не дошёл postback.

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

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

Одна конверсия проходит пять точек

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

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

На второй точке трекер принимает переход, записывает кампанию, креатив, площадку, устройство и другие параметры. Затем создаёт свой уникальный click ID.

На третьей точке трекер направляет пользователя на оффер и передаёт этот click ID в свободный параметр партнёрской ссылки. У одной сети он называется clickid, у другой aff_sub, sub1, s2 или иначе. Название поля не имеет значения. Важно, чтобы значение сохранилось без изменения.

На четвёртой точке пользователь выполняет целевое действие. Партнёрская платформа связывает регистрацию или депозит с сохранённым click ID.

На пятой точке платформа подставляет значение в postback URL и обращается к трекеру. Трекер находит исходный клик, добавляет к нему конверсию и пересчитывает отчёт.

Вся цепочка держится на одном совпадении: идентификатор, отправленный в оффер, должен вернуться в postback.

Click ID работает как номер квитанции

Click ID не описывает пользователя и не обязан быть понятным человеку. Это уникальная строка, по которой трекер находит запись о переходе. В ней уже сохранены источник, кампания, объявление, стоимость и время клика.

Упрощённая ссылка на оффер может выглядеть так:

offer.example/landing?sub1={clickid}

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

offer.example/landing?sub1=abc123xyz

В настройках партнёрки создают обратный адрес:

tracker.example/postback?clickid={sub1}

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

Частая ошибка возникает из-за одинаково выглядящих слов. Слева от знака равенства находится параметр принимающей системы. Справа находится макрос отправляющей системы. Их нельзя выбирать по памяти или копировать из другой сети.

Макрос и параметр выполняют разные роли

Postback URL состоит из адреса обработчика и набора параметров. Обязательным обычно является идентификатор клика. Остальные данные расширяют отчёт:

• status передаёт состояние конверсии;
• payout или sum передаёт выплату;
• currency указывает валюту;
• goal или event определяет тип действия;
• transaction_id или action_id отличает повторные события;
• conversion_time передаёт фактическое время действия;
• comment или custom fields добавляют служебную информацию.

Конкретные названия зависят от платформы. Например, один трекер ожидает clickid, другой cid. Одна партнёрка отдаёт выплату через payout, другая через sum. Поэтому рабочий postback всегда собирается из документации двух сторон.

Нельзя вставить пример целиком и заменить только домен. Сначала определяют, какие поля принимает трекер, затем подставляют в них макросы, которые реально поддерживает партнёрская сеть.

Что происходит со статусами

В iGaming одна конверсия может менять состояние несколько раз. Регистрация появляется как новое событие, депозит уходит на проверку, затем подтверждается или отклоняется. Если трекер принимает только первый postback, отчёт быстро расходится с кабинетом партнёрки.

Есть два распространённых подхода. При первом каждое состояние отправляется как отдельный тип события: Registration, FTD Pending, FTD Approved. При втором одна запись обновляется по transaction ID.

Выбор зависит от трекера и целей аналитики. Отдельные события удобны для построения воронки. Обновление одной конверсии помогает видеть её актуальный статус и не завышать количество депозитов.

Особенно важно проверить обработку declined. Если отклонённый депозит остаётся в трекере как оплачиваемый, ROI будет выглядеть выше реального. Если повторный approved postback считается дублем и игнорируется, отчёт останется заниженным.

Зачем передавать transaction ID

Один пользователь способен выполнить несколько действий после одного клика. Он регистрируется, делает первый депозит, затем пополняет баланс повторно. Во всех событиях может возвращаться тот же click ID.

Если трекер определяет дубль только по click ID, второй депозит будет отброшен или перезапишет первый. Уникальный transaction ID позволяет отличить отдельную операцию от повторной отправки того же события.

Это полезно и для защиты от технических дублей. Партнёрская платформа может повторить запрос после таймаута, хотя первый уже дошёл. При одинаковом transaction ID трекер понимает, что речь идёт об одной конверсии, а не о двух новых депозитах.

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

Postback и пиксель решают похожую задачу по-разному

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

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

При этом S2S не исправляет плохую передачу идентификатора. Если click ID потерялся до конверсии, серверу нечего возвращать. Надёжность postback начинается не в момент отправки события, а в момент первого перехода.

Семь причин, по которым конверсия не появилась

Click ID не ушёл в оффер. Макрос остался текстом, параметр удалился при редиректе или ссылка была собрана без нужного поля.

Партнёрка не сохранила значение. Использован неподдерживаемый sub-параметр либо поле имеет ограничение по длине и формату.

Перепутаны макросы. В postback вставлено название параметра вместо макроса платформы. В результате запрос приходит со значением вроде {sub1}, а не с реальным ID.

Postback добавлен не на тот уровень. Глобальный postback перекрыт настройкой оффера или адрес сохранён в другой цели.

Событие считается дублем. Повторный депозит пришёл с тем же click ID без уникального transaction ID, а режим трекера настроен на игнорирование повторов.

Статус не сопоставлен. Партнёрка отправила pending или approved, но трекер не знает такое значение и отклонил запрос либо записал его не в ту цель.

Запрос дошёл с ошибкой. Домен, SSL-сертификат, обязательный параметр, кодировка или секретный ключ настроены неправильно. Ответ сервера 200, 400 и 500 расскажет больше, чем сравнение итоговых таблиц.

Как тестировать цепочку без догадок

Тест начинается с реального клика по кампании. Нужно открыть ссылку так, чтобы трекер создал обычную запись, затем найти переход в click log и скопировать его click ID.

После этого проверяют конечную ссылку. В ней не должно остаться необработанных макросов. Значение click ID должно находиться именно в том параметре, который сохраняет партнёрская программа.

Далее выполняют тестовую конверсию средствами сети либо вызывают postback с найденным ID вручную. Трекер должен вернуть успешный ответ и показать событие рядом с исходным кликом.

Проверка считается завершённой только после сравнения четырёх мест:

1. Лог клика в трекере.
2. Значение параметра в конечной ссылке.
3. Лог исходящего postback в партнёрке.
4. Лог принятой конверсии в трекере.

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

Диагностика начинается с направления потери

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

Если конверсия есть в партнёрке, но отсутствует в трекере, проверяют сохранённый click ID, исходящий postback и ответ трекера.

Если событие есть в трекере, но не дошло до рекламного источника, проблема находится на следующем участке. Нужно проверить сохранение source click ID, интеграцию с кабинетом и правила отправки выбранной цели.

Такое деление экономит время. Фраза «не работает postback» слишком общая. Сначала нужно назвать две системы, между которыми исчезло событие.

Payout и валюта могут испортить отчёт без потери конверсий

Иногда события передаются правильно, но экономика остаётся неверной. Например, партнёрка отправляет 50 EUR, а трекер записывает значение как 50 USD. В другом случае макрос payout пустой, поэтому используется фиксированная выплата из настроек оффера.

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

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

Безопасность postback тоже важна

Postback URL способен создавать конверсии, поэтому его нельзя без необходимости публиковать вместе с рабочим ключом. Если трекер поддерживает secure token или hash, его добавляют к запросу и проверяют на принимающей стороне.

В postback не стоит передавать лишние персональные данные. Для атрибуции достаточно технических идентификаторов события и клика. Электронная почта, телефон или платёжные реквизиты обычно не нужны и повышают риск утечки.

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

Финальная проверка перед запуском

Рабочая интеграция отвечает на девять вопросов:

• трекер создаёт уникальный click ID;
• ID передаётся в поддерживаемый параметр оффера;
• партнёрка сохраняет значение без изменения;
• postback возвращает ID в обязательное поле трекера;
• цели и статусы сопоставлены;
• payout и currency записываются правильно;
• повторные события имеют transaction ID;
• тестовый запрос виден в логах обеих систем;
• конверсия отправляется дальше в источник трафика, если это требуется.

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