Discussion: `affiliate` channel has no matching pricing model — should AdCP add `revenue_share`?

[torbenbrodt]

Summary

AdCP recognizes affiliate as a valid channel in the media channel taxonomy, but has no pricing model that expresses an affiliate commission rate (percentage of attributed sale value). The closest model, cpa, requires a fixed_price per acquisition — it does not support a percentage-of-revenue rate.

This issue asks the working group to decide whether AdCP should add a revenue_share pricing model, extend cpa, or formally treat affiliate commission as out-of-band.

---

The Gap

The pricing-model enum currently contains:
cpm, vcpm, cpc, cpcv, cpv, cpp, cpa, flat_rate, time

The affiliate commercial model is:

Advertiser pays a percentage of attributed sale value (e.g. "4% of each purchase attributed to a publisher click")

There is no commission_rate or revenue_share_pct field anywhere in the schema. cpa-option.json requires fixed_price — a fixed dollar amount per event, not a percentage of order value.

This gap was surfaced during a real integration: a campaign brief stated Budget Type: Affiliate / Commission: 4%. There is no AdCP pricing option that maps to this. The workaround was to treat the commission rate as a commercial term between the advertiser and the affiliate network (out-of-band), and select a cpc or cpm pricing option from the seller's product instead.

---

Why This Is Worth Discussing

affiliate appears as a first-class channel in the AdCP channel taxonomy alongside display, olv, ctv, retail_media, etc. If a seller declares channels: ["affiliate"] on a product, there is currently no pricing model that reflects how affiliate inventory is actually priced. That's an internal consistency gap.

The question is whether AdCP should close it at the protocol layer, or whether affiliate commission is inherently a network-layer commercial term that sits above AdCP — with AdCP only seeing the resulting CPC/CPM media buy.

There's also an open architectural question this group should answer first: who is the seller in an AdCP affiliate relationship?

• If the publisher/placement is the seller, revenue_share means "publisher earns X% of attributed sale value per placement." This is a clean seller-declared pricing model.
• If the affiliate network is the seller (acting as operator/SSP), the network's payout structure is what revenue_share would express. This raises a broader question about whether affiliate networks belong in AdCP's seller model at all.

The answer shapes the schema design.

---

Options

Option A — Add revenue_share pricing model (new enum value + schema)

{
  "pricing_model": "revenue_share",
  "event_type": "purchase",
  "commission_rate": 0.04,
  "currency": "USD"
}

Sellers that support affiliate commission expose revenue_share pricing options on their products. Sellers that don't simply omit it. Follows the same discriminated-union pattern as existing pricing models.

Precedent exists: signals pricing already includes percent_of_media (a percentage-of-value model). This would be the equivalent for media buy.

Pro: Protocol-native, consistent with channel taxonomy, enables buyer agents to reason about commission-based inventory.
Con: Requires measurement infrastructure to attribute sale value and calculate payouts — more complex than fixed-price models.

---

Option B — Extend cpa-option.json with optional commission_rate

Make fixed_price optional and add commission_rate as an alternative, using oneOf:

"oneOf": [
  { "required": ["fixed_price"] },
  { "required": ["commission_rate"] }
]

Pro: Smaller change, reuses existing cpa model identifier.
Con: Breaks the discriminated-union pattern of the pricing model schema set. Validation tooling will struggle. Conflates two commercially distinct models under one identifier. Not recommended.

---

Option C — Treat as out-of-band (no protocol change)

Affiliate commission rates are negotiated between the advertiser and the affiliate network. AdCP only sees the resulting media buy (CPC/CPM on placements). The commission rate is not protocol-visible.

Pro: No schema change required. Works today.
Con: Leaves affiliate as a channel with no native pricing model, creating an internal consistency gap in the taxonomy. Buyer agents cannot reason about commission-based inventory natively.

---

Questions for the Working Group

1. Should the affiliate channel have a native AdCP pricing model, or is commission always a network-layer concern?
2. Who is the canonical AdCP seller in an affiliate relationship — the publisher, or the affiliate network?
3. If Option A: should revenue_share be scoped to affiliate channel products only, or available broadly (e.g. influencer, sponsored content)?
4. If Option A: what measurement provider declares the attributed sale value that governs billing? Does AdCP need to express this, or is it inherited from the network?

---

Affected Schema Files

• enums/pricing-model.json — new enum value revenue_share
• pricing-options/revenue-share-option.json — new schema (Option A only)
• pricing-options/cpa-option.json — if Option B
• docs/reference/media-channel-taxonomy.mdx — affiliate channel section
• docs/media-buy/advanced-topics/pricing-models.mdx — new model documentation

[bokelley]

Triage

Classification: Discussion
Bucket(s): spec / protocol
Status: ready-for-human
Milestone: Spec Backlog (#9)

What the experts said:

• ad-tech-protocol-expert: The gap is real and pre-existing — docs/reference/media-channel-taxonomy.mdx already describes affiliate's buying model as "CPA/CPC/rev-share," a claim the schema doesn't back today. Option A is the technically right shape (matches the discriminated-union pattern every other pricing-option file uses), but commission_rate (0–1) should be commission_pct (0–100) to match percent_of_media's existing convention. Also: Q2 ("who is the seller") isn't actually open — Aggregator Sales Agents (docs/media-buy/specification.mdx) + delegation_type: ad_network (adagents.mdx) + the retail_media precedent already establish networks as valid AdCP sellers.
• adtech-product-expert: Confirms the same doc/schema inconsistency, but no integration is blocked today — the cpc/cpm workaround matches how affiliate networks already invoice off-protocol. Option A carries real, non-trivial cost (order-value attribution, billing reconciliation lag, 30–90 day return-driven commission adjustments) that shouldn't be built speculatively.

My take: Both experts reject Option B outright and agree the taxonomy doc overpromises what the schema delivers — worth fixing regardless of what else happens. They split on urgency (ship revenue_share now vs. defer pending real demand), and since Q2 is already answered by existing precedent, the WG's actual decision is just A vs. C, and when.

Option A — add revenue_share pricing model:

{
  "pricing_model": "revenue_share",
  "event_type": "purchase",
  "commission_pct": 4,
  "currency": "USD"
}

New sibling pricing-option type; commission_pct (0–100) mirrors signal-pricing.json's percent_of_media, not the issue's 0–1 commission_rate.

Option B — extend cpa-option.json (rejected by both experts):

 "pricing_model": { "const": "cpa" },
 "fixed_price": { "type": "number" },
+"commission_rate": { "type": "number" }

Breaks the one-shape-per-discriminator-value invariant every other pricing-option file relies on.

Option C — status quo, out-of-band:

{
  "pricing_model": "cpc",
  "cpc": 0.85,
  "currency": "USD"
}

No schema change; commission stays a network-layer term — works today, as the reporter's own workaround shows.

@bokelley — the doc/schema inconsistency is real either way (taxonomy promises rev-share, schema has none) and worth a docs fix regardless. The open call is timing: ship revenue_share now, or soften the taxonomy doc and park Option A in Spec Backlog until an affiliate-network operator actually needs it natively?

---

Triaged by Claude Code. Session: https://claude.ai/code/cse_01E49uv4Ewst5d49s2z6jHnX

---

Generated by Claude Code