RFC: Support place-based audio as DOOH inventory, not screen-only or generic streaming audio

[bokelley]

Summary

AdCP can identify DOOH venues and audio inventory independently, but its normative vocabulary leaves audio-only inventory installed in physical venues between two classifications:

• dooh is described as screen-based inventory;
• streaming_audio describes online audio services rather than a physical venue context.

This creates an avoidable modeling gap for place-based digital audio: installed players/streams in taverns, grocery stores, convenience stores, gyms, and similar venues, where audio ads are inserted between music plays and delivery is reported as plays plus modeled audience.

Adopter case

A current operator supplied a catalog of roughly 5,800 installed radio/stream endpoints across taverns. Rows include a stable-looking source ID (STP), site name, address, latitude/longitude, geography, and stream metadata. The same operating model also covers grocery and US convenience-store portfolios.

These portfolios should preserve separate publisher identities. Tavern Media, SPAR, Circle K, and other venue-network owners each use their own publisher_domain, property catalog, and authorization relationship to the selling agent. The existing AdCP publisher/authorization graph already supports that; this RFC does not propose a network pseudo-publisher or a new inventory-source authorization model.

What already works

AdCP already has most required primitives:

• Property.property_type: dooh, radio, streaming_audio;
• property identifiers: venue_id, screen_id, openooh_venue_type, station_id, facility_id, network_id;
• publisher-scoped property_id and publisher_domain;
• publisher_properties selectors for all, by_id, and by_tag;
• canonical hosted/DAAST audio creative formats;
• OpenOOH venue taxonomy values for bars, grocery, convenience, fueling, and other physical environments;
• DOOH: Add structured selling-unit fields to placements (slot_duration, share_of_time, screen_resolution, delivery_unit) #5537 for reusable placement identifiers and DOOH placement facts;
• DOOH/OOH: Add structured geo fields to properties (coordinates, coverage polygon, venue-type counts) #5538 for placement location and aggregate venue geography.

A source ID such as STP can therefore map to venue_id when it identifies the venue, or to a placement identifier when it identifies the installed player/endpoint. Coordinates remain correctable location metadata, not identity.

The gap

Current schema descriptions make the otherwise-valid representation contradictory:

• property_type: "dooh" is described as “Digital out-of-home screen networks.”
• channel dooh is described as “Digital out-of-home screens in public spaces.”
• streaming_audio loses the physical venue, OpenOOH context, location, and place-based buying semantics.
• radio implies a broadcast station, which an installed venue stream/player is not.

Consequently, conformant sellers must either call an audio-only endpoint a screen or erase its physical context.

Proposed direction

Treat delivery context and creative medium as orthogonal:

• dooh means digital advertising inventory delivered in physical out-of-home venues, including visual, audio-only, and multimodal surfaces.
• The creative format declares whether the placement accepts audio_hosted, audio_daast, image, video, or another canonical format.
• dooh_placement_attributes fields remain optional; screen-only fields such as resolution are absent for audio-only placements.
• placement.identifiers[] and location from DOOH: Add structured selling-unit fields to placements (slot_duration, share_of_time, screen_resolution, delivery_unit) #5537/DOOH/OOH: Add structured geo fields to properties (coordinates, coverage polygon, venue-type counts) #5538 apply equally to screens and audio endpoints.
• audio_distribution_types may describe the underlying stream/feed when useful, but does not replace the dooh venue context.

Illustrative property:

{
  "property_id": "stp_12345",
  "property_type": "dooh",
  "name": "Example Tavern",
  "publisher_domain": "publisher.example",
  "identifiers": [
    { "type": "venue_id", "value": "STP-12345" },
    { "type": "openooh_venue_type", "value": "804" }
  ],
  "supported_channels": ["dooh"],
  "tags": ["tavern", "za-kzn"]
}

Illustrative placement:

