[Change] § 5.2, § 5.3 — Disclose audience taxonomy, data label, sensitive categories, and child-directed properties #97

What kind of change?

Change a field's type or shape

Which section?

Whole document / more than one section

Current text

§ 5.2: | `properties` | Object | selectable | `available[]` of `{ id, name, domains, supported_formats }`, `included[]`, `pricing`, `max_select` |

§ 5.3: | `audiences` | Object | selectable | `available[]` of `{ id, name, taxonomy_ref, provenance, addressable_scale }`, `included[]`, `pricing` as `delta_cpm` per option, `max_select` |

Proposed text

§ 5.3, in the `audiences` row, replace `taxonomy_ref, provenance` with
`taxonomy_ref, data_label, sensitive_categories[]`.

Add after the § 5.3 table:

**Audience disclosure.** Each option in `audiences.available[]` carries
these keys:

- `data_label`: REQUIRED. The option's IAB Tech Lab Data Transparency
  Standard 1.1 label: every field in its "Minimum Segment Disclosures:
  Required Fields" table, keyed by its API flat file key, with values
  exactly as the standard publishes them, such as `Observed/Known` or
  `TCF (Europe)`. A multi-select field is an array of those values. The
  standard's conditional rules apply: offline data sources require the
  Onboarder Details fields, and `Single domain / App` scope requires
  `originating_domain`.
- `taxonomy_ref`: REQUIRED. The integer from the OpenRTB segment
  taxonomies list for the IDs that name this option: `4` (IAB Tech Lab
  Audience Taxonomy 1.1) for the label's `taxonomy_id_list`, or the
  seller's registered vendor value (500 and up) for the label's
  `audience_id`. When the seller signals the segment in an OpenRTB 2.6
  request, these are the `data.ext.segtax` and `segment.id` values.
- `sensitive_categories[]`: REQUIRED. The categories the option's
  membership is derived from or reveals: `racial_or_ethnic_origin`,
  `political_opinions`, `religious_or_philosophical_beliefs`,
  `trade_union_membership`, `genetic`, `biometric`, `health`,
  `sex_life_or_sexual_orientation`, `precise_geolocation`, `minors`
  (under 18). An empty array declares none.

§ 5.2, in the `properties` row, add `child_audience, child_treatment` to
each `available[]` entry:

- `child_audience`: REQUIRED. `directed` (children are its primary
  audience under the law the seller applies, or its app store lists it
  for children only), `mixed` (directed to children but not as its
  primary audience, or listed for children and older users), or
  `general` (neither).
- `child_treatment`: REQUIRED when `mixed`. `excluded` (users identified
  as children don't receive the line item) or `contextual` (they receive
  it without personal data).

A line item with a `directed` entry in `properties.available[]` SHOULD
NOT carry `audiences`, and its `buyer_supplied.segments_allowed` and
`suppression_allowed` SHOULD be false. Where that property's app store
bars behavioral advertising (Apple's Kids Category, Google Play's
Families policies), the line item MUST NOT carry `audiences`, and both
flags MUST be false.

§ 2.1: add each property's `child_audience` to the summary.

Beyond these rules, this specification does not decide where an option
or a property may lawfully be used.

Why

provenance and taxonomy_ref have no defined values, so a buyer agent can't compare two sellers' audiences. We ask the draft to reuse the two IAB Tech Lab standards that already define them, and to add the two declarations they lack: sensitive data per audience, and child-directed status per property.

The § 6.2 example uses provenance: modeled and provenance: first_party. They answer different questions: how membership was decided, and whose data it is. The Data Transparency Standard 1.1 label answers both (audience_inclusion_methodology; audience_scope with provider_domain). It covers data sold "bundled with media" (Seller-defined Audience guidance). We ask for all its required fields, with its published values. Its taxonomy_id_list holds Audience Taxonomy 1.1 IDs, 4 in the segtax list. So taxonomy_ref needs only that integer, which OpenRTB 2.6 Data ext.segtax sets for Segment IDs.

Neither standard says whether membership reveals sensitive data, even for the taxonomy's Interest | Health and Medical Services nodes. GDPR Article 9, US state laws on sensitive data and minors, and the Digital Services Act bans on platforms' profiling-based ads (Articles 26(3) and 28(2)) all turn on it. A buyer agent needs the declaration before it commits.

minors says who a segment reveals; child_audience says who uses the property. The COPPA Rule allows behavioral ads to children with verifiable parental consent, given separately for third-party disclosure (§ 312.5(a)), so a directed property SHOULD carry no segments. Where app stores bar them, it MUST: Apple App Review Guideline 1.3 allows Kids Category apps only limited contextual third-party ads, and Google Play's Families policies bar interest-based advertising and remarketing in ads shown to children. The Rule also defines "mixed audience" services, which don't target children primarily. OpenRTB 2.6 regs.coppa arrives per request, after commitment; a buyer needs the status before.

#47 and #69 cover privacy around the segment; this covers the segment. Details: Audience and child-directed disclosure: full rationale and examples.

Knock-on effects

• § 6.2: the two inline options gain the keys and lose provenance, and the catalog entry carries them; both properties gain child_audience: general.
• With #64, a refreshed label is a new version.
• #48 types taxonomy_ref as a String; here it is a segtax integer, whose content analog is cattax.

Open questions for the working group

1. For a mixed property with child_treatment: contextual, should a line item that carries audiences or buyer segments be required to use excluded instead, or is serving children without personal data enough?
2. Should audiences and content name a taxonomy one way across the spec: with the OpenRTB integer, segtax for audiences as proposed here and cattax for content, or with a String, either the taxonomy reference that content categories with taxonomy_ref (#48) proposes or the prefixed IDs, such as "IAB-CT3.0:<id>", that buyer-supplied block lists (#25) use?
3. Should the record carry the full Data Transparency Standard label by value, as proposed, or only the provider domain, segtax, and segment ID plus a digest of the label in the Transparency Center?
4. Should sensitive_categories[] be a closed list of the ten proposed values, an extensible list, or a list that IAB Tech Lab maintains beside the Audience Taxonomy?
5. How should a Data Transparency Standard Purchase Intent modifier, such as 123|PIFI2, travel in an OpenRTB 2.6 segment.id: inside the ID as written, in a separate extension field, or not at all?

Would this break an implementation already built to this draft?

Yes — breaking

Alternatives you considered and rejected

• A pointer to the label in the Transparency Center. The agreed record would no longer be self-contained (§ 2.2).
• An OpenProposal enum for provenance. It would duplicate the Data Transparency Standard and drift from it.

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.

Analyzed and generated with the help of Claude, fully reviewed by me.