Postback и события: что обязательно настроить партнёру, чтобы не терять деньги

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

В 2026 году проблема стала ещё заметнее. Ограничения браузеров, блокировка cookies и трекинг-защита в iOS и Android делают S2S postback практически обязательным элементом инфраструктуры. В статье разберемся, что вообще такое postback в партнёрке, какие события нужно отслеживать и как проверить, что трекинг работает корректно.

Что такое postback (S2S) простыми словами

Postback — это сервер-к-серверу уведомление (S2S), которое отправляется из партнёрской программы в трекер или систему аналитики, когда происходит конверсия.

Если говорить просто: пользователь совершает действие → партнёрка фиксирует событие → сервер отправляет postback в трекер.

Так трекер понимает, какой именно клик привёл к конверсии. Например: клик → регистрация → оплата → партнёрка отправляет postback → трекер фиксирует событие.

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

Почему?

• postback не зависит от cookies
  
• не блокируется браузером
  
• работает даже если пользователь сменил устройство
  
• передаёт точные параметры клика
  

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

• потерялся clickid
  
• редирект удалил параметры
  
• события отправляются на неправильный endpoint
  
• неправильно настроены статусы.
  

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

Минимальная архитектура партнерского трекинга

Она выглядит так: источник трафика → трекер → оффер/партнёрка → postback → трекер/аналитика.

Ключевой элемент этой цепочки — идентификатор клика.

Чаще всего это:

• clickid
  
• subid
  
• transaction_id
  

Этот параметр передаётся в партнёрку вместе с кликом, а затем возвращается через postback. Если clickid потерялся — конверсия не сможет «склеиться» с кликом. Поэтому в арбитраже трафика всегда используется структура subid.

Например: source|campaign|adset|creative|placement.

Так партнёр может видеть:

• источник трафика
  
• кампанию
  
• креатив
  
• площадку
  

Иногда дополнительно передаются:

• geo
  
• device
  
• os
  
• utm метки.
  

Так строится сквозная аналитика: партнёрка + трекер + источник трафика. Хотите узнать больше о метках, статистике и анализе лидов? Читайте отдельную нашу статью.

Какие события обязательно отслеживать

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

• Click. Фиксирует переход пользователя. Без него невозможно построить атрибуцию.

• Lead / Registration. Первичное действие пользователя: регистрация, заявка, установка. Это первый сигнал качества трафика.

• Approved / Valid. Подтверждение того, что лид прошёл проверку. В некоторых партнёрках именно этот статус используется для оплаты.

• Sale / Paid. Ключевое событие. Оно означает, что пользователь совершил оплату. Именно здесь появляются реальные деньги.

• Rebill / Renewal. Особенно важно для подписочных офферов. Это повторная оплата или продление подписки. Иногда именно rebill приносит основную прибыль.

• Refund / Chargeback. Возврат денег пользователю. Если не учитывать эти события, можно получить ложную прибыль.

• Rejected. Отклонённый лид. Важно понимать процент отклонений.

Статусы и деньги: что важно понимать партнёру

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

Например:

• Lead — пользователь оставил заявку или зарегистрировался. Это первичное действие, но деньги на этом этапе ещё не гарантированы.
• Approved / Valid — лид прошёл проверку качества. Партнёрка подтверждает, что действие было реальным и соответствует требованиям оффера.
• Paid / Sale — произошла оплата или депозит. Вот на этом этапе появляются реальные деньги.
• Rebill / Renewal — повторное списание средств по подписке. В некоторых офферах именно здесь формируется основная прибыль.
• Rejected — лид отклонён. Например, из-за фрода, дубликатов или несоответствия гео.
• Refund / Chargeback — возврат средств. Это особенно важно учитывать в долгосрочной аналитике.

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

Но в реальности между lead и paid может быть огромная разница. Например:

• 100 лидов
• 40 approved
• 15 оплат.

Если оптимизировать рекламу только по лидам, можно легко масштабировать убыточный трафик. Поэтому правильный подход — строить аналитику так, чтобы видеть финальные деньги: paid, rebill и возвраты.

Параметры, которые нужно передавать всегда

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

Чаще всего используется параметр clickid или transaction_id.

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