{
  "kind": "seller_inline",
  "placement_id": "stp_12345_audio",
  "mode": "targetable",
  "identifiers": [
    { "type": "venue_id", "value": "STP-12345" }
  ],
  "format_ids": [
    {
      "agent_url": "https://creative.adcontextprotocol.org",
      "id": "audio_hosted"
    }
  ],
  "dooh_placement_attributes": {
    "location": {
      "lat": -29.8587,
      "lon": 31.0218,
      "address": {
        "country": "ZA",
        "region": "KZN"
      }
    }
  }
}

Requested changes

1. Generalize the dooh property-type and media-channel descriptions from screens to physical-venue digital inventory.
2. Document that DOOH placements may be audio-only and use canonical audio formats.
3. Ensure DOOH placement schemas do not require visual/screen attributes.
4. Add a place-based audio example covering property identity, publisher authorization, OpenOOH venue type, placement, location, product discovery, and proof-of-play reporting.
5. Clarify that publisher identity remains per venue-network owner; a sales agent representing multiple publishers resolves them through existing publisher_properties authorization.
6. Decide whether any additional reporting/pricing work is needed for play-based delivery, or whether existing flat-rate/metric primitives are sufficient. Keep that decision separate from property identity.

Non-goals

• No place_based_audio property type unless the WG rejects the orthogonal channel/format model.
• No network pseudo-publisher.
• No use of latitude/longitude as identity.
• No duplication of the location and placement-identity work in DOOH: Add structured selling-unit fields to placements (slot_duration, share_of_time, screen_resolution, delivery_unit) #5537 and DOOH/OOH: Add structured geo fields to properties (coordinates, coverage polygon, venue-type counts) #5538.
• No assumption that one operator owns every publisher portfolio it represents.

Related

• DOOH: Add structured selling-unit fields to placements (slot_duration, share_of_time, screen_resolution, delivery_unit) #5537 — placement identifiers and DOOH selling-unit fields
• DOOH/OOH: Add structured geo fields to properties (coordinates, coverage polygon, venue-type counts) #5538 — placement location and aggregate venue geography
• spec(creative): omnichannel canonical-format gaps (retail media, DOOH, reframing intent) #5546 / Canonical-formats roadmap beyond 3.1 — 5 un-annotated catalog categories needing canonical decisions #4663 — DOOH canonical-format gaps
• Wire enum gaps: creative-builder specialism, audio MediaChannel, cpv/vcpm pricing #3735 — generic audio channel discussion
• Add inventory_sources[] to adagents.json for network / retail-media / audience-network supply that is not a single owned domain #5321 — closed network-supply proposal; existing publisher authorization graph is the correct model

[bokelley]

Triage

Classification: RFC — Normative semantic clarification
Bucket(s): spec / protocol, schema, media-buy, creative
Status: ready-for-human

What the experts said:

• ad-tech-protocol-expert: Direction sound and consistent with OpenRTB 2.6 / OpenOOH precedent — "screens" in the current description is AdCP-narrowing, not an upstream normative exclusion; description changes are PATCH-eligible; one genuine MINOR gap: audio_distribution_type enum (modeled on OpenRTB audio.feed values 1–7) has no value for installed venue streams.
• adtech-product-expert: Credible adopter use case (Mood Media / Vibenomics analogues in production); schema already largely medium-agnostic (plays, flat_rate.DoohParameters.min_plays_per_hour, dooh_metrics.loop_plays); near-zero migration cost for existing DOOH sellers; one WG deliverable: a normative sentence distinguishing dooh (venue-installed device) from streaming_audio (user-owned device); Item 6 closes without new schema.

---

Decision memo DR-0010 (draft — pending WG ratification)

---
id: DR-0010
title: "dooh" property type and channel encompass physical-venue digital inventory regardless of creative medium
class: normative
status: recorded
date: 2026-07-15
refs: ["#5878", "#5537", "#5538", "#5546"]
dissent: none
---

## Decision

`property_type: "dooh"` and channel `dooh` apply to digital advertising
inventory delivered via a device physically installed in or at a venue,
regardless of creative medium. The creative format (`audio_hosted`,
`audio_daast`, image, video) determines the accepted medium; the property
type declares venue context. An installed venue audio player or stream is
`dooh`. An online streaming service on a user-owned device is
`streaming_audio`. A broadcast radio station is `radio`.

