diff --git a/community_extensions/README.md b/community_extensions/README.md new file mode 100644 index 0000000..02daaad --- /dev/null +++ b/community_extensions/README.md @@ -0,0 +1,11 @@ +![IAB Tech Lab](https://drive.google.com/uc?id=10yoBoG5uRETSXRrnJPUDuONujvADrSG1) + +# **Community Extensions** + + +### Server Side Unwrapped VAST + +#### Notes + +See [server_side_unwrapped_VAST.md](server_side_unwrapped_VAST.md) for details. + diff --git a/community_extensions/server_side_unwrapped_VAST.md b/community_extensions/server_side_unwrapped_VAST.md new file mode 100644 index 0000000..96641be --- /dev/null +++ b/community_extensions/server_side_unwrapped_VAST.md @@ -0,0 +1,232 @@ +**Sponsor: Google** + +**Last updated: 2020-06-25** + +Objective +========= + +Propose a change to the VAST (4.3+) standard to support server side +unwrapping use cases in a native way by introducing a **\** +element in the \ element. The new element would be present +alongside \ which would represent the URL that was +called. + +Background +========== + +The Video Ad Serving Template +([[VAST]](https://iabtechlab.com/standards/vast/)) standard offers +an XML dialect which can describe the video ads a player should render +for the user. The VAST document contains instructions about the video ad +creative that should be rendered, the URLs which should be pinged when +various events happen with the ad creative (an error occurs, a view +occurs, the user pauses the video, etc.) as well as other bits of +information facilitating the communication between the ad server and the +player. + +The basic building block of a VAST document is the \ element. An +\ element represents in the system that generated the response a +single advertisement. Inside the \ element, the advertisement can +be described in one of two ways: + +- **\**. In this case the actual assets that need to be + > played are known to the ad server generating the response and + > their location is copied in this element in the VAST document. + +- **\**. In this case the assets that need to be played are + > not known to the ad server. Instead, the ad server returns a + > redirect to another ad server (inside the element + > \) alongside with URLs which would need to be + > pinged for various accounting purposes (views, errors, etc.). The + > video player would follow the redirect to get to the video ad + > assets and play them. The video player could go through several + > redirects (hops) before getting to the video assets. When the + > video assets are played the view URLs are pinged for all the ad + > servers through which the ad request has been processed. + +The \ element is very popular currently, a large portion of +video ad requests going through at least one hop like this. +Unfortunately, by going through these extra hops we run a higher +likelihood of error (the error rates of all the ad servers involved in +ad serving are compounded) and we increase the end user latency (the +bandwidth for each user varies wildly). + +In order to reduce the number of requests ending up in error and to +maximize the opportunity, some ad servers have started calling the +\ stored redirect tags server-side and returning the final +response as an \ ad. The ad server will combine its own view +events, quartile events, etc. with those belonging to the called ad +servers into one unified response. + +Though this model works reasonably well, if the player and one of the ad +servers in the chain of ad calls have a special integration the data +they use to communicate between them (most likely an extension) can't be +properly handled and runs the risk of being dropped. This lossy +mechanism hinders innovation by eliminating the communication channel +between ad servers in the chain and players. + +Overview +======== + +We will introduce a new element inside the \ element \-- +**\**. The \ element would contain the full +VAST document that has been retrieved from another ad server. The +\ element would live alongside the \ element +and serve as a cached response for the player. + +Detailed design +=============== + +For the cases when the ad server has a redirect and it does server side +unwinding of the ad tag, the \ element could be used to +represent the VAST fetched from the other ad server. The \ +element would contain a fully formed VAST document. + +When the \ element is present in the \ element, +the \ will contain the exact URL that was used to call +the partner ad server. + +The VAST document inside the \ element must be a valid VAST +document. To ensure this happens, the ad servers might have to rewrite +the VAST document. Here are some cases in which the ad server would have +to rewrite the received VAST document: + +- The retrieved VAST document still contains redirects and the ad + > server wants to follow those to get to the final assets. This + > would lead to having an \ inside an \. + > There is no requirement for an \ to fully resolve all + > \ elements, those could still be present if the ad + > server decides to let the player follow some of the redirects. + +- One of the redirects in the received VAST document fails retrieval + > and the ad server replaces it with an ad from the ad buffet. + +- We have a VAST redirect which ends up in error inside the pod. The + > ad server would need to rewrite the sequence indices. + +Example +======= + +Let's assume we have the following ad calls and responses that a video +player would do. + +ad-server1.com → returns 2 redirects (to ad-server2.com and +ad-server3.com) + +``` + + + + Ad Server 1 + + + + + + + Ad Server 1 + + + + + +``` + +ad-server2.com → returns an inline ad + +``` + + + + Ad Server 2 + + ... + + + +``` + +ad-server3.com → returns one inline ad, a redirect (which will error +out) and another inline ad. + +``` + + + + Ad Server 3 + + ... + + + + + Ad Server 3 + + + + + + + Ad Server 3 + + ... + + + +``` + +Here is the expected outcome if Ad Server 1 does full server side +unwinding. + +``` + + + + Ad Server 1 + + + + + + Ad Server 2 + + ... + + + + + + + + + + Ad Server 1 + + + + + + Ad Server 3 + + ... + + + + + Ad Server 3 + + ... + + + + + + + + +``` + +You can see in the response above that the VAST document from +ad-server2.com has been copied verbatim while from the response from +ad-server3.com the second ad has been removed and the sequence indices +have been updated. diff --git a/server_side_unwrapped_VAST.md b/server_side_unwrapped_VAST.md new file mode 100644 index 0000000..198329b --- /dev/null +++ b/server_side_unwrapped_VAST.md @@ -0,0 +1,337 @@ +**Authors**: [[mpungaru\@google.com]{.ul}](http://who/mpungaru) + +**Last updated: 2020-06-25** + +Objective +========= + +Propose a change to the VAST (4.3+) standard to support server side +unwrapping use cases in a native way by introducing a **\** +element in the \ element. The new element would be present +alongside \ which would represent the URL that was +called. + +Background +========== + +The Video Ad Serving Template +([[VAST]{.ul}](https://iabtechlab.com/standards/vast/)) standard offers +an XML dialect which can describe the video ads a player should render +for the user. The VAST document contains instructions about the video ad +creative that should be rendered, the URLs which should be pinged when +various events happen with the ad creative (an error occurs, a view +occurs, the user pauses the video, etc.) as well as other bits of +information facilitating the communication between the ad server and the +player. + +The basic building block of a VAST document is the \ element. An +\ element represents in the system that generated the response a +single advertisement. Inside the \ element, the advertisement can +be described in one of two ways: + +- **\**. In this case the actual assets that need to be + > played are known to the ad server generating the response and + > their location is copied in this element in the VAST document. + +- **\**. In this case the assets that need to be played are + > not known to the ad server. Instead, the ad server returns a + > redirect to another ad server (inside the element + > \) alongside with URLs which would need to be + > pinged for various accounting purposes (views, errors, etc.). The + > video player would follow the redirect to get to the video ad + > assets and play them. The video player could go through several + > redirects (hops) before getting to the video assets. When the + > video assets are played the view URLs are pinged for all the ad + > servers through which the ad request has been processed. + +The \ element is very popular currently, a large portion of +video ad requests going through at least one hop like this. +Unfortunately, by going through these extra hops we run a higher +likelihood of error (the error rates of all the ad servers involved in +ad serving are compounded) and we increase the end user latency (the +bandwidth for each user varies wildly). + +In order to reduce the number of requests ending up in error and to +maximize the opportunity, some ad servers have started calling the +\ stored redirect tags server-side and returning the final +response as an \ ad. The ad server will combine its own view +events, quartile events, etc. with those belonging to the called ad +servers into one unified response. + +Though this model works reasonably well, if the player and one of the ad +servers in the chain of ad calls have a special integration the data +they use to communicate between them (most likely an extension) can't be +properly handled and runs the risk of being dropped. This lossy +mechanism hinders innovation by eliminating the communication channel +between ad servers in the chain and players. + +Overview +======== + +We will introduce a new element inside the \ element \-- +**\**. The \ element would contain the full +VAST document that has been retrieved from another ad server. The +\ element would live alongside the \ element +and serve as a cached response for the player. + +Detailed design +=============== + +For the cases when the ad server has a redirect and it does server side +unwinding of the ad tag, the \ element could be used to +represent the VAST fetched from the other ad server. The \ +element would contain a fully formed VAST document. + +When the \ element is present in the \ element, +the \ will contain the exact URL that was used to call +the partner ad server. + +The VAST document inside the \ element must be a valid VAST +document. To ensure this happens, the ad servers might have to rewrite +the VAST document. Here are some cases in which the ad server would have +to rewrite the received VAST document: + +- The retrieved VAST document still contains redirects and the ad + > server wants to follow those to get to the final assets. This + > would lead to having an \ inside an \. + > There is no requirement for an \ to fully resolve all + > \ elements, those could still be present if the ad + > server decides to let the player follow some of the redirects. + +- One of the redirects in the received VAST document fails retrieval + > and the ad server replaces it with an ad from the ad buffet. + +- We have a VAST redirect which ends up in error inside the pod. The + > ad server would need to rewrite the sequence indices. + +Example +======= + +Let's assume we have the following ad calls and responses that a video +player would do. + +ad-server1.com → returns 2 redirects (to ad-server2.com and +ad-server3.com) + ++----------------------------------------------------------------------+ +| \ | +| | +| \ | +| | +| \ | +| | +| \Ad Server 1\ | +| | +| \\\ | +| | +| \\\ | +| | +| \ | +| | +| \ | +| | +| \ | +| | +| \ | +| | +| \Ad Server 1\ | +| | +| \\\ | +| | +| \\\ | +| | +| \ | +| | +| \ | +| | +| \ | ++----------------------------------------------------------------------+ + +ad-server2.com → returns an inline ad + ++----------------------------------------------------------------------+ +| \ | +| | +| \ | +| | +| \ | +| | +| \Ad Server 2\ | +| | +| \\\ | +| | +| \\...\ | +| | +| \ | +| | +| \ | +| | +| \ | ++----------------------------------------------------------------------+ + +ad-server3.com → returns one inline ad, a redirect (which will error +out) and another inline ad. + ++----------------------------------------------------------------------+ +| \ | +| | +| \ | +| | +| \ | +| | +| \Ad Server 3\ | +| | +| \\\ | +| | +| \\...\ | +| | +| \ | +| | +| \ | +| | +| \ | +| | +| \ | +| | +| \Ad Server 3\ | +| | +| \\\ | +| | +| \\\ | +| | +| \ | +| | +| \ | +| | +| \ | +| | +| \ | +| | +| \Ad Server 3\ | +| | +| \\\ | +| | +| \\...\ | +| | +| \ | +| | +| \ | +| | +| \ | ++----------------------------------------------------------------------+ + +Here is the expected outcome if Ad Server 1 does full server side +unwinding. + ++----------------------------------------------------------------------+ +| \ | +| | +| \ | +| | +| \ | +| | +| \Ad Server 1\ | +| | +| \\\ | +| | +| **\** | +| | +| \ | +| | +| \ | +| | +| \ | +| | +| \Ad Server 2\ | +| | +| \\\ | +| | +| \\...\ | +| | +| \ | +| | +| \ | +| | +| \ | +| | +| **\** | +| | +| \\\ | +| | +| \ | +| | +| \ | +| | +| \ | +| | +| \ | +| | +| \Ad Server 1\ | +| | +| \\\ | +| | +| **\** | +| | +| \ | +| | +| \ | +| | +| \ | +| | +| \Ad Server 3\ | +| | +| \\\ | +| | +| \\...\ | +| | +| \ | +| | +| \ | +| | +| \ | +| | +| \ | +| | +| \Ad Server 3\ | +| | +| \\\ | +| | +| \\...\ | +| | +| \ | +| | +| \ | +| | +| \ | +| | +| **\** | +| | +| \\\ | +| | +| \ | +| | +| \ | +| | +| \ | ++----------------------------------------------------------------------+ + +You can see in the response above that the VAST document from +ad-server2.com has been copied verbatim while from the response from +ad-server3.com the second ad has been removed and the sequence indices +have been updated.