Repository navigation
[Change] § 5.2 — App identity on properties (store id / bundle id) for app_mobile and ctv inventory #15
Description
What kind of change?
Change a field's type or shape
Which section?
5.2 — Inventory composition
Field(s) involved
properties.available[]
Current text
properties.available[] items are { id, name, domains, supported_formats }.
Proposed text
Add an app identity to the property object, and require at least one of domains or apps:
{ id, name,
domains?: [...],
apps?: [{ store: ios | android | roku | fire_tv | samsung_tv | ..., store_id, bundle_id, developer_domain? }],
supported_formats }
Note in the field description that authorisation for app inventory resolves through app-ads.txt (published on the developer domain from the store listing), not through the property's domains.
Why
environments already enumerates app_mobile and ctv, but the only identity a property can carry is a web domain. In-app and CTV-app inventory is identified by store id / bundle id — that is what AdCOM, app-ads.txt, sellers.json and every DSP keying on the bid request use. Without it a buying agent cannot match an app line item to its brand-safety lists, run its app-ads.txt check, or join its own historical performance data, and the downstream OpenRTB app.bundle / Deals API line cannot be pre-filled from the proposal.
Knock-on effects
- §2.1 summary representation lists "property names"; it should list the app identifier too.
- Partly answers open question 7 (
environments[]validation):app_mobileandctvneed app identity to be validatable at all.
Would this break an implementation already built to this draft?
No — additive; domains keeps working for web properties.
Alternatives you considered and rejected
- Putting the bundle id in
content_detailorexternal_references[]: both are free-form, so buyers could not key on them reliably. - A separate
app_propertiesfield: splits one concept in two and forces the no-inheritance rule to be restated for each.
Concrete scenario
A CTV line item lists property { id: "weather-app", domains: ["exampleweather.com"] }. The buyer's agent runs its app-ads.txt check against the Roku channel id and has nothing to key on; the same line item, once agreed, cannot be handed to the DSP as an app.bundle deal.
You are commenting as
SSP — an in-app supply-side exchange (mobile + CTV) selling preferred-deal / private-auction / open-market inventory to buyer agents over AAMP and AdCP; we run the seller side of both today.
Before you submit
- I have read the draft section I am commenting on.
- This contains no confidential or commercially sensitive information.
Activity
Sirajmx commentedon Oct 6, 2026
Thank you for raising this.
We agree in principle. § 5.2 properties currently carry only web domains, so
app_mobileandctvinventory cannot be identified, verified againstapp-ads.txt, or carried into the downstream OpenRTB request.Rather than introduce new names, we propose aligning
apps[]with the OpenRTB 2.6appobject:As OpenRTB 2.6 defines
bundleas the store ID, it covers bothstore_idandbundle_idfrom your proposal.platformhas no OpenRTB equivalent and would be defined by OpenProposal.Draft PR #17 applies this to the § 5.2 property object and the CTV example. Appendix A is unaffected, as
appsis a key withinpropertiesrather than a new field. The PR will remain in draft until the working group confirms the disposition of this issue.This issue also bears on OQ-7 (#8):
app_mobileandctvcannot be validated against real inventory without an app identity.Sirajmx commentedon Oct 8, 2026
Related: #25 proposes buyer-supplied block lists, including an
app_bundleexclusion type. If app identity is added to properties as proposed here, the two should use the same app identifier.Make the app developer domain RECOMMENDED
unreconciled commentedon Oct 13, 2026
Agree with the direction in #17, and aligning on the OpenRTB 2.6
appobject is the right call. For CTV there is one case it does not cover yet: the party selling is often not the app owner.A FAST channel or content library is commonly distributed through several CTV apps at once, and under an inventory share the channel owner sells part of the ad time inside apps it does not own. In that case authorization runs through two files, not one. The app owner lists the channel owner's domain as an
inventorypartnerdomainin its app-ads.txt (ads.txt 1.1), and the channel owner's own ads.txt lists the sellers authorized for that share. OpenRTB 2.6 carries the same thing asapp.inventorypartnerdomain, and carries the channel and its parent network ascontent.channelandcontent.network, each withid,nameanddomain.With #17 as drafted, a channel owner can list every app its channel runs in, which helps. But a buying agent following the rule that authorization is checked through app-ads.txt on the developer domain will look only in the app owner's file, not find the channel owner's seller there, and conclude the line is unauthorized. Nothing on the property says whose channel it is either, so after agreement the deal carries the apps but not the channel the buyer actually chose.
Two suggested additions, both optional and both keyed to OpenRTB 2.6:
And one sentence for the authorization note: "Where
inventorypartnerdomainis present, authorization is checked through the app owner'sapp-ads.txtentry for that domain and then through theads.txton the inventory partner's domain."This would also partly answer the point in #17 that the object has no field in which a seller claims app-ads.txt authorization. For shared inventory,
inventorypartnerdomainis that claim, and a buyer can check it.Commenting in a personal capacity. Product leader in CTV, identity and data; I have led teams that built DSP bidding, household identity graphs, and CTV ad insertion and monetization platforms. I maintain OpenCTV, an open-source, non-commercial project on CTV ad delivery diagnostics.