Conversion Value Payout: Passing Affiliate Payout as Event Value

At its core, conversion value payout is the difference between teaching the ad platform to count your conversions and teaching it to weigh them. A flat Purchase event says "another one happened"; the same event carrying the network's payout in its value field says "this one was worth 42 dollars, that one 9." Value-based optimization can only optimize toward the number you transmit, and for affiliate buyers that number is born in the CPA network's postback - not on your side. This guide follows the payout on its full journey: from the postback into the tracker, from the tracker into the event's value and currency fields, and through everything that makes payouts non-flat - partial approvals, rebills, and clawbacks.

The transport contract behind step one is in the network postback to CAPI guide; the approval-timing constraints are in the hold status guide. Here the focus stays on the number itself.

Why the Algorithm Should See Money, Not Counts

Ad platforms optimize campaigns toward the events they receive - see the Conversions API entry for the channel behind them. With flat events, every conversion weighs the same - a 3-dollar lead and a 60-dollar deposit are one and the same signal. The algorithm then does its job perfectly and finds you more of the cheap ones.

Value changes the objective. When each event carries its worth, the platform's value-based strategies can bid toward expected revenue instead of expected count, and the reporting layer finally speaks the same language as your balance. Meta documents the plumbing plainly: conversion events carry a value and a currency inside custom_data, with currency as an ISO 4217 code (server event parameters). TikTok's Events API follows the same event-parameter model for its funnel.

The catch for affiliate buyers: the money is not yours to observe at conversion time. Sales happen on the advertiser's page, and the only number you get is the payout the network reports. That makes the postback - not your checkout - the source of truth for value.

Where the Payout Number Comes From

Payout enters your system at handoff one. Keitaro's postback contract defines it as an optional parameter alongside subid and status: payout - with "positive and negative values are supported" - plus cost for CPA and RevShare models, and currency, which "the tracker converts to its base currency" (Keitaro postback documentation). Once stored, the payout travels back out through the tracker's macros: Keitaro's {conversion_revenue} placeholder exists precisely for outgoing S2S delivery (S2S postbacks).

That single sentence is the whole pipeline for most setups: network postback writes payout into the conversion row, delivery layer reads it back out. The failure modes are just as short - the network's postback template missing the payout macro entirely, or an empty value arriving because the advertiser reports payouts only after approval. Both show up as zero-value events at the platform, so value monitoring belongs in your regular postback log review.

From Payout to value: The Event Fields

Meta's server event schema puts the money in 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
      }
    }
  ]
}

The corpus mapping table for affiliate CAPI setups says it compactly: postback payout maps to custom_data.value as a number "paired with currency," and postback currency maps to custom_data.currency as an ISO 4217 code. Delivery layers - tracker integration or automation - do this mapping once; every postback thereafter rides the same path.

Two practical rules keep the value stream clean. First, decide the sign convention explicitly: a payout arrives positive for money earned, and Keitaro documents negative values as supported - which is exactly what clawbacks need (more below). Second, never send a currency-less value: the platform reads value in the context of currency, and a missing code makes the number ambiguous at best.

Non-Flat Payouts: Partials, Rebills, Clawbacks

Affiliate money rarely arrives as one clean number:

1. Partial approvals. The advertiser confirms 40 dollars of a 60-dollar lead. Your tracker's conversion row gets overwritten by the corrected payout postback - Keitaro's documented resend behavior - and the corrected number keeps your books honest. Already-sent platform events stand on their own - which is precisely why high-stakes offers delay sending until confirmation.
2. Rebills. A subscription offer pays monthly. Each rebill is a new conversion with its own transaction identity: Keitaro's tid-style parameter "records separate conversions instead of overwriting the previous one," and each becomes its own valued event. Timing still applies - a rebill must land inside the platform's acceptance window for its event time (using the API).
3. Clawbacks. A chargeback reverses a payout. The tracker's negative-payout support exists for exactly this, and your books stay accurate. On the platform side no correction channel is documented: deduplication keeps the first received copy of an event and discards later duplicates, so a resent correction changes nothing - which again argues for the hold-until-approval policy on offers where clawbacks are common.

Through-line: every bend in the payout is a data change the tracker already models, while the platform trusts the first event it received. Value passing breaks only when policy pretends otherwise - send timing and correction rules belong in one delivery layer, decided before traffic scales.

Currency: Three Records, One Truth

The payout's currency journey has up to three hops: the network reports in its currency, the tracker converts to its base ("the tracker converts payout to its base currency"), and the platform reads the event's currency code. Currency mismatches between ad accounts and networks distort value-based optimization silently - a 42-euro payout sent as 42 USD is not a rounding error, and the quality scoring layer is not where you want to discover it.

The fix is procedural, not technical: pick one conversion edge - usually "tracker base currency equals account currency" - and make the delivery layer assert the correct ISO code per event. When reconciliation shows money drifting between systems, the discrepancy guide separates counting problems from currency problems.

What Number Should Optimization See

The last decision is a policy one:

1. Gross payout at conversion time maximizes volume and freshness - right for fast-approving offers where clawbacks are rare.
2. Confirmed payout only sends money facts alone - right for high-rejection verticals, at the cost of the hold-window math from the hold guide.
3. Expected value (payout times approve rate) blends both - a modeling choice, and a defensible one, but it should live in the delivery layer where it is consistent, auditable, and per-offer.

Whichever you choose, the Meta-specific event wiring and the affiliate custom-conversion mapping carry it into the platform.

Conversion Value Payout: Frequently Asked Questions

Sources