VASTはどのように動作するか
VASTは当初、動画広告における標準的な広告レスポンスの取り扱いを円滑にする目的で設計された。しかし今や、ビデオプレイヤーが動画広告レスポンスをどのように取り扱うべきかにまでその内容が及ぶことを期待されるにいたっている。VASTの最新バージョンは、ビデオプレイヤーによってVAST広告がどのように表示され、どのようにトラッキングされるべきかのガイドラインを提供することによって、それらを標準化している。
VASTはビデオプレイヤーについても規定しており、その範囲は、ビデオプレイヤーが動画広告をリクエストし、そのVASTレスポンスを表示し、そして広告インプレッションやその他のイベントのトラッキング情報をサーバに送るプロセス全体に及ぶ。一般的に、動画広告の配信プロセスはこれらのVASTの内容によってサポートされる。この通信プロセスは、ビデオプレイヤーと１つの（普通はパブリッシャーの）アドサーバ間で直接的に完結する場合もあるし、ビデオプレイヤーと複数のアドサーバ間で行われる場合もある。
パブリッシャーのシステムからビデオプレイヤーに広告が直接配信される時、VASTの広告配信プロセスは以下のようになる。
★TODO 図
- VAST Request: ビデオプレイヤーが、アドサーバへVASTレスポンスの呼び出しを行う。
- VAST inline Response: アドサーバは、広告の表示とトラッキングに必要な全てのメディアファイルとトラッキングのURIを収めたVASTのインライン・レスポンスを返す。
- Tracking URIs Pinged ビデオプレイヤーは、配信・表示された広告上で発生するイベントに紐付いたトラッキングURIリソース（訳注：ピクセルのimgタグとか）にリクエストを投げる。
このシナリオでは、アドサーバが１つだけ登場する。VASTのキャンペーンの内容がパブリッシャーのアドサーバに直接記述されている場合は、通常はこのようなシナリオとなる。（訳注：この１つのアドサーバしか登場しないシナリオでは大してVASTのありがたみが感じられないが）複数のアドサーバが動画広告の配信プロセスを構成するような場合に、よりVASTのありがたみが出てくる。
以下の図は、セカンダリ・アドサーバが登場する時の広告配信のプロセスを描いている。
★TODO 図
- VAST Request: ビデオプレイヤーが、プライマリ・アドサーバへVASTレスポンスの呼び出しを行う。
- VAST Redirect: キャンペーンがセットアップされている間、広告パーティ（エージェンシーかもしれないしネットワークかもしれない）は、VASTのラッパー・レスポンスを送る。ラッパー・レスポンスは、セカンダリ・アドサーバに（リダイレクトすること）よってリソースを特定する。
<VAST> <Ad> <Wrapper> ...
<VASTAdTagURI>
http://SecondaryAdServer.vast.tag
</VASTAdTagURI>
... </Wrapper> </Ad> </VAST>
- VAST Request: 送られたVASTレスポンスを解析した後、ビデオプレイヤーは、ステップ2. のプライマリ・アドサーバのVASTレスポンスに書かれたURIを使って、セカンダリ・アドサーバにリクエストを送信する。
- VAST Inline Response: セカンダリ・アドサーバは、表示する広告に必要な詳細を全て含めたVASTレスポンスを送信する。
<VAST> <Ad> <InLine>
...
</InLine> </Ad> </VAST>
- Tracking URIs Pinged: 配信された広告の特定のイベントが発生すると、指定されたトラッキングURIを使って各アドサーバは通知を受信する。
上記のシナリオにおいて、２つのアドサーバが登場する。全てのトラッキング情報の受信を希望する複数ベンダーのアドサーバによって配信プロセスが構成される場合に、このシナリオはよくある。
この広告配信のシナリオは、２つ以上のアドサーバのシナリオへ容易に拡張できる。セカンダリ・アドサーバはさらにまた別のアドサーバを指したVASTのラッパーレスポンスを返すことができる。しかしながら最終的には、このリダイレクトチェーンの最後のアドサーバがVASTのインライン・レスポンスを返さなければならない。
VASTによってサポートされる広告の種類
インストリームビデオには、パブリッシャーのコンテンツ動画の前や後や中間において再生される動画（これをリニアと言う）や、コンテンツ動画の進行中にそこに重なって表示される画像（これをノンリニアと言う）などがある。
★TODO 図
いくつかのリニアアドとノンリニアアドの種類について、より詳細に以下に記述する。
リニアアドは、普通は動画として配信されるが、静的な画像を含む場合もある。このような静的な画像はコンテンツ動画のタイムラインに沿って設定した一定の時間再生される。このリニアアアドは
- コンテンツ動画の開始前に再生されたり（プリロール）
- コンテンツ動画の中間に再生されたり（ミッドロール）
- コンテンツ動画の後に再生されたり（ポストロール）
する。
コンパニオンアドは、リニアアドやノンリニアアドと共に配信されるが、ビデオプレイヤーの領域の外に表示される。コンパニオンアドは、動画広告（訳注：←インストリームの動画広告）が終了した後もページ上に残るので、ユーザはより深い広告体験が可能となる。コンパニオンアドは通常、標準的なバナーかリッチメディア広告として表示され、配信された動画の広告体験を包括したスキン（訳注：インターフェイス）となることができる。
通常は画像広告（オーバーレイとも呼ばれる）であり、ノンリニアアドはコンテンツ動画の再生と並列して動画上に表示される。ノンリニアアドは通常、コンテンツ動画の上部か下部の1/5を覆い、典型的なテキストか静的画像であり、約10~20秒ほど表示される。
VPAIDのような別の技術を使用すると、ノンリニアアドはインタラクティブな挙動が可能となり、さらなる広告コンテンツを再生するために（親の）コンテンツ動画自体を停止（ポーズ）させたりすることができる。これらのインタラクティブな挙動は、ユーザ操作が起点となる場合に限られる。
VAST3.0で新たにサポートされたアドポッドは、複数の（順番のある）連続するリニアアドのセットを配信する。下の図は、コンテンツ動画の前に順に再生される3つの広告を持つアドポッドを表している。アドポッドは、コンテンツ動画の前でも中間でも後でも再生可能である。そのため、複数のアドポッドを用いればTVコマーシャルのように機能する。アドポッドの配置（再生のタイミング）についてはVAST3.0の範囲外であるが、ビデオプレイヤーのプログラミングか、広告再生のタイミングを明示することができるVMAPの、いずれかを使えば、再生位置を制御できる。VMAPに関する情報はセクション3.1を参照。
★TODO 図
VASTが規定しないのは何か
VASTは、
- 機能としてのVASTスキーマのフォーマットの要件
- 期待される準拠事項
を記述する。そして、以下はVASTの範囲外である。
（省略）
（省略）
（省略）
<InLine>エレメント
動画広告レスポンスのリダイレクトチェーンの最後のアドサーバは、<InlLine>要素を返す。この<InLine>要素は入れ子状になっていて、その中に動画広告を表示するために必要なファイルとURIが全て入る。
InLine要素の要件
<InLine>要素の中には、以下の必須要素が直接含まれる。
<AdSystem>: 広告を返すアドサーバの名称<AdTitle>: 広告の一般名称<Impression>: 動画広告の最初の１フレーム目が表示される時にビデオプレイヤーがリクエストすべきトラッキングリソースのURI<Creatives>: １つ以上の<Creative>要素が入る
ここまでのVASTレスポンスの構造は以下のように表される。
★TODO 図
オプションのインライン要素
以下、<InLine>要素に含まれる場合があるが、任意（オプショナル）だ。
（省略）
<Survey>: 調査機関が調査を可能にするためのトラッキングピクセルや、それ以外の調査に用いる何かだ。survey要素は複数書ける。type属性は実行のためのMIMEタイプの指定をすることができる。例えばこの属性はtype=text/javascriptとセットすることができる。survey要素は、クロスドメイン通信の問題を回避しているならば、動的にVASTレスポンスに挿入することが可能だ。
VASTトラッキング
VASTフォーマットにおいて提供される広告トラッキングは、VASTレスポンスの中の様々な階層に置かれたVASTトラッキング要素のコレクション（訳注：集まり）を用いて実行される。これらのトラッキング要素はそれぞれ、VASTレスポンスを返したアドサーバの何らかのリソースやロケーションを指すURIを含んでいる。このリソースは（必ずではないが）普通は、1×1の透過画像（例えばトラッキングピクセル）である。このトラッキングピクセルは、呼び出されると紐付いた特定のイベントを記録する。
ビデオプレイヤー実装上の注意点
ビデオプレイヤーは、VASTの広告レスポンスの実行における適切なタイミングにおいてトラッキングピクセルのリクエストを送信する義務がある。
ほとんどのトラッキング要素は、それを含めるかどうかはアドサーバの任意（オプショナル）だ。しかし、もしトラッキング要素が含まれているならば、適切なタイミングで提供されたURIのリソースにリクエストを送信することがビデオプレイヤーには求められる。広告主とパブリッシャーは、請求、キャンペーンの効果把握、市場分析、そしてその他のビジネスインテリジェンスと評価を、トラッキングの記録の正しさに頼っている。動画広告産業全体のより良いトラッキングの実践は、デジタル動画広告の成長と成功にとって重要である。
一般的な実装上の注意点 （省略）
VASTトラッキング要素のサマリ
以下のトラッキング要素のリストは、VASTの各階層で提供されているトラッキング・オプションを簡潔に説明する。
-
<VAST>トラッキング要素<Error>"no ad"レスポンスを受信した場合に、ビデオプレイヤーがリクエストすべきトラッキングリソースのURIを入れる。
-
<InLine>と<Wrapper>トラッキング要素<Error>何らかの理由でInLine動画広告を提供することができない場合に、ビデオプレイヤーがリクエストすべきトラッキングリソースのURIを入れる。<Impression>動画広告"Impression"のメトリクスがカウントされる時にビデオプレイヤーがリクエストすべきトラッキングリソースのURIを入れる。それは、典型的にはInLine動画広告の最初１フレーム目がユーザに表示された時である。
-
<Linear>トラッキング要素<TrackingEvents>以下のタイプの要素が入る：<Tracking>リニアのクリエイティブの再生中に特定の名前のイベントが起きた時にビデオプレイヤーがリクエストすべきトラッキングリソースのURIを入れる（そのイベントの名前はこの要素の属性として渡される）。アドサーバは、特定のイベントに紐付いたメトリクスのトラッキングのためにこのURLへのリクエストを利用することができる。
<VideoClicks>以下のタイプの要素を収める：<ClickThrough>リニアアドが再生されている時にユーザが動画フレームをクリックした時にビデオプレイヤーがリクエストし表示すべきページのURIを入れる（これは、"クリックスルー"や"ランディングページ"とも呼ばれている）。<ClickTracking>リニアアドが再生されている時にユーザが動画フレームをクリックした時にビデオプレイヤーがリクエストすべきトラッキングリソースのURIを入れる。アドサーバは"クリックスルー"メトリクスをトラッキングするためにURIへのリクエストを利用することができる。<CustomClick>リニアアドの再生中に、ユーザが特定のボタン、リンク、あるいはその他のアクションが関連付けられた呼び出しを行った時に、ビデオプレイヤーがリクエストすべきファイルかロケーションのURIを入れる。しかし、ブラウザのウィンドウの中で新しいページを開くべきではなく、ClickThroughとCustomClickのURLは同時に呼び出されるべきではない（例えば、１つのクリックによって両方が呼び出されるべきではない）。
<IconClicks>Icon/Icons 要素内で以下の要素を収めるためのコンテナ。<IconClickThrough>動画広告に紐付いて表示されているアイコンのがユーザにクリックされた時に、ビデオプレイヤーがブラウザウィンドウ内に開くべきWebページのURLを入れる。<IconClickTracking>ユーザがアイコンをクリックした時にビデオプレイヤーがリクエストすべきファイルやロケーションのURIを入れる。
<IconViewTracking>Icon/Icons のクリエイティブがユーザに表示された時にビデオプレイヤーがリクエストすべきファイルやロケーションのURIを入れる。
-
<Companion>トラッキング要素（詳細はセクション2.2.5.2を参照）<CompanionClickThrough>コンパニオンアドのクリエイティブがユーザにクリックされた時にビデオプレイヤーがブラウザウィンドウ内に開くべきWebページのURIを入れる。このURIは、クリックスルーのトラッキングとしても使用できる。<CompanionClickTracking>コンパニオンアドのクリエイティブがユーザにクリックされた時にビデオプレイヤーがリクエストすべきファイルやロケーションのURIを入れる。コンパニオンアドのクリエイティブがユーザのクリックを制御する時、InLineのクリエイティブに対するクリックスルーのトラッキングとして使用される。Wrapper広告においてこのURIは、Wrapper広告の後に得られるInLineレスポンスのクリックスルーをトラッキングするために使用される。
-
< NonLinearAds>トラッキング要素<TrackingEvents>以下のタイプの要素が入る。<Tracking>ノンリニアのクリエイティブの再生中に特定の名前のイベントが起きた時にビデオプレイヤーがリクエストすべきトラッキングリソースのURIを入れる（そのイベントの名前はこの要素の属性として渡される）。アドサーバは、これら（訳注：リニアアドの所の文章はここが、theseではなくspecified）のイベントに紐付いたメトリクスのトラッキングのためにこのURLへのリクエストを利用することができる。
-
< NonLinear>トラッキング要素（詳細はセクション2.2.5.2を参照）<NonLinearClickThrough>ノンリニアアドのクリエイティブ上をユーザクリックした時にビデオプレイヤーが開くべきWebページのURIを入れる。<NonLinearClickTracking>ノンリニアアドのクリエイティブがユーザにクリックされた時にビデオプレイヤーがリクエストすべきファイルやロケーションのURIを入れる。ノンリニアアドのクリエイティブがユーザのクリックを制御する時、InLineのクリエイティブに対するクリックスルーのトラッキングとして使用される。Wrapper広告においてこのURIは、Wrapper広告の後に得られるInLineレスポンスのクリックスルーをトラッキングするために使用される。
全てのトラッキング要素は、InLineでもWrapperでもどちらのフォーマットにおいても利用可能である。ただし<VAST>階層の<Error>要素だけは例外となる。それは、この要素がInLineのレスポンスが返されなかった場合にのみ使用されるからである。
クリックスルーとクリックトラッキング要素
<StaticResource>（例えば画像）タイプからなるノンリニアアドやコンパニオンアドのクリエイティブは、ユーザがその広告をクリックした時にユーザを広告主のWebページヘ誘導するクリックスルーURIを提供する手段を必要とする。広告主は、<NonLinearClickThrough>と<CompanionClickThrough>のVAST要素を使用することで、静的な画像クリエイティブにクリックスルーURIを入れることができる。ほとんどの場合、このクリックスルーは、広告がクリックされたことを適切なパーティ（プレイヤー）に通知するトラッキング情報も提供することになる。
しかしながら、広告ユニットとビデオプレイヤー間のコミニュケーションのための仕様であるVPAIDのようなAPIを利用すると、広告ユニットがクリックスルーを制御することができるようになる。ノンリニアアドの<NonLinearClickTracking>要素やコンパニオンアドの<CompanionClickTracking>要素は、このケースにおけるトラッキングを可能にする。
訳注：ここらへんに↑↓、単純な動画広告フォーマットでは分からない、<〜ClickThrough>要素と<〜ClickTracking>要素のできることの違いが強調されている。
さらに、InLineのクリエイティブのみがクリックスルーの情報を提供するので、このクリック-トラッキング（訳注：<〜ClickTracking>）の要素は、Wrapperレスポンスを経由するInLineのクリエイティブにおけるクリックスルーをトラッキングするために利用することができる。
VASTのInLineとWrapperのそれぞれのレスポンスにおいて、どの要素が静的なクリエイティブの選択において使用されるかを、下の表に記述した。
| StaticResource クリエイティブ・タイプ | InLine クリエイティブ | Wrapper クリエイティブ |
|---|---|---|
| ** NonLinear ** | ||
| 画像 | <NonLinearClickThrough> |
<NonLinearClickTracking> |
| APIフレームワークを使わないFlash | <NonLinearClickThrough> |
<NonLinearClickTracking> |
| APIフレームワークを使ったFlash ＝ clickTAG | <NonLinearClickThrough> |
<NonLinearClickTracking> |
| ビデオプレイヤーがクリックを制御する静的リソース（例えば、VPAIDのplayerHandlesClick=true） | <NonLinearClickThrough> |
N/A |
| 広告ユニットがクリックスルーを制御する静的リソース（例えば、VPAIDのplayerHandlesClick=false） | <NonLinearClickTracking> | <NonLinearClickTracking> |
| ** Companion＊ ** | ||
| 画像 | <CompanionClickThrough> |
<CompanionClickTracking>＊ |
| APIフレームワークを使わないFlash | <CompanionClickThrough> |
<CompanionClickTracking>＊ |
| APIフレームワークを使ったFlash ＝ clickTAG | <CompanionClickThrough> |
<CompanionClickTracking>＊ |
| ビデオプレイヤーがクリックを制御する静的リソース（例えば、VPAIDのplayerHandlesClick=true） | <CompanionClickThrough> |
N/A |
| 広告ユニットがクリックスルーを制御する静的リソース（例えば、VPAIDのplayerHandlesClick=false） | <CompanionClickTracking> | <CompanionClickTracking> |
＊ クリエイティブリソースが入れられたWrapperフォーマットのコンパニオンアドのクリックをトラッキングする場合は、コンパニオンアドのクリエイティブはInLineと見なされ<ConpanionClickThrough>要素が使われるべきである。 |
<Impression>要素
VASTの<InLine>要素は、１つ以上の<Impression>要素を持つ。各<Impression>要素は、CDATAでラップされたURIをただ１つの子要素として持つ。もし１つのクリエイティブに対して複数のインプレッション・リソースが必要な場合（複数のシステムがインプレッションの通知を受け取りたいような時）、それぞれのインプレッションリソースの（ユニークな）URIを持つ<Impression>要素が含まれるべきである。
★TODO 図
VAST中のURIやその他の自由記述のテキストのフィールドは、（XMLやVASTにとって）危険性のある文字を含むかもしれない。なのでCDATAブロックで囲むべきである。以下の例に示されるように：
<Impression id=”myserver”>
<![CDATA[
http://ad.server.com/impression/dot.gif
]]>
</Impression>
インプレッションと「スタート」イベント
インプレッションのトラッキングURIは、動画広告の最初の1フレーム目が表示された時に使用されなければならない。しかしながら、広告が複数のクリエイティブから構成されていることもあるので、もし広告主がこの「インプレッション」に加えて、個別のそれぞれのクリエイティブの開始をトラッキングしたい場合はトラッキングするクリエイティブの<TrackingEvents>要素配下のstartイベントをVASTレスポンスに入れてください。それぞれのアドフォーマットに関連した注意事項は、セクション 2.3.1 - 2.3.5 を参照してください。
複数のインプレッション
複数のインプレッションURIを使用することで、アドサーバは、インプレッションのトラッキング情報を他のシステムを共有することができる。それは、例えば広告主が契約している第三者のアドサーバなどである。複数のインプレッション要素がVASTレスポンスに入れられている時、ビデオプレイヤーはその全てインプレッションに対して同時にリクエストを送信する必要がある。インプレッションリクエスト間の大きな遅延は、配信システム間の数値の乖離を引き起こす可能性がある。
ビデオプレイヤー実装上の注意事項 （省略） TODO
複数パーティにおけるトラッキングレコード
あるデジタル広告キャンペーンに関わるそれぞれのパーティは皆VASTフォーマットにおける動画広告配信のトラッキングデータが自分専用に欲しい。（訳注：計測を誰かにやってもらってその結果をもらうのではなく、という意味だと思う。）これを実現する方法は色々考えられる。しかし、VASTは複数のトラッキング要素を使える。そのため、どのパーティが動画広告のトラッキング情報の通知を要求しても、そのURIを提供可能である。
３つのcreative要素のそれぞれのtracking要素は、ID属性を持つ。複数のインプレッションについて前のセクションで説明したように、同じID属性を持つ複数のtracking要素はについてはいかなる場合でもそのトラッキングリソースは同時にリクエストされなければならない。トラッキングリソースへのリクエスト間の大きな遅延は、関わってくる配信システム間の（レポーティングの）数値の乖離を引き起こす可能性がある。
フォーマット全体におけるVASTの要件
VAST3.0において、ビデオプレイヤーは、VASTで ビデオプレイヤーは、５つのVASTのアドフォーマットの１つ以上のサポートを選択する。
- リニアアド
- スキップできるリニアアド＊
- コンパニオンアド＊
- ノンリニアアド
- アドポッド＊
＊スキップできるリニアアドとアドポッドは、リニアアドがサポートされている必要がある。コンパニオンアドはリニアアドとノンリニアアドのどちらかがサポートされている必要がある。
各アドフォーマットのサポートは任意となっているため、 ビデオプレイヤーは、自分の動画提供モデルに最もマッチしたアドフォーマットだけをサポートするだけでも、VASTのガイドラインに準拠することができる。準拠するアドフォーマットが任意（オプショナル）で良いことによって、業界での幅広い採用が促進され、動画アドサーバがより多くのパブリッシャーのプラットフォームにリーチすることが容易になる。
VASTレスポンスにおけるアドフォーマットの判定
下の表は、。５つのVASTアドフォーマットのレスポンスにおける設定項目（要素や属性）をまとめている。各アドフォーマットの列でチェック 〆 が付いている所は、その行のVAST要素を必ずレスポンスに含めなければならないことを表している。
エンジニアは、VASTレスポンスに入っているアドフォーマットの迅速な判定をビデオプレイヤーにプログラムするのに、下の表を使うことができる。
| 設定項目 | リニアアド | コンパニオンアド | スキップできるアド | ノンリニアアド | アドポッド |
|---|---|---|---|---|---|
<Ad>（sequence属性無し） |
〆 | 〆 | 〆 | 〆 | |
<Ad sequence="n"> |
〆 | ||||
<Linear>（skipoffset属性無し） |
〆 | 〆＊ | 〆 | ||
<Linear skipoffset="HH:MM:SS"> |
〆 | ||||
<NonLinearAds> |
〆＊ | 〆 | |||
<CompanionAds> |
〆 |
＊コンパニオンアドのクリエイティブは、リニアアドかノンリニアアドのクリエイティブと一緒に提供されなければならず、単独で提供することはできない。<CompanionAds>要素は、その他のどのアドフォーマットと一緒でも提供可能である。required="none"の属性が付いている場合、
ビデオプレイヤーは入っているコンパニオンアドを好きに無視して良い。
その他のアドフォーマットを表す要素がある場合、そのアドフォーマットをサポートしていないことを表明しているならば、その要素を無視して良い。
例えば、ビデオプレイヤーがリニアアドしかサポートしていないのに、アドポッドとして再生されることを意図するようなsequence属性を持つ<Ad>要素がレスポンスに入っている場合、sequence属性のない<Ad>要素が少なくとも１つでも入っている限り、その他のsequence属性の付いた<Ad>要素についてをビデオプレイヤーが無視しても良い。しかし、もしレスポンスに入っているアドフォーマットが、ビデオプレイヤーがサポートしていないものしか選択できないような場合、ビデオプレイヤーはその広告を拒否して、<Ad>の<Error>要素を使用してアドサーバにそれを通知することができる。
これと同様に、リニアアドとコンパニオンアドの両方のフォーマットをどちらもサポートしている（メジャーなコンパニオンアド付きのリニアアドをサポートしている）ビデオプレイヤーは、どちらのアドフォーマットの指定も尊重されるべきである。
それぞれのカテゴリの準拠内容の詳細は以下のセクション2.3.1〜2.3.5に続く。
リニアアドのフォーマット
この業界で流通する動画広告のなかで最もよくあるのは、「リニアアド」だ。リニアアドは、コンテンツ動画と同じ領域を使うが、コンテンツ動画の再生とはかぶらないように表示される。要するに、ビデオプレイヤーは、リニアアドを再生する前にコンテンツ動画を中断しなければならない。リニアアドはしばしばコンテンツ動画の直前に再生される。この広告再生位置は「プリロール」ポジションと呼ばれており、そのためリニアアドは、しばしば「プリロール」と呼ばれたりもする。
リニアアドを表すVASTレスポンスの構造を以下の図に表現する。
★TODO 図
任意の（オプショナルな）<VideoClicks>要素
<Linear>要素は、<VedeoClicks>要素に任意で入る。この要素は、リニアアドがビデオプレイヤーの表示されている時にユーザがフレーム（表示領域）を直接クリックした時にビデオプレイヤーがどう振る舞うかを規定する。もし<VideoClicks>要素が提供されるならば、１つの<ClickThrough>が子要素として必須で、１つ以上の<ClickTracking>と<CustomClick>が子要素として任意である。この<VideoClicks>要素とその子要素の構造を下の図に書き表す。
★TODO 図
メディアファイルがそれ自身を提供しない場合（訳注：クリック時にどっか外部にリソースを提供する場合、という意味？普通はそう。）、メディアのクリックスルーを与えるために<ClickThrough>要素が使われる。クリックスルーURIは、ユーザが広告をクリックした時にビデオプレイヤーがブラウザの新しいウィンドウで開く。このクリックスルーURIは、通常はユーザーを広告主のサイトのページへリダイレクトする。
任意で使用可能な<ClickThrough>要素は、クリエイティブがクリックスルーを制御する時にそのクリックスルーをトラッキングするために使用される。そして、<CustomClick>要素はリニアアドに対するクリックスルー以外のクリックをトラッキングするために使用される。
ビデオプレイヤーの実装上の注意点
<ClickThrough>要素があったら、ユーザが広告動画のクリエイティブをクリックした時にブラウザのウィンドウにそのURIをロードしなければならない。
<Linear>要素のその他の任意の（オプショナルな）子要素は、実行可能なクリエイティブに使われる<AdParameters>要素と、<TrackingEvents>要素である。<AdParameters>要素はセクション2.3.1.9で、<TrackingEvents>要素ではセクション2.3.1.7で説明します。
リニアアドのトラッキング
VASTの動画広告をアドサーバにリクエストし表示する際の、ビデオプレイヤーの極めて重要な機能が、VASTの仕様書で規定されている通りにきちんとアドサーバへトラッキング情報を送り返すことである。正確なトラッキングデータの送信に失敗すると、ビデオプレイヤーとアドサーバ間で一貫性の無い結果を生み出される。
リニアアドのトラッキング情報は２箇所で規定されている。それは、<VideoClicks>と<TrackingEvents>だ（どちらも<Linear>要素直下の任意（オプショナルな）要素である）。
<TrackingEvents>要素には、１つ以上の<Tracking>要素が入る。<Tracking>要素のevent属性によって、トラッキングしたいイベントを区別してそれぞれ個別のトラッキングURIを入れることができる。event属性は、以下のVASTレスポンス（の一部分）の例のように表される。
<TrackingEvents>
<Tracking event=”firstQuartile”>
<![CDATA[http://adserver.com/firstQuartilePixel.gif]>
</Tracking>
</TrackingEvents>
こんなのがあったら、ビデオプレイヤーは、リニアアドの再生中にイベントが発生した時に、対応する<Tracking>要素のURIに対してリクエストを送信しなければならない。あるイベントの<Tracking>要素が提供されていない場合には、ビデオプレイヤーは（そのイベントが起きても）特に何もしなくていい。
全般的な実装上の注意点
VAST3.0で扱われるトラッキングイベントにはこのバージョンで新たに追加されており、IABが2008年に出した「Digital Video In-Stream Ad Metrics Definitions document」で定義されているメトリクスでカバーされていないものがいくつかある。この２つのドキュメントのメトリクスは衝突するべきではないのだが、VAST3.0はより多くのトラッキングオプションを要求し、そしてそれは（このドキュメントのリリース以後は）VAST3.0の中でのみ取り扱う。
<Tracking>イベントの種類は以下の通り。
- creativeView:
impressionと混同しないように。このイベントはリニアアドの個々のクリエイティブが見られたことを示す。impressionはリニアアドの最初の１フレーム目が表示されたことを示す。しかしながら、リニアアドは複数のクリエイティブから構成されることもあれば、いくつかのプラットフォームでのみ再生されるがそれ以外で再生されない１つのクリエイティブで構成されることもある。 このイベントによって、アドサーバはどのクリエイティブが見られたかをトラッキングすることができ、そしてそれによりどのプラットフォームがより一般的かを知ることができる。（訳注：例えば１つのリニアアドを２つの動画ファイルの連続再生として構成することができるし、その場合に、その２つの動画の再生をそれぞれにトラッキングしたい場合、このcreativeViewメトリクスを使用する。<Impression>が<InLine>の直下の要素なのに対して、この要素は<InLine>の子供の<Creatives>の子供の<Creative>の子供の<Linear>の子供の<TrackingEvents>の子供の<Tracking>要素だという点に注意。そもそも階層が全然違う） - start: このイベントはリニアアドの個々のクリエイティブがロードされ再生が始まったことを示す。
creativeView同様このイベントはクリエイティブの再生をトラッキングするまた別の方法である。 - firstQuartile: このリニアアドのクリエイティブの全体の尺の少なくとも25%が再生された。
- midpoint: このリニアアドのクリエイティブの全体の尺の少なくとも50%が再生された。
- thirdQuartile: このリニアアドのクリエイティブの全体の尺の少なくとも75%が再生された。
- complete: このリニアアドのクリエイティブが標準の速度で最後まで再生された。
- mute: ユーザがミュート（無音）を有効にし、クリエイティをミュートにした。
- unmute: ユーザがミュート（無音）を無効にし、クリエイティブのミュートを解除した。
- pause: ユーザがポーズ（一時停止）をクリックし、クリエイティブを止めた。
- rewind: ユーザが巻き戻しを使用し、クリエィティブの再生位置を戻した。
- resume: クリエイティブが停止や一時停止された後に、ユーザが再開した。
- ＊＊fullscreen: ユーザがスクリーンの角までビデオプレイヤーを拡大した。
- ＊＊exitFullscreen: ユーザがビデオプレイヤーのサイズをオリジナルまで縮小した。
- ＊＊expand: ユーザがクリエイティブの拡大をした。
- ＊＊collapse: ユーザがクリエイティブをオリジナルのサイズまで縮小した。
- ＊acceptInvitationLinear: そのクリエイティブの更なる部分（押すと何かがポップするとか）を起動するような操作をユーザが行った。このイベントの名前は、2008年にIABから出された「Digital Video In-Stream Ad Metrics Definitions」で既に存在する
acceptInvitationメトリクス（ノンリニアアドにしか使用しない）と区別されることを強調している。この＊acceptInvitationLinearイベントは、acceptInvitationをリニアアドに拡張している。 - ＊closeLinear: ユーザがクリエイティブの閉じるボタンををクリックした。このイベントの名前は、2008年にIABから出された「Digital Video In-Stream Ad Metrics Definitions」で既に存在する
closeイベントと区別されることを強調している。 - ＊skip: ユーザがクリエイティブをスキップするためにスキップを行った。このスキップの制御は、クリエイティブを閉じる制御とは区別される。
- ＊progress: クリエイティブが標準の再生速度で任意の時間再生された。この再生時間が、
offset属性の値と同じかそれより大きい。offsetの値は、"HH:MM:SS"か"HH:MM:SS.mmm"の形式による経過時間か、あるいは"n%"フォーマットのパーセンテージとなる。リニアアドのタイムラインの複数のプログレスポイントをトラッキングするには、異なるoffset値を持つ複数のprogressイベントを使用すれば良い。
＊ VAST3.0で追加されたメトリクス
＊＊ 2008年にIABから出された「Digital Video In-Stream Ad Metrics Definitions」で出てくるexpandとcollapseのメトリクスは、ビデオプレイヤー自身がフルスクリーンに拡大されたり、フルスクリーンから元のサイズに戻されたりした時にトラッキングするのに使用されている。この2008年のガイドラインとの互換性を維持するため、これらのメトリクスはそのようにすべきである。VAST3.0では、fullscreenとexitFullscreenというメトリクスを使用することができ、ビデオプレイヤーの挙動ではなくクリエイティブの挙動をトラッキングするためにexpandとcollapseを残している。この2008年のガイドラインと互換性を保ちながらfullscreenとexitFullscreenを使用するには、fullscreenとexpandに共通のトラッキングURIを、exitFullscreenとcollapseにそれとは別の共通のURIを使用するようにしてください。
ビデオプレイヤー実装上の注意点
（訳注：省略）
複数の同種のトラッキングイベント
複数の同種のトラッキングイベントの用いると、例えば広告主が契約しているベンダーのアドサーバのような別の配信システムと、インプレッションのトラッキング情報をシェアすることができるようになる。
複数の同種のトラッキングイベント（例えば複数の"start"イベント）が与えられた場合、同種の全てのイベントを同時かあるいはできる限り少ない時間差でリクエストする必要がある。このトラッキングリクエスト間の大きな遅延は配信システム間の数値の乖離を引き起こす可能性がある。
ビデオプレイヤー実装上の注意点
（訳注：省略）
実行可能メディアファイル
VASTは、メディアファイルが「実行可能ファイル」であるケースをサポートしている。「実行可能メディアファイル」とは、例えば Adobe Flash の実行環境において実行されるべきコードでできている広告である。アドサーバは、独自のインタラクティビティや独自のトラッキングを行うクリエイティブを特定するためにこの実行可能ファイルを使用することができる。通常（この文章のリリース時点では）、「実行可能メディアファイル」とは、Webブラウザで実行されるように設計されたJavaScriptファイルや、フラッシュプレイヤーで起動するようにデザインされたバイナリファイルである。フォーマットをビデオプレイヤーに通知することによって、これら２つのフォーマットやあるいはその他のフォーマットについても、VASTはサポートしている。
もしVASTレスポンス中のクリエイティブが「実行可能メディアファイル」だと分かったら、ビデオプレイヤーは、プログラム的にどのようにそれを扱うかだけでなく、そのファイルのフォーマットも知る必要がある。通常、「実行可能メディアファイル」は IAB Video Player AdInterface Definition (VPAID) のAPIをビデオプレイヤーとの通信に使用します。VASTはそのようなAPIを何もサポートしていない。VPAIDのより詳細な情報は http://www.iab.net/vsuite/vpaid を訪れてください。
「実行可能メディアファイル」を入れたVASTレスポンスは、<MediaFile>のtype属性にそのMIMEタイプを含めなければならない。例えば。Flashの「SWF」ファイルなら”application/x-shockwave-flash”、JavaScriptなら"application/x-javascript"という具合だ。実行可能な場合の<MediaFile>要素は、別のおオプショナルな属性である"apiFramework"を明示しなければならない。もし適切な"apiFramework"属性が得られないがそれでもそのメディアファイルを実行する必要がある場合、ビデオプレイヤーはそのメデイアファイルを無視しても良い。もし、そのリニアアドを表示するためのオプションが他に何も得られない場合、ビデオプレイヤーはその広告を無視し、その広告が表示されなかったことを通知するために<Error>要素を使用すること。
次のXMLの例は、インタラクティブAPIとしてVPAIDを使用したFlash環境で実行されるメディアファイルの属性値である。
<MediaFiles>
<MediaFile id=1 delivery=”progressive” type=”application/x-shockwave- flash” width=640 height=480 apiFramework=”VPAID”>
...
</MediaFile>
</MediaFiles>
任意の（オプショナルな）<AdParameters>要素
いくつかの広告配信システムでは、メディアファイルの初期化の際にメディアファイルに何らかのデータを受け渡したいことがある。例えば、メディアファイルが、クリエイティブを表示する際のコンテキストをアドサーバのデータから判定することがある。アドサーバの通信相手は誰なのか、表示するクリエイティブは何なのか。リニアアドの<AdParameters>オプション要素はデータのやり取りを実現する。
<AdParameters>要素のxmlEncodedオプション属性は、アドパラメータ（ad parameters）がxml-encoded
★TODO
★TODO
スキップイベント ★TODO
進捗イベント ★TODO
ノンリニアアドのフォーマット ★TODO
ノンリニア・クリエイティブのトラッキング ★TODO
コンパニオンアドのフォーマット ★TODO
トラッキングの詳細 ★TODO
共通のVAST要件 ★TODO
アイコンのサポート ★TODO
アイコンのクリックとトラッキング ★TODO
マクロ ★TODO
- [ERRORCODE]:
- [CONTENTPLAYHEAD]:
- [CACHEBUSTING]:
- [ASSETURI]:
VASTの用語
アドポッドとは、TVの連続した複数のコマーシャルのように、次々と再生される一連のリニアアドです。
一般的に、ビデオプレイヤーのディスプレイ広告やリッチメディア広告で、ページ内でビデオプレイヤーの外に表示されるもののこと。コンパニオンアドは、関連するインストリームの広告が終了した後もページに残り続けることがある。コンパニオンアドもまた、動画体験を包括するスキン（インターフェイス）といえる。
ユーザが広告クリエイティブをクリックした時に開くページのURL
動画広告を表示するの必要な情報を全て含んだ VAST ad レスポンス。インラインVASTレスポンスを受信した後は、他のアドサーバへの追加の呼び出しの必要はない。
ビデオプレイヤーのストリーミング中に表示される何らかの広告。画像のオーバーレイの場合もあるし、30秒アドスポットで再生されるようなリニアアドの場合もある。
リニアアドはTVコマーシャルに似ている。
- コンテツ動画の再生の前に表れるもの（プリロール）
- コンテツ動画の途中に表れるもの（ミッドロール）
- コンテツ動画の再生の後に表れるもの（ポストロール）
がある。 リニアアドは、動画や、リッチメディア、あるいは単なる画像広告である。リニアアドはインタラクティブに動作可能であり、ユーザアクションがある際にはリニアアドの持続時間は拡大することがある。
インストリームアドと１つ以上のコンパニオンアドを含む動画広告キャンペーンにおいて、広告ユニットのインストリームアドの部分は、マスターアド（主広告）と呼ばれる。この マスターアド-コンパニオンアド の関係性がある場合には、マスターアドは常に表示されなければいけない。 （訳注：コンパニオンアドが、それに関連するマスターアドの表示なしに表示されちゃいけないってことだと思われる。）
動画広告の再生にともなって表示されるインストリームアド。ノンリニアアドは通常、ビデオプレイヤーの下部または上部の1/5をカバーし（★）、テキストや画像やインタラクティブアドである。APIやその他の技術を使って、ノンリニアアドに対するユーザインタラクション（ユーザ操作）を起点に、ビデオプレイヤーはコンテンツ動画の再生を中断させても良い。ノンリニアアドはコンテンツ動画の始まりと終わりの間（つまりミッドロールの位置）のあるポイントにおいてのみ表示させても良い。そして、ユーザインタラクション（ユーザ操作）がなければ通常は10~20秒ほどで消える。
コンテンツビデオの上部に表示される画像やテキストを使ったノンリニアアドのアドフォーマット。オーバーレイアドは、しばしば単に「ノンリニアアド」と呼ばれたりもする。しかしながら、「ノンリニアアド」には、ビデオプレイヤーにサーブされるがコンテンツ動画と重なることのないようなオーバーレイ以外のフォーマットも含まれる。 （訳注：ノンリニアアド ∋ オーバーレイアド）
広告内容取得のためにビデオプレイヤーが最初に呼び出すアドサーバ。普通はパブリッシャーが使っているアドサーバになる。
プライマリ・アドサーバからVASTリダイレクト（ラッパーアド）を受信した後にビデオプレイヤーが呼び出すアドサーバ。セカンダリ・アドサーバが更に３番目のアドサーバにリダイレクトしたり、更に４番目のアドサーバにリダイレクトしたり、あるいは更にもっと、ということもある。最終的にどこかのアドサーバが、広告を表示するために必要なクリエイティブの要素を全て含んだVASTレスポンスを返さなければならない。
動画広告計測ガイドライン（Video Ad Measurment Guidelines）とは、動画広告が再生された時に追跡すべきイベントのセットを定義したIABのガイドラインである。
動画広告送信テンプレート（The Video Ad Serving Template）とは、動画広告レスポンスのXML構造を記述したXMLスキーマであり、IABのガイドライン。
自分以外の他のVASTレスポンス（これは、しばしば下流のVASTレスポンスと呼ばれる）を、指したVASTレスポンス。
呼び出された時にVASTレスポンスを返すURI。
ビデオエクスペリエンスを背景にして表示されるあらゆる広告のことをいう。「ビデオエクスペリエンス」とは
- banner video（バナー動画）
- in-text video（インテキスト動画）
- in-stream video（インストリーム動画）
- その他のフォーマット
が含まれる。 VASTは、その他のあらゆるコンテンツから独立したビデオエクスペリエンスを管理するために使用されているビデオプレイヤー上のインストリームビデオにのみ適用される。例えば。広告バナー枠において提供される動画はリッチメディアとみなされるため、VASTのガイドラインでは扱っていない。
ビデオエクスペリエンスを管理するために使用される動画再生環境。ビデオプレイヤーは、オンラインビデオプラットフォーム（OVP）ベンダによって提供されるか、あるいはパブリッシャーによって自前で構築することもできる。
動画の複数広告プレイリスト（Video Multi Ads playlist）とは、アドサーバから送られる動画広告のプレイリストにについてのXML構造を記述したIABのガイドラインである。
ビデオプレイヤーの広告インターフェイス定義（Video Player Ad interface Definition）とは、インタラクティブ広告とそれを再生しているビデオプレイヤー間の通信プロトコルを定義したIABのガイドラインである。
VASTにおいて、ラッパーとは、セカンダリVASTレスポンスを呼び出すためにビデオプレイヤーが使用するためのURIを返すレスポンスのことをさす。セカンダリレスポンスはまた別のラッパーかVASTをインラインに含んだレスポンスのどちらかを返すだろう。
広告枠を提供している媒体
広告ではない、コンテンツの動画。このコンテンツ動画に対して諸々の動画広告を配信する。
サードパーティとかの「パーティ」。この文脈で日本語にすると「者」？
iOSのsafari上で動画の自動再生はできない、らしい。by立ち話。 FaceBookとかでよくあるあれ。 アプリではできる。