Помимо clickid, почти всегда используется subid. Subid позволяет передавать дополнительные параметры кампании. Например: source | campaign | adset | creative | placement.

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

• geo — страна пользователя
• device / os — устройство и операционная система
• event_name — название события
• status — статус конверсии
• payout / amount — размер выплаты
• currency — валюта
• timestamp — время события.

Такая структура данных позволяет не только фиксировать конверсии, но и строить полноценную аналитику.

Например:

• понимать, какие креативы дают больше оплат
• сравнивать эффективность разных гео
• анализировать задержку между кликом и оплатой.

Без передачи этих параметров часть информации просто теряется, и оптимизация кампаний становится намного сложнее.

Типовые схемы настройки postback

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

Самая распространённая схема — postback партнёрка → трекер.

В этом случае:

1. пользователь кликает по рекламе
2. трекер создаёт clickid
3. пользователь переходит на лендинг или оффер
4. происходит конверсия
5. партнёрка отправляет postback в трекер.

В postback передаются:

• clickid
• событие
• статус
• сумма выплаты.

Трекер получает это событие и связывает его с исходным кликом.

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

Иногда вместо классического postback используются webhooks. Webhook — это тоже серверное событие, но оно может отправляться в разные системы и запускать дополнительные действия: например обновление CRM или отправку данных в аналитику.

Для арбитража трафика чаще всего используется именно S2S postback, потому что он:

• надёжнее браузерных пикселей
• не зависит от cookies
• работает даже при ограничениях приватности.

Правильно настроенный postback позволяет видеть реальную картину конверсий и принимать решения на основе данных, а не догадок.

Как проверить postback за 30 минут

Перед запуском кампаний стоит провести быстрый тест.

1. Сделать тестовый клик с уникальным subid.
   
2. Создать тестовый лид или регистрацию.
   
3. Проверить, дошёл ли postback до трекера.
   
4. Убедиться, что clickid совпадает.
   
5. Проверить, нет ли дублей конверсий.
   
6. Проверить задержку (delayed conversions).
   

Такая проверка занимает меньше получаса, но экономит много денег.

Топ ошибок настройки postback

Самые частые причины потерянных лидов:

• Нет clickid в ссылке. Конверсия не может связаться с кликом.
• Редиректы съели параметры. Особенно часто это происходит при нескольких промежуточных доменах.
• Ошибки URL-кодирования. Спецсимволы ломают параметры.
• Перепутаны event_name и status.
• Postback отправляется на неправильный endpoint.
• Дубли событий. Конверсия фиксируется дважды.
• Нет событий paid или rebill. Из-за этого партнёр не видит реальные деньги.
• Не учитываются refund и chargeback.

События для подписочных офферов

Подписочные офферы отличаются от обычных CPA тем, что у пользователя появляется несколько финансовых событий, а не одно. Если в системе фиксируется только первое действие (например lead или trial), большая часть данных о доходе просто теряется. Поэтому для подписочных моделей важно правильно передавать разные типы событий через postback.

Чаще всего используются следующие event_name:

• trial / start_trial. Пользователь активировал пробный период. Это событие показывает начало подписки, но ещё не означает оплату.
• paid / first_payment. Первое списание средств. Именно здесь появляется первая реальная выплата.
• rebill / renewal. Повторное списание средств по подписке. Такие события могут происходить несколько раз и часто дают основную прибыль.
• cancel. Подписка отменена пользователем.
• refund / chargeback. Возврат средств или спорный платёж.

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

Также желательно передавать дополнительные параметры:

• event_name
• payout или amount
• currency
• timestamp.

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

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

Правильно настроенный postback и система событий — это основа аналитики в арбитраже трафика. Если она работает некорректно, начинается хаос, а ваш заработок падает. Именно поэтому перед запуском трафика важно проверить передачу clickid, корректность событий и отсутствие дублей конверсий. Потратив немного времени на настройку и тестирование postback, можно избежать потери данных — а вместе с ними и значительной части прибыли.

А если только начинаете путь в арбитраже трафика, присоединяйтесь к HUNT ME! Снабдим первыми офферами, скриптами, гайдами и готовыми инструментами — всем, чтобы вы вышли на стабильный доход от $500 уже в первый месяц.

Регистрируйтесь и получайте свой первый оффер всего за 5 минут!