## Rationale

OpenRTB 2.6 §3.2.26 defines DOOH by venue context (not screen presence);
OpenOOH 1.0 venue taxonomy covers bars, grocery, and convenience stores
without requiring a screen. AdCP's "screen networks" / "screens in public
spaces" descriptions narrow beyond what upstream specs and market practice
support, creating a conformance gap for a real, operating inventory class.
The orthogonal delivery-context vs. creative-medium model is already
operative in AdCP's canonical-formats layer and this extends it to the
property-type and channel description layer.

## Implications

PATCH-eligible (3.0.x + main):
- enums/property-type.json: "Digital out-of-home screen networks,
  identified by network/venue IDs" → "Digital out-of-home venue networks
  — screens, audio players, and other installed surfaces — identified by
  network/venue IDs"
- enums/channels.json: "Digital out-of-home screens in public spaces" →
  "Digital out-of-home inventory in physical venues (screens, audio
  players, and other installed surfaces)"
- enums/identifier-types.json screen_id description: add "audio player or
  other addressable endpoint" alongside "screen"
- delivery-metrics.json plays description: remove "DOOH screen" specificity
- docs/creative/channels/dooh.mdx: add audio-only DOOH section with the
  property + placement examples from the RFC body
- docs/reference/media-channel-taxonomy.mdx: update dooh entry

MINOR (main / 3.1.x track only):
- enums/audio-distribution-type.json: add one value for installed venue
  streams (suggested: `in_venue_stream`; WG to confirm name). Without this,
  placement-level audio delivery context cannot be precisely declared via
  `audio_distribution_types`.

Play-based reporting (Item 6): no new schema. The `plays` +
`dooh_metrics.loop_plays` + `flat_rate.DoohParameters.min_plays_per_hour`
+ `estimated_impressions` pattern already expresses the plays × venue-
attendance-model = impressions idiom. Implementation note: sellers should
use `plays` as the raw count and `impressions` for the multiplied modeled-
audience figure; `DoohParameters` carries the floor and multiplier.

---

My take: Both experts converge; the RFC is protocol-sound with no spec-breaking changes. Three questions for WG to resolve before implementation proceeds: (1) confirm in_venue_stream (or provide the preferred name) for the new audio_distribution_type value; (2) confirm the PATCH-eligible description changes are eligible for 3.0.x under the playbook's errata test — the prior spec is demonstrably ambiguous on audio-only venue inventory, and any conformant 3.0.0 DOOH implementation would already satisfy the new language; (3) confirm that the plays + estimated_impressions + DoohParameters pattern is the normative idiom for play-based venue audio delivery, closing Item 6.

---

Triaged by Claude Code. Session: https://claude.ai/code/cse_01EN7wNd2XXCzypeWrATEYEQ

---

Generated by Claude Code

[bokelley]

Scope clarification from the adopter mapping

Checking the current 3.1 schemas against the place-based-audio use case narrowed the protocol question:

• plays already exists in both forecast and delivery metrics.
• flat_rate already supports DOOH allocation parameters including min_plays_per_hour.
• time already supports hour/day/week/month pricing.
• Products can expose multiple pricing options, and budgeted proposal/refinement handles known tiers and negotiated terms.

The adopter's current one-week rate cards can therefore use existing flat_rate or time options. Known budget/coverage tiers can be returned as distinct pricing options or proposals; this issue should not invent a place-based-audio pricing model.

The only possible residual is generic and should remain outside this RFC unless confirmed by an adopter: Package still has an impression-specific goal field and no canonical way for a buyer to request an exact non-impression quantity such as N plays. If the source contract proves that exact requested play quantity is required—rather than selecting a fixed/time package with a play guarantee—that deserves a separate generic package-quantity RFC.

For #5878, the actionable gap remains the channel/property semantics: audio-only physical-venue inventory should retain DOOH context while using canonical audio formats.