Skip to main content

Instream video ad in a Protected Audience sequential auction setup


This demo is a proof of concept created for illustrative purposes only, and should not be taken as a recommendation or standardized implementation of this use case.

☝️ Use the tabs to navigate to other sections in this document

If you have any questions and comments for this instream video ad demo, use the instream video ad demo post in the Discussions tab.



This demo shows one of the ways that VAST XMLs can be handled in a Protected Audience sequential auction setup when the ad is rendered in an iframe. In this demo, a pre-roll video ad has been implemented, but the same mechanism can be used to render other video ad types that use the VAST XML standard, such as mid-roll and post-roll instream video ads.

The following features have been implemented:

  • The SSP's VAST XML wraps around the DSP's VAST URI
  • A unique ID is appended to the reporting URLs in the VAST XML
    • This unique ID is also propagated to the header bidding auction, ad server auction, and every Protected Audience auction worklet
  • The finalized VAST is messaged out of the creative iframe to the video player

Note that this mechanism does not work with Fenced Frames, but Protected Audience allows iframe usage until at least 2026.



  • Chrome > v120 (Open chrome://version to look up your current version)
  • Enable Privacy Sandbox APIs (Open chrome://settings/privacySandbox to enable this setting)

We are in the process of enrolling the new endpoints. Until then, visit chrome://flags/#privacy-sandbox-enrollment-overrides and add the following origins to the Privacy Sandbox Overrides textbox.

Origins for the enrollment override:,,,,


The query param that enables the video ad demo on the advertiser and publisher sites is ?auctionType=multi.

  1. Navigate to advertiser site:
  2. Navigate to publisher site:
  3. Click ‘Play video’ when the button is ready


The finalized VAST XML is messaged out of the iframe to the publisher page, and that VAST is passed to the video player. The finalized VAST contains the DSP+SSP wrapped VAST and a unique ID appended to URLs in VAST. The server-side VAST transformation is conducted by the SSP.

When the DSP adds the render URL, a query param macro is added that specifies the SSP's VAST serving endpoint (i.e. When the SSP constrcuts the component auction config, the macro replacement is defined (deprecatedReplaceInURN: { '%%SSP_VAST_URL%%': '' }). When the ad is rendered, the macro is replaced by the value defined by the seller in the component auction config.

When the ad is rendered, the creative code parses the SSP's VAST URL from the query params, and makes a request to that endpoint, with the DSP VAST URI and the unique ID set as query params. On the server, the SSP wraps its own VAST XML around the DSP's VAST URI, and appends the unique ID to the URLs in the VAST. The SSP's server responds to the creative's request with the finalized VAST. The finalized VAST is post-messaged from the iframe to the publisher page, and that VAST is passed to the video player.

Macro substitution for component sellers

The deprecatedReplaceInURN() function allows macros to be replaced in the winning ad's render URL.


deprecatedReplaceInURN('%%SOME_MACRO%%', 'some-value')

This mechanism can be used to pass information into the creative iframe, like the winning SSP's VAST URL. However, since this feature will become available M123, this demo adds a render URL for each SSP, then filter the render URLs when generating bids, as a temporary mechanism for passing the SSP VAST URL to the creative.

Privacy Sandbox APIs involved

  • Publisher (News site)
  • Advertiser (Shoping site)
  • Ad Server / Top-Level seller (Ad server)
  • Component Seller A (SSP-A)
  • Component Seller B (SSP-B)
  • Demand Side Platform A (DSP-A)
  • Demand Side Platform B (DSP-B)