VASTlint
Validate

DAAST: Digital Audio Ad Serving Template

DAAST (Digital Audio Ad Serving Template) is the IAB specification that did for audio what VAST does for video: a standard XML response format for serving ads into streaming radio, music services, and podcast players. Released in 2014, it lived as a separate spec for four years before IAB Tech Lab folded audio support into VAST 4.1 and retired it.

You still meet DAAST in two places: legacy audio ad servers that never migrated, and validation work on old integrations. New audio work should target VAST 4.1+.

Why audio had its own template

Audio delivery breaks several assumptions video ad serving makes. There is often no screen: playback happens in a locked phone, a car dashboard, or a smart speaker. Viewability, the organizing metric of video, does not exist. Clicks are rare and sometimes impossible, so companion display and audible calls to action carry the response. And playback environments range from full apps to bare streaming protocols with no runtime at all.

DAAST encoded those differences while copying VAST's skeleton. An InLine or Wrapper response, Creatives containing Linear elements, MediaFiles pointing to audio assets, impression and quartile tracking. A VAST engineer could read a DAAST document without learning a new mental model, which is precisely why maintaining two parallel specs stopped making sense.

What VAST 4.1 absorbed

VAST 4.1 (2018) made three changes that ended DAAST:

  • The adType attribute on the <Ad> element, with values video, audio, and hybrid, so a response can declare itself audio-first and players can route it accordingly.
  • Audio MediaFiles as first-class citizens: audio MIME types (audio/mpeg, audio/aac, audio/ogg) in <MediaFile>, with the existing delivery, bitrate, and codec attributes.
  • Tracking semantics that tolerate screenless playback: the linear event model (start, quartiles, complete) works without any visual surface, and companion ads are optional accompaniments rather than expectations.

A minimal VAST 4.2 audio ad:

<VAST version="4.2">
  <Ad id="audio-1" adType="audio">
    <InLine>
      <AdSystem>ExampleAudioAdServer</AdSystem>
      <AdTitle>Podcast Mid-Roll 30s</AdTitle>
      <Impression><![CDATA[https://track.example.com/imp]]></Impression>
      <Creatives>
        <Creative>
          <UniversalAdId idRegistry="Ad-ID">CNPA0484000H</UniversalAdId>
          <Linear>
            <Duration>00:00:30</Duration>
            <MediaFiles>
              <MediaFile delivery="progressive" type="audio/mpeg" bitrate="128">
                <![CDATA[https://cdn.example.com/spots/midroll-30.mp3]]>
              </MediaFile>
            </MediaFiles>
            <TrackingEvents>
              <Tracking event="start"><![CDATA[https://track.example.com/start]]></Tracking>
              <Tracking event="complete"><![CDATA[https://track.example.com/complete]]></Tracking>
            </TrackingEvents>
          </Linear>
        </Creative>
      </Creatives>
    </InLine>
  </Ad>
</VAST>

Migrating a DAAST integration

DAAST conceptVAST 4.1+ equivalent
<DAAST> root element<VAST version="4.1"> (or later)
Audio ad declaration (implicit)<Ad adType="audio"> (explicit)
InLine / Wrapper structureIdentical
Audio MediaFilesIdentical, with standard VAST attributes
Impression and linear trackingIdentical event names
Companion display<CompanionAds>, optional

The migration is mostly a root-element and version-declaration change plus a review of anything vendor-specific that rode in Extensions. The structural concepts carry over one to one.

Does vastlint validate DAAST?

Yes. The vastlint core validates DAAST documents for legacy pipelines alongside VAST and VMAP, and validates VAST 4.1+ audio responses (including adType values and audio MIME types in MediaFiles) as ordinary VAST. See VMAP and DAAST validation in vastlint core and the rules reference.

Validate an audio VAST tag or a legacy DAAST response.Open the VAST tag validator →

Further reading