Skip to main content
Broadcast radio spots use the canonical audio_hosted format. They do not require a new canonical: the product narrows hosted audio to a fixed duration, file specification, loudness profile, and a single audio slot.

Reference format declarations

The following :15, :30, and :60 declarations use a common production profile: MP3, AAC, or WAV; 48 kHz stereo; at least 192 kbps where bitrate applies; and -16 LUFS/LKFS ±2 dB. A station or network may publish a different accepted profile. The canonical parameter is historically named audio_codecs, but its vocabulary includes the WAV container label. In these declarations, wav means that a WAV delivery file is accepted; a matching manifest reports container_format: "wav" and its underlying codec, normally codec: "pcm". Validators should compare the declared wav value with the asset container rather than reject the asset because its codec is PCM.

:15 spot

:30 spot

:60 spot

Creative identifiers

Use the manifest’s industry_identifiers list for the traffic or clearance identifier expected by the broadcaster. AdCP supports ad_id, isci, clearcast_clock, and idcrea; choose the identifier used by the applicable market and traffic system. Each duration cut should carry its own identifier.

No VAST or tracker semantics

The reference declarations contain only the required audio_main file slot. Terrestrial broadcast radio has no renderer in which a VAST/DAAST tag, impression pixel, click tracker, or clickthrough URL can operate. Their absence is part of the format contract; do not add tracker slots or represent these spots as audio_daast. Digital streaming or SSAI inventory is a separate execution context. It may use audio_hosted with explicitly declared impression, click, or other supported pixel_tracker slots. Standardized audio quartile and completion tag events use audio_daast. A terrestrial spot simulcast digitally does not make trackers operational on the terrestrial airing.

Delivery measurement and reconciliation

Radio plans, guarantees, and reconciles on measured audience — panel data (Nielsen Audio in the US, RAJAR in the UK), not served-event counts. Three declarations carry the whole contract:
  • Demographic notationdemographic_system on the CPP pricing option and forecast (e.g. nielsen_audio with demographic: "P25-54") says how the audience is written.
  • Provider identitymeasurement_source on forecast and delivery rows (e.g. nielsen_audio, rajar) says whose data produced the numbers. Notation and provider are separate declarations: RAJAR is a measurement_source, not a notation system.
  • Maturation — delayed panel publication reuses the existing measurement_windows contract (is_final, finalized_at), the same preliminary→final semantics broadcast uses for C3/C7. There is no separate phase vocabulary.
A buy committed to grps against P25-54 on nielsen_audio reconciles when the delivery row carries the same declarations:
Panel data arrives on the panel’s publication cycle — declare weekly (or coarser) in reporting_capabilities.available_reporting_frequencies, and buyers treat that cadence as an optimization-eligibility gate: nothing should mid-flight-optimize against numbers that publish weekly. Station affidavits and playout logs prove that scheduled spots aired; the audience currency turns those airings into the audience-size number. See Audio, Broadcast, and Creative manifests.