[Change] § 5.3 — Say whether selected audiences combine as AND or OR, and how buyer segments and exclusions combine with them #91

What kind of change?

Change a field's type or shape

Which section?

5.3 — Audience reach

Current text

| `audiences` | Object | selectable | `available[]` of `{ id, name, taxonomy_ref, provenance, addressable_scale }`, `included[]`, `pricing` as `delta_cpm` per option, `max_select` |
| `buyer_supplied` | Object | supplied | `{ segments_allowed, suppression_allowed, match_rate_expected, segments[], suppression_list }`. `match_rate_expected` is the seller's stated expectation; `segments[]` and `suppression_list` are buyer-populated |

Proposed text

§ 5.3, in the `audiences` row, add `excludable` to each option
(OPTIONAL, default `false`) and `combine` to the object:
`combine: { allowed[], value }`. `allowed[]` holds `any`, `all`, or both.

Add after the § 5.3 table:

**Audience composition.** The line item targets users who match all of
the following conditions:

1. The seller audiences in effect: `selected[]`, or `included[]` when
   `selected[]` is absent, under the operator in effect: `combine.value`,
   or the only value in `combine.allowed[]`. `any` matches a user in at
   least one of them. `all` matches a user in every one. An empty set
   adds no condition.
2. At least one of `buyer_supplied.segments[]`, when that list is not
   empty.
3. None of the options in `excluded[]`.
4. Not in `buyer_supplied.suppression_list`.

When more than one seller audience can be in effect, the seller MUST
declare `combine.allowed[]`. When `allowed[]` holds both operators and
more than one seller audience is in effect, the buyer MUST write
`combine.value`, one of `allowed[]`. The buyer MUST NOT alter
`allowed[]`.

The buyer MAY write `excluded[]`: ids of options whose `excludable` is
`true`, disjoint from the seller audiences in effect. `max_select` does
not count them.

Audience deltas in `agreed_rate`, under either operator: every delta of
a seller audience in effect that is not in `included[]`, plus every
delta of an option in `excluded[]`.

`addressable_scale` and `availability` (§ 3.3) MUST be recomputed
against conditions 1 and 3. Conditions 2 and 4 need the buyer's data
matched first; until then, the figures for them are estimates.

Why

When a buyer selects two audiences, the draft never says whether the line item reaches people in either one (OR) or only people in both (AND). That choice decides what the buyer is buying. We ask the draft to make the operator an agreed term: the seller declares the operators it supports, and the buyer picks one.

Take § 6.2. A buyer selects ep:hnw-investors (1,100,000) and ep:cfo-finance-leaders (480,000), within max_select: 2. Read as OR, the line reaches up to 1,580,000; read as AND, at most 480,000. The #30 derivation prices both at 34.50, so 80,000 USD buys two different audiences, and the record can't show which.

Nor does the draft say how buyer_supplied.segments[] combine with seller audiences, and a buyer can't exclude a seller audience. § 3.3 recomputes scale with no rule to recompute by.

Production systems declare the operator: Google Ad Manager customTargeting (OR of AND sets, IS_NOT), Microsoft Invest segment groups, where the buyer picks the operator and data costs follow the operator, and the AAMP reference agents' intersect, union, and exclusion roles. Details: Audience composition: full rationale and examples.

Knock-on effects

• Builds on selected[] from #22 and amends its rule that selected[] is the only key the buyer writes: in audiences, the buyer also writes excluded[] and combine.value. combine follows [Change] § 3 — Name the key the buyer writes its selection to: selected[] on selectable fields, value on settable fields #22's settable pattern, allowed[] and value.
• Extends step 2 of the agreed_rate derivation in #30 to excluded[] options. Selected deltas sum under both operators, as [Change] § 5.6 — Give the buyer's counter a field (requested_rate), state how agreed_rate is derived, and say who can read floor and seller_rate #30 sums them across all selectable fields, so the rest of [Change] § 5.6 — Give the buyer's counter a field (requested_rate), state how agreed_rate is derived, and say who can read floor and seller_rate #30 is unchanged.
• § 6.2 gains combine, and excludable: true on any option the buyer may exclude. Appendix A and B are unchanged: these are keys inside existing fields.

Open questions for the working group

1. Should the draft define a default operator when combine is absent, for example any, so that this change isn't breaking, or require combine whenever more than one seller audience can be in effect, as proposed?
2. Answered in part by @peterduhon: AND is the only rule that holds across all three activation_route values; an operator declared per route may be closer to how production systems behave. Still open: should buyer segments always narrow the seller audiences (AND), as proposed, or should a later key let them extend reach (OR), as the extensions role in the AAMP reference agents' AudiencePlan wire format does?
3. Should excluding a seller audience add that option's delta to agreed_rate, as proposed and as Microsoft Invest charges for exclusion segments in its data cost, or should exclusion carry no charge?
4. Answered by @peterduhon: by its version-pinned reference, as [Change] §2.2, §3.1 — Freeze the buyer's selected[] into the committed artifact when a line item reaches agreed #160 (d) proposes. We'd name an option in excluded[] the same way. Our stack inlines the options and has no catalog_ref (§ 2.1, § 2.2, § 2.6, § 3 — Shared types and authoring rules (#121) #137). As posted: how should selected[] and excluded[] name an option given only as a catalog_ref: by the id that the issue on addressing a catalog_ref option (#9) asks the draft to define, or only after the reference is resolved?
5. Should excluded[] and the targeting exclude[] in our reply on targeting values (#58) share one name, or keep separate names because excluded[] picks among priced options and exclude[] narrows unpriced values?

Would this break an implementation already built to this draft?

Yes — breaking

Alternatives you considered and rejected

• OR only. Sellers would publish each intersection they sell as its own option.
• A free-form buyer-written Boolean expression. The seller can't declare a price for every expression up front.
• Only the highest delta under any. A second pricing rule beside [Change] § 5.6 — Give the buyer's counter a field (requested_rate), state how agreed_rate is derived, and say who can read floor and seller_rate #30's sum, and the rate would change with the buyer's operator.

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-12: question 2 marked answered in part and question 4 answered, from @peterduhon.

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