Repository navigation
[Change] § 5.6, § 1.1, § 2.1 — Say which price a deal carries: agreed_rate as the Deals API dealfloor, with its pricetype; rename floor to min_rate #133
Description
What kind of change?
Add a new field
Which section?
5.6 — Commercial terms
Current text
§ 5.6:
| `pricing[].gross_rate` | Number | seller-set | The list rate the buyer pays |
| `pricing[].agreed_rate` | Number | derived | The transacted rate after selections and any agreed request |
| `pricing[].currency` | String | seller-set | ISO-4217 |
| `pricing[].floor` | Number | seller-set | OPTIONAL. The lowest rate the seller will consider. Enables a `requestable` counter to be evaluated without a round trip |
§ 2.1, Summary Representation, per line item:
`pricing.cost_method` · `pricing.gross_rate` ·Proposed text
Our handoff PR carries this text, with the handoff table of our deal handoff change request (#132), and closes both. The min_rate row and list_rate, which renames gross_rate, come from our buyer writes PR. The Required column and the Amount type come from our shared types PR.
§ 5.6, after the `pricing[].currency` row:
| `pricing[].price_type` | Integer | REQUIRED when the entry prices a deal mechanism | seller-set | How `agreed_rate` clears, as Deals API 1.0 `terms.pricetype`: Dynamic (0), the auction type of each bid request; First Price (1); Second Price Plus (2); Fixed Price (3); or an exchange-specific value, 500 and up |
§ 5.6, replace the `pricing[].floor` row:
| `pricing[].min_rate` | Amount | OPTIONAL | seller-set | A hint: the lowest `list_rate` the seller says it will consider. It grants nothing. Not a term, not the downstream auction floor, and never sent downstream |
§ 5.6, after the `agreed_rate` formula:
**Deal price.** For a deal on a `CPM` entry (§ 1.1), the committed entry's
`agreed_rate` is the deal's price per thousand impressions, in that entry's
`currency`. Under Fixed Price (3), it is the price the buyer pays. Under an
auction `price_type`, it is the deal's minimum bid. The Deals API treats it as
guidance: per-impression floors can be higher, so a bid at `agreed_rate` is not
guaranteed to clear.
§ 1.1, Deals API handoff table, add:
| Deals API 1.0 | OpenRTB 2.6 | From the agreed line item |
| :--- | :--- | :--- |
| `terms.dealfloor` | `Deal.bidfloor` | `agreed_rate` of the committed `pricing[]` entry |
| `terms.cur` | `Deal.bidfloorcur` | That entry's `currency`, always sent |
| `terms.pricetype` | `Deal.at`, the same value, omitted for Dynamic (0) | That entry's `price_type`, always sent |
| `terms.guar` | `Deal.guar` | `1` when the mechanism in effect is `programmatic_guaranteed`, `0` otherwise |
| `terms.units` | | `commitment.amount` when `basis` is `units`, otherwise `derived_units` (§ 5.6.5) |
| `terms.totalcost` | | The seller total (§ 5.6.5) |
§ 1.1, after the table:
`terms.dealfloor` and `Deal.bidfloor` are prices per thousand impressions, so
this table maps a `CPM` entry. Other cost methods have no mapping yet.
§ 2.1, Summary Representation: add `pricing[].price_type`.Why
For a deal, the draft never says which of its four rates goes downstream. We ask it to say: agreed_rate, with a price_type that says whether it's a fixed price or a minimum bid, as the Deals API does.
The Deals API 1.0 Terms carries one price, dealfloor: "Minimum bid … Unless pricetype is Fixed, this should be used as guidance". pricetype says which. OpenRTB 2.6 Deal pairs bidfloor with at the same way: under at 3, bidfloor "is the agreed upon deal price". Both are CPM.
@fgranata (#19) and @VJAlkimi (#30) already read the mapping this way: the Deals API line carries the agreed rate. The text doesn't say so, and a mapper that matches names sends floor. In the display example, that sends 21.00 for a 24.00 guaranteed deal. In the CTV example, a private auction, the deal floor becomes the 39.60 offer floor, not the derived 45.00. @Sirajmx's PR #18 clarifies that floor is "not the downstream auction floor". This request names the field that is. It renames floor to min_rate, to match list_rate and agreed_rate and stay clear of bidfloor and dealfloor.
transaction_mechanism doesn't give a private auction's auction type, which the Deals API needs. An absent pricetype defaults to Second Price Plus (2). Every entry that prices a deal mechanism states price_type, so the default never applies. The Deal price paragraph covers @fgranata's scenario in #16: bids at the agreed price lose to a higher exchange floor.
guar, units, and totalcost follow from fields OpenProposal has. Under our delivery type change request (#93), programmatic_guaranteed is guaranteed or share_of_voice, and the other deal mechanisms are non_guaranteed.
Details: Deals API alignment: full crosswalk
Knock-on effects
min_rateis not a term, so our signing PR keeps it out of the agreed record.- Whether a rate request at or above
min_ratemust be granted is a rule we left out of the text. The rules issue asks whether implementers need it. terms.totalcostis the seller total of our pricing PR. Whatcommitment.amountincludes is open in @dineshbhat's #115.
Open questions for the working group
- Answered by our handoff PR. A line item that offers
preferred_dealandprivate_auctionmay need two price types. Eachpricing[]entry states its ownprice_type. It names the mechanisms it prices intransaction_mechanisms[], from our pricing PR, which closes our cost-method change request (#94). - Answered in part by our handoff PR: the Deals API mapping covers a
CPMentry, and other cost methods have no mapping yet. Still open: may a flat-priced programmatic guaranteed deal send onlytotalcostandunits? Our cost-method change request (#94) lists the other cost methods, and the rules issue lists the strict option: deal entries MUST beCPM. - Should
programmatic_guaranteedrequire Fixed Price (3)? The Deals API says a price "must be provided if the deal is a fixed price deal, especially if it's a programmatic guaranteed deal". It doesn't require the pairing. We left theprice_typevalues each mechanism allows out of the text. The rules issue asks whether implementers need them. - Answered by our buyer writes PR. We asked whether
min_rateis the right name for the field that replacespricing[].floor(§ 5.6), or another, such asoffer_floor. The PR landsmin_rate.
Would this break an implementation already built to this draft?
Yes — breaking
Alternatives you considered and rejected
- Map
min_ratetodealfloor. It sends the seller's hint, below the agreed price. - Derive
price_typefromtransaction_mechanism. A private auction can run first price, second price, or dynamic, so the mechanism doesn't say which. - String values, such as
first_price. The Deals API and OpenRTB use the integers, and the 500 range needs no registry. Our placement PR (#120) carries AdCOM integer codes the same way. - Keep
flooras a deprecated alias. Two names for one value can disagree.
You are commenting as
Other — IAB Tech Lab member (Postindustria).
Before you submit
- I have read CONTRIBUTING.md and agree my contribution may be published under this repository's licence.
- This contains no confidential or commercially sensitive information.
Revised 2026-11-03: Rewritten against our handoff PR, which closes this issue: price_type, list_rate, and a min_rate hint that replaces floor with no deprecation. It answers open questions 1 and 4, and 2 in part, and moves two rules to the rules issue.
Analyzed and generated with the help of Claude, fully reviewed by me.
Activity
davidsands11 commentedon Oct 31, 2026
This proposal highlights the importance of accurately defining and transmitting advertising pricing information across programmatic systems.
However, a critical financial accountability question remains unanswered:
Why are advertising intermediaries developing increasingly precise standards for exchanging pricing and financial information among themselves without establishing an equivalent mandatory right for intellectual property owners to independently verify the revenue generated from their inventory?
This advertising architecture cannot continue to operate on the premise that intermediaries control both the monetization of intellectual property and the financial records necessary to determine what its owners are owed.
Such an arrangement creates serious financial accountability concerns and raises substantial red flags regarding potential underpayments, undisclosed revenue retention, deceptive accounting, and other conduct that may carry civil, regulatory, and, where intentional fraud is established, criminal consequences.
The persistent withholding of financial reconciliation records raises a fundamental question of intentionality: Why would an intermediary that can calculate, invoice, and collect advertising revenue refuse to permit the intellectual property owner to independently verify the amounts generated and contractually owed?
An even more fundamental question follows:
What legitimate justification exists for requiring an intermediary to remain in the monetization path when that intermediary is supposed to serve the rights holder but is not subject to mandatory independent financial accountability?
Intellectual property rights holders must have the ability to establish direct commercial relationships with advertising buyers, as web publishers can, without being compelled to surrender control over monetization or financial visibility to an intermediary.
Intermediaries may provide valuable services, but their participation must be a commercial choice—not an unavoidable condition of monetizing intellectual property.
Where an intermediary cannot demonstrate transparent, independently verifiable financial accountability, the justification for its continued position between the advertising buyer and the rights holder must be open to serious scrutiny.
Confidentiality and proprietary technology cannot serve as blanket justifications for denying meaningful independent financial verification.
Rights holders must have mandatory, direct, independent, real-time access to complete underlying advertising transaction and financial records—not delayed, filtered, aggregated, or intermediary-controlled dashboards.
All programmatic advertising activity involving intellectual property must be subject to continuous, independent financial transparency and retrospective auditability. No intermediary, platform, or technology provider should be permitted to restrict, obscure, or selectively disclose the records necessary to verify rights-holder compensation.
This is not simply a technical standards issue. It is a fundamental question of financial accountability, competition, legal compliance, and whether the architecture of programmatic advertising permits intellectual property owners to discover and challenge potential wrongdoing.
IAB Tech Lab must directly confront this structural accountability gap. Continuing to standardize advertising transactions while leaving rights holders without independent financial verification invites serious scrutiny by the U.S. Department of Justice, Federal Trade Commission, and relevant U.S. Senate committees. Where investigations establish deceptive conduct, unlawful revenue diversion, anticompetitive practices, or intentional fraud, the consequences may include substantial civil liability, regulatory enforcement, and criminal prosecution where applicable law permits.
Will IAB Tech Lab establish mandatory real-time financial transparency, retrospective independent audit rights, and the ability for intellectual property owners to transact directly with advertising buyers—or will these fundamental accountability failures remain unresolved until federal enforcement and congressional oversight intervene?