Передача выплаты value: выплата CPA сети в событии площадки

Термин «передача выплаты value» описывает разницу между «научить площадку считать ваши конверсии» и «научить её взвешивать их». Плоский Purchase говорит «случилось ещё одна»; тот же номер с выплатой сети в поле value говорит «эта была на 42 доллара, та - на 9». Value-based оптимизация способна оптимизироваться только на число, которое вы передаёте, а у арбитражника это число рождается в постбеке CPA сети - не на вашей стороне. Гайд ведёт выплату по всему пути: из постбека в трекер, из трекера в поля value и currency события - и через всё, что делает выплаты нелинейными.

Транспортный контракт первого шага - в гайде от постбека CPA сети до Conversions API; тайминговые ограничения аппрува - в гайде про холд-статусы. Здесь в фокусе само число.

Зачем алгоритму видеть деньги, а не счётчики

Площадки оптимизируют кампании на получаемых событиях - смотрите статью Conversions API о канале за ними. С плоскими событиями каждая конверсия весит одинаково - лид на 3 доллара и депозит на 60 для сигнала неразличимы. Алгоритм тогда делает свою работу идеально и приносит вам больше дешёвых.

Value меняет целевую функцию. Когда каждое событие несёт свою ценность, value-based стратегии площадки могут бидить в ожидаемую выручку вместо ожидаемого счётчика, а отчётный слой наконец говорит на языке вашего баланса. Meta документирует механику прямо: конверсионные события несут value и currency внутри custom_data, валюта - код ISO 4217 (параметры серверных событий). Events API TikTok держит ту же событийную модель параметров.

Подвох арбитражника: деньгами в момент конверсии вы не распоряжаетесь. Продажа случается на странице рекламодателя, и единственное число, которое вы получаете, - выплата, отчитанная сетью. Источник истины для value - постбек, а не ваш чекаут.

Откуда берётся число выплаты

Выплата входит в вашу систему на первом хопе. Постбек-контракт Keitaro определяет её как опциональный параметр рядом с subid и статусом: payout - причём «поддерживаются положительные и отрицательные значения» - плюс cost для CPA и RevShare моделей, и currency, которую «трекер конвертирует в базовую валюту» (документация постбеков Keitaro). Будучи сохранённой, выплата выезжает обратно макросами трекера: плейсхолдер {conversion_revenue} у Keitaro существует ровно для исходящей S2S-доставки (S2S постбеки).

Для большинства связок это вся труба одним предложением: постбек сети пишет выплату в строку конверсии, слой доставки читает её обратно. Режимы отказа столь же коротки - в шаблоне постбека сети вообще нет макроса выплаты, или приходит пустое значение, потому что рекламодатель отчитывает выплаты только после аппрува. Оба видны как события с нулевым value на площадке, поэтому монитор value - часть регулярного просмотра лога постбеков.

Из выплаты в value: поля события

Схема серверного события Meta кладёт деньги в custom_data:

{
  "data": [
    {
      "event_name": "Purchase",
      "event_time": 1790000000,
      "event_id": "postback-88412",
      "action_source": "website",
      "user_data": { "client_ip_address": "203.0.113.24" },
      "custom_data": {
        "currency": "USD",
        "value": 42.50
      }
    }
  ]
}

Таблица соответствий для арбитражных CAPI-связок в корпусе говорит это компактно: постбек-payout ложится в custom_data.value числом «в паре с валютой», а постбек-currency - в custom_data.currency как код ISO 4217. Слой доставки - интеграция трекера или автоматизация - настраивает это соответствие один раз; дальше каждый постбек едет по готовой дороге.

Два практических правила держат поток value чистым. Первое: зафиксируйте конвенцию знака явно - выплата приходит положительной у заработанного, а отрицательные значения документированы - именно они и нужны клэкбэкам (ниже). Второе: никогда не слать value без валюты - площадка читает value в контексте currency, и число без кода в лучшем случае двусмысленно.

Нелинейные выплаты: частичные аппрувы, ребиллы, клэкбэки

Арбитражные деньги редко приезжают одним чистым числом:

1. Частичные аппрувы. Рекламодатель подтвердил 40 долларов из 60-долларового лида. Строку конверсии в трекере перезапишет исправленный постбек выплаты - документированное поведение повтора у Keitaro, - а исправленное число держит честной вашу бухгалтерию. Уже отправленные события площадки живут своей жизнью - и именно поэтому высокостаканные офферы придерживают отправку до подтверждения.
2. Ребиллы. Подписочный оффер платит ежемесячно. Каждый ребилл - новая конверсия с собственной транзакционной идентичностью: параметр класса tid у Keitaro «записывает отдельные конверсии вместо перезаписи предыдущей», и каждая становится собственным событием с value. Тайминг действует и тут - ребилл обязан попасть в окно приёма площадки для своего event_time (using the API).
3. Клэкбэки. Чарджбек разворачивает выплату. Поддержка отрицательных выплат в трекере существует ровно для этого, и ваша бухгалтерия остаётся честной. На стороне площадки документированного канала коррекции нет: дедупликация хранит первую принятую копию события и отбрасывает поздние дубли, так что повторная коррекция ничего не меняет - что снова аргумент за политику придерживания до аппрува на офферах, где клэкбэки часты.

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

Валюта: три учёта, одна истина

При передаче выплаты учитывают до трёх валютных этапов: сеть отчитывается в своей валюте, трекер конвертирует её в базовую («трекер конвертирует выплату в базовую валюту»), площадка читает код currency события. Расхождения валют кабинета и сети молча искажают value-based оптимизацию - выплата в 42 евро, отправленная как 42 USD, - не погрешность округления, и слой оценки качества - не то место, где вы хотите это обнаружить.

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

Какое число должна видеть оптимизация

Последнее решение - политическое:

1. Грязная выплата в момент конверсии даёт максимум объёма и свежести - верно для быстроаппрувных офферов, где клэкбэки редки.
2. Только подтверждённая выплата шлёт одни денежные факты - верно для вертикалей с высоким отклонением, ценой арифметики холд-окна из гайда про холд.
3. Ожидаемое значение (выплата на аппрув-рейт) смешивает оба - выбор моделирующий, но защитимый; жить ему в слое доставки, где он консистентен, аудируем и настраивается по офферам.

Какой бы вариант вы ни выбрали, в площадку его донесут Meta-обвязка событий и настройка арбитражных кастомных конверсий.

Передача выплаты value: частые вопросы

Источники