Repository navigation
[Change] § 5.5 — Buyer-supplied block lists (exclusions_accepted, exclusions) #25
Description
What kind of change?
Add a new field
Which section?
5.5 — Targeting envelope
Current text
n/a — new field
Proposed text
§ 5.5, two new rows:
| `exclusions_accepted` | Object | seller-set | What the seller can enforce: `{ types[], max_entries, enforcement, verification[] }` |
| `exclusions` | Object | supplied | The buyer's lists: `{ domain[], app_bundle[], iab_content_category[], keyword[], list_ref }` |Shape:
exclusions_accepted:
types: [domain, app_bundle, iab_content_category, keyword]
max_entries: { domain: 5000, keyword: 500 }
enforcement: { domain: pre_serve, iab_content_category: pre_serve, keyword: best_effort }
verification: ["ias", "doubleverify"] # optional, vendors who can attest
exclusions:
domain: ["example-gambling.example"] # or list_ref
app_bundle: []
iab_content_category: ["IAB-CT3.0:<id>"] # IAB Content Taxonomy ids
keyword: ["crypto"]
list_ref: { url: "<url>", sha256: "<hash>" } # for large listsRules:
- A buyer MUST NOT supply an exclusion type absent from
`exclusions_accepted.types`. A seller agent MUST reject it deterministically
rather than ignore it.
- `exclusions` are recompute inputs: `addressable_scale` and `availability`
MUST reflect them (§ 3.3).
- `best_effort` enforcement MUST NOT be presented as a guarantee.
- Exclusions are visible only to the counterparty on the issued proposal, as
they reveal buyer strategy (§ 5.8).
- `list_ref` MUST be hash-pinned, and resolved into the stored record at
`agreed`, as for `catalog_ref` (§ 2.2).Why
A buyer's brief often carries brand-safety constraints, such as no adjacency to gambling, cryptocurrency or competitor products. The draft cannot carry them into the commitment. The only exclusion field is the seller's advisory not_suitable_for[] (§ 4.2, non-normative), and creative_policy (§ 5.6) is the seller restricting the buyer's creative. There is nothing for the reverse: the buyer stating what its advertising must not run against.
The proposal follows the existing buyer_supplied pattern in § 5.3: the seller declares capability and the buyer supplies the data, so the lists resolve without a round trip. It does not let a buyer assume enforcement the seller cannot provide: keyword blocking on CTV or audio may not be enforceable, so the seller declares enforcement per type. It uses IAB taxonomies where they exist instead of free text.
Attendees at the 24 September 2026 Agentic Bootcamp flagged buyer-supplied domain, keyword and topic block lists as important and not yet in the specification.
Knock-on effects
- § 3.3:
exclusionsadded to the recompute inputs. - § 5.8: a note on the visibility of exclusions.
- Appendix A / B: two new rows and the marker counts.
- § 6: the display and CTV examples updated, with CTV showing
keywordas unsupported orbest_effort. - If a buyer needs enforcement guaranteed, that is a
committed_metricsand measurement question, deferred to 4.0.
Would this break an implementation already built to this draft?
No — additive or editorial
Alternatives you considered and rejected
- Extending
not_suitable_for[]: it is the seller's advisory guidance and non-normative. - Free-text exclusions: not machine-evaluable.
You are commenting as
Standards body / working group participant
Activity
fgranata commentedon Oct 8, 2026
Agree with the cross-reference from #15: if app identity lands on properties,
exclusions.app_bundle[]should carry the same identifier — the OpenRTB 2.6app.bundlevalue, exactly as draft PR #17 definesapps[].bundle(iOS numeric store id, Android package name, platform-native id elsewhere). That is what buyers' block lists already hold and what a seller agent can enforce at bid time without a mapping step.Two small notes from the seller side:
apps[].platform, make it optional rather than required.exclusions_accepted.enforcementper type is the right shape for in-app and CTV:app_bundleanddomainarepre_servefor us,keywordis at bestbest_efforton in-app and CTV inventory, so the per-type declaration lets a seller be honest about that instead of silently accepting the list.Commenting as an in-app / CTV supply-side exchange.
aleksUIX commentedon Oct 21, 2026
Could
exclusions.app_bundle[]retain the store namespace used by the app identity in #17?The iOS/Android example above covers two platforms, while #17 also supports Roku and other CTV stores. The app-ads.txt specification describes an app lookup key made from the store domain and canonical bundle or store ID. Keeping only the ID drops part of that identity.
As a constructed example, a buyer blocking
(roku, "123456")and another blocking(ios, "123456")would both sendapp_bundle: ["123456"]. The receiver cannot recover which scope the buyer intended. This is a namespace example, not a report of an observed store-ID collision.For 3.0, could exclusions match the qualified identity in
properties.available[].apps[], such as{ platform, bundle }, with the store namespace defined for each platform? Flat strings could remain usable when the list explicitly declares one namespace. An entry whose namespace cannot be determined should be rejected with a structured error, rather than guessed or applied across stores.That would keep the blocked app the same from the buyer's list through proposal validation to delivery.
Commenting in a personal capacity.
fgranata commentedon Oct 22, 2026
Agreed once CTV stores are in scope: a numeric Roku channel id and an iOS store id can collide, so the qualified
{ platform, bundle }form from #17 is the right entry forexclusions.app_bundle[]. The flat string can stay as a convenience only where the list declares a single namespace, and an entry whose namespace cannot be determined should be rejected with a structured error rather than applied across stores. That keeps the blocked app identical from the buyer's list through validation to delivery.Commenting as an in-app / CTV supply-side exchange.
Restore iab_content_category as filed