interactiveadvertisingbureau / vast Goto Github PK

Video Ad Serving Template (VAST)

License: Other

HTML 100.00%

vast's Introduction

vast

Digital Video Ad Serving Template

The IAB’s Video Ad Serving Template (VAST) specification is a universal XML schema for serving ads to digital video players, and describes expected video player behavior when executing VAST-formatted ad responses. VAST opens up the in-stream digital video advertising marketplace and reduces expensive technical barriers,encouraging advertisers to increase video ad spend.

VAST4 was released in January of 2016. With the proliferation of devices and screen sizes over the last few years, this release was focussed on meeting the challenges around delivering video ads efficiently to this wide variety of devices. This included features like separation of media files from verification and interactive code, a mezzanine file for server side ad insertion, etc.

VAST 4.1 was released in November 2018 with support for Ad Requests, Ad verification with Open Measurement, integration of DAAST for Audio ads, etc.

VAST 4.2 was released in June 2019 with support for interactivity with SIMID (https://github.com/InteractiveAdvertisingBureau/SIMID/).

For more information about the VAST specification, visit the Digital Video Ad Serving Template page on the IAB TechLab website.

For the latest set of VAST4 macros, please visit http://interactiveadvertisingbureau.github.io/vast/vast4macros/vast4-macros-latest.html

Other VAST Resources

vast's People

Contributors

Stargazers

Watchers

Forkers

bschlehuber appodeal ibrahimennafaa tusharbz ownerhzh psniranjan jucrouzet phstudy ademartini rajverve jeanfrancois-lai marcsantiago pykita pietermees hotmobjackson epicdevs aaronice sebastian-weiss ajitdhalnielsen jeffreycarlson andrewwinter77 misbarku zhxinx crazyalien jan-bednar eisglace bhanditz damirtm suroin arnaudcasame emonmishra iloveilmare im-ade vladimirpodmogilnyi isss1650 switch-media gdchb vpon-sdk zgb7mtr bobskigit ressmann onlynishant mimidden terrorizer1980 reuvenk neririchter mizhidan joakim-ribier isabella232 wiem-belkhiri tmdbckr schhabra-tpg kkeyanb thinlabs likelifeitself jaiclan momotoculteur frankfanslc apalady sgonzalez-pluto pedropinheiro alebastrov fabiant7t lamrowena

vast's Issues

Add VAST 4.2 constant to VASTVERSIONS macro

http://interactiveadvertisingbureau.github.io/vast/vast4macros/vast4-macros-latest.html#macro-spec-vastversions

We should have another constant for vast 4.2 support.

VAST 4.2 missing notUsed event type

The 4.2 spec shows "notUsed" as a valid event type for Tracking event. Is it possible to get this added to the xsd?

HTMLResource description incorrectly specifies URI requirement

HTMLResource description specifies that it should contain a URI instead of an html snippet/document.

Examples

My understanding is that HTMLResource should look something like:

<HTMLResource><![CDATA[<html><body>I'm a companion</body></html>]]></HTMLResource>

Where as the IFrameResource would be a remote resource:

<IFrameResource><![CDATA[http://adserver.com/htmlresourcefile.htm]]></IFrameResource>

Also

There are a few places that this would need to change, such as section 3.15.

I see this bug:
#6

Which also mentions HTMLResource and a HTMLResourceType but I couldn't find the latter mentioned in the current spec.

Attributes in UniversalAdId are not marked as required

UniveralAdId is missing Attribute use=required.

Reported via Mayank

VAST Macros - fix INVENTORYSTATE example is incorrect

The examples for INVENTORYSTATE includes autoplayed, fullscreen.
fullscreen is not a valid state.

Corrections for VAST4.xsd

From VAST 4.0 documentation:

Section 3.10.1: ClickThrough bounded 0-1 (if is used), but now VideoClicks_InlineChild_type can has collection of ClickThrough elements
Section 3.7.3: CreativeExtension element: new attribute 'type' - The MIME type of any code that might be included in the extension.
Section 3.15.3: HTMLResource element: HTMLResourceType now haven't attribute "xmlEncoded", that must be only String with CDATA.
Section 3.4.1: AdSystem element: must be required in response, if its parent is 'InLine' element
Section 3.4.4: Category element: bounded 0+, but now we can set only one category
Section 3.7.1: UniversalAdId element: attributes idRegistry and idValue must be required
Section 3.9.2: Mezzanine element: can be simplified to CDATA-string element (now it is complexType), because it hasn't any attributes
Section 3.9.1: MediaFile element: attribute 'adaptiveStreaming' must be removed
Section 3.11: Icons element: now it can be in Wrapper element too, but now we have it only in Linear element.
Section 3.11.1: Icon element: attributes 'program', 'width', 'height', 'xPosition', 'yPosition' must be not required.
Sections 3.11.4 and 3.11.5: IconClickThrough and IconClickTracking elements now are confused: IconClickThrough must have only String body with CDATA and IconClickTracking can have attribute 'id'
Section 3.11.2: IconViewTracking element can't have attribute 'id', it is only URI string with CDATA. IconTrackingUri_type is redudant
Section 3.13.4: CompanionClickTracking element: must have 'id' attribute, but now it is simple String
Section 3.19.1: VASTAdTagURI element: can be simplified to String with CDATA, now it is complex type
Section 3.19: Wrapper element: sub-elemnt 'Creatives' is not required
Please, rename 'Verification_type' to 'VerificationWrapper_type'

Inline order of elements does not respect IAB latest specs

Looks like the order of the inline element does not follow the IAB latest specs.

I have the following sequence

Adswizz

... IAB24 ... www.dunkindonuts.com ... ...

And I get the following error when validating against the xsd
Not valid.
Error - Line 5, 10: org.xml.sax.SAXParseException; lineNumber: 5; columnNumber: 10; cvc-complex-type.2.4.a: Invalid content was found starting with element 'AdTitle'. One of '{"http://www.iab.com/VAST":Error, "http://www.iab.com/VAST":Extensions, "http://www.iab.com/VAST":Impression}' is expected.

Is it valid to have a creative element within a wrapper element in vast3 and vast4 spec?

A customer set up a campaign (declared as vast4) with a creative (linear) and also Mediafiles inside of a vast wrapper having also a VASTAdTagURI redirecting to another xml which also has linear creatives.
We have a discussion and I want to make sure I got the specs right.

vast/vast_4.2.xsd

Line 21 in f28dbb4

    
           <xs:element name="Wrapper" minOccurs="0" maxOccurs="1" type="vast:Wrapper_type">

vast/vast3_draft.xsd

Line 279 in f28dbb4

    
           <xs:documentation>Second-level element surrounding wrapper ad pointing to Secondary ad server.</xs:documentation>

I see creative elements inside of the wrapper element in the specification of vast3 but not in vast4. But I have a lack of fantasy what a player should do with two linear creative elements (one from the wrapper and one from the redirect). My question: Are creatives valid inside of a wrapper? In the case of VAST3 what could be the intended behavior of the player?

NonLinearClickTracking in vast 4.2 is changed to only occur once

In 4.2 XSD schema, it's changed but the annotation said it could occur many times(unbounded), which is confusing. What's more, current schema could be not backward-compatible due to this change.

Also, the same annotation is found for ClickThrough.

Should we just modify XSD schema to make NonLinearClickTracking and ClickThrough to reflect the annotation?

<xs:element name="NonLinearClickTracking" minOccurs="0" maxOccurs="1">
        <xs:annotation>
          <xs:documentation>URLs to ping when user clicks on the the non-linear ad unit. This can occur zero to many times (unbounded). The XSD syntax can't represent that.</xs:documentation>
        </xs:annotation>

altText and hoverText Icon attributes missing from VAST 4.2 XSD

The altText and hoverText attributes for an element (which were added in some version of VAST 4.2) are not declared in the vast 4.2 XSD document (inside the "Icon_type" definition)

Note that I'm not referring to the node beneath which IS included, I'm only referring to the attribute(s) of the node.

Lets add 2 more examples to vast macro CLIENTUA

The spec isn't specific in what to do in 2 cases.

See http://interactiveadvertisingbureau.github.io/vast/vast4macros/vast4-macros-latest.html#macro-spec-clientua

If you have the client player but no plugin.

I suggest no delimiter, example.

MyPlayer/1.23.4

If you have no version.

I suggest no delimiter.

MyPlayer MyPlugin/1.2.3

I suggest we add these two examples to that section so we are on the same page.

Clarify support for Simid Wrapper

The vast specification is not very clear if it should be possible to have a SIMID creative inside a vast Wrapper, while the actual MediaFile (e.g. an mp4 video) should be served from the wrapped vast tag.

Right now googles ImaSdk for example is not supporting it. They also seem to not be sure if that should be supported according to the vast spec or not.

here is an example of a vast wrapper which I would expect to show the simid ad and the mp4:
https://assets.redpineapplemedia.com/vast/simid-wrapper/simid-wrapper.xml
Currently, when showing this wrapper in googles imasdk the simid is not shown:
https://googleads.github.io/googleads-ima-html5/vsi/?tag=https%253A%252F%252Fassets.redpineapplemedia.com%252Fvast%252Fsimid-wrapper%252Fsimid-wrapper.xml

Here is an other example where the SIMID and the video mp4 are in the same vast tag (no wrapper), just to show the expected result:
https://googleads.github.io/googleads-ima-html5/vsi/?tag=https%253A%252F%252Fassets.redpineapplemedia.com%252Fvast%252Fsimid-wrapper%252Fsimid-vast.xml

Could you clarify if this should be supported by the spec? If currently not: could you consider adding support for this case in the next vast version?

this is a test issue again

Need to update VAST4 with newer codec spec reference

Posting for Tay @ itv

Hi Amit,
Greetings from the UK. I am working with a group of European broadcasters to ratify VAST as the interoperability standard for commercial TV. We have noticed that VAST 4.1 and VAST 4.2 are referencing obsolete reference: http://tools.ietf.org/html/rfc4281 (VAST 4.1 p53 and p54)
This has been superseded by https://tools.ietf.org/html/rfc6381
We'd appreciate if you could correct this for future releases.
Best regards,
Tay

VAST 3.0 CompanionClickTracking for inline ads

I noticed that the current schema is still on a _draft and it does not consider the <CompanionClickTracking> for inline ads. Is the schema something you guys will update for a final version? Should we use it as a validator to guarantee the format of the VAST 3.0 spec?

New VAST Macros Proposal: Continuous Play

The industry seeks to better differentiate between valid binge behavior and endless back-to-back ads with no viewers. This is particularly sensitive in lean-back environments such as CTV where a streaming device may be active while the screen is turned off or in another input.

Identifying this behavior has specifically been a part of the IAB Digital Video Impression Measurement Guidelines since 2018: “...to the extent that the video content itself (inclusive of advertising) is played without user interaction (Continuous Play) this should be disclosed to users of measurement data including disclosure of the parameters and settings to the extent known by measurement organizations“. Link to this language: http://mediaratingcouncil.org/Digital%20Video%20Served%20Impression%20Measurement%20Guidelines%20(MMTF%20June%202018).pdf

To help identify environments where ads may play endlessly without users present, DoubleVerify proposes two self-declared identifiers for passing seconds since the user last interacted with an environment and whether the environment autoplays content without user interaction.

There are two proposed macros:

TIMESINCEINTERACTION: The time since the user last interacted with the device or app controls. This includes any user interaction with the environment including opening the app, clicking to play a video, muting, and pausing. Any interaction that a user directly drives should be counted. Any automatic functions should not be counted - e.g. auto play of a video.
CONTINUOUSPLAY: Identifies if an environment is set to play additional videos automatically without user interaction after the end of the current video.

Please see the attached document for further details on these macros.

DV_Continuous Play Proposal_ Aug 2020.pdf

Missing Attribute "vendor" in element Verification.

Probably in one of the declaration of Verification element(may be for "Verification_Inline_type") we missed to include attribute "vendor".

Vast 3 maxOccurs of <Error> and <Error> at root

Issue 1

vast/vast3_draft.xsd

Line 80 in dac1274

<xs:element name="Error" minOccurs="0" maxOccurs="1" type="xs:anyURI">

Please clarify:

Vast 3 final spec (https://www.iab.com/wp-content/uploads/2015/06/VASTv3_0.pdf), section "2.2.4.2 Optional InLine Elements" states:

<Error>: a URI representing an error-tracking pixel; this element can occur multiple times. Errors are defined in section 2.4.2.3.

If I'm interpreting this correctly, this would seem to indicate that the maxOccurs should be "unbounded" in the xsd, not "1" -- similar to the <Impression> element.

Also, while not explicit in the spec, I would imagine, the <Error> inside the <Wrapper> would match:

vast/vast3_draft.xsd

Line 293 in dac1274

<xs:element name="Error" minOccurs="0" maxOccurs="1" type="xs:anyURI">

Issue 2

There should be an <Error> element defined at the root element. See section "6 Human Readable VAST XML Schema" in the spec as well as "2.2.5.1 Summary of VAST Tracking Elements".

VAST 3.0 Creatives required under Wrapper

The VAST 3.0 schema considers the following XML to be valid:

<VAST version="3.0">
    <Ad>
        <Wrapper>
            <AdSystem>prebid.org vastUrl redirect wrapper</AdSystem>
            <VASTAdTagURI>http://www.google.com</VASTAdTagURI>
            <Impression>www.my-tracking.url.com</Impression>
            <Creatives></Creatives>
        </Wrapper>
    </Ad>
</VAST>

It also considers the following XML to be invalid:

<VAST version="3.0">
    <Ad>
        <Wrapper>
            <AdSystem>prebid.org vastUrl redirect wrapper</AdSystem>
            <VASTAdTagURI>http://www.google.com</VASTAdTagURI>
            <Impression>www.my-tracking-url.com</Impression>
        </Wrapper>
    </Ad>
</VAST>

The only difference is the empty "Creatives" tag.

In section 2.4.11, the PDF spec says:

Three optional elements are also available:

<Creatives>: Contains a creative element, which describe the Wrapper Ad creative

Given this, I would expect the opposite behavior. It seems like XML with no Creatives tag should be valid, but XML with an empty Creatives tag should be invalid. (XML with a Creatives tag containing a single element should also be valid).

VAST Macros STOREURL example incorrect

STOREURL is incorrect for Android and Roku. The examples should be URLs. (Pick it up from the OTT/CTV app store id guidance doc)

why is VAST is xsd:sequence rather than xsd:all?

Can someone explain why the XSD's use xsd:sequence rather than xsd:all and so enforce the ordering of the elements? I cannot think of a technical reason (alphabetical means the reasoning is not for SAX and optimising reading in for RTB) so it would be helpful to know why this constraint is present?

#9 hints that it is desirable (though I cannot see anything in the VAST 4.1 spec stating alphabetical ordering is required) but I cannot see anywhere why. grep'ing the project also shows nothing but a statement in the release notes that this will be done but lacks the 'why'.

As I cannot find any explaination was this just a cosmetic reason? If so it needlessly makes creating VAST documents trickier and definately something that can trip up newcomers to VAST and is something I think most (including myself) find unexpected.

Looking forward to hearding the why, maybe it could be made into an IAB pub quiz question!

VAST Macros STOREURL and STOREID unobtainable on iOS/tvOS

On iOS/tvOS, there is no API for retrieving the app's App Store ID (e.g. 886445756). So this information would have to be provided by the app developer at their word, which is problematic for brand safety purposes. Likewise for the App Store URL.

This is in contrast to the bundle ID (e.g. com.example.app) which is retrievable directly (by say an ads SDK), and also uniquely identifies the app, which is robust for brand safety purposes.

I'd like to know more about the intention/use case for adding these macros, and if we can solve the issue by using the existing APPBUNDLE macro. For instance, Apple's App Store search API allows you to match bundle IDs to App Store IDs. This makes sense to do server-side, offline, but is prohibitive to gate ad display on, client-side.