How Prebid on AMP Works
AMP is deprecating
remote.html for DoubleClick by March 29, 2018. We will be building support for AMP RTC through Prebid Server before then.
For more information, see this issue.
This page has information about how Prebid.js works with AMP to show Prebid ads on AMP pages.
The diagram below shows how the pieces fit together. In the list below, the items with numbers correspond with the numbered actions in the diagram.
- The content page (
publisher.com/amp_page.htmlin the diagram) is just a normal AMP page that serves over HTTPS
- It has a
metaelement pointing to the cross-domain host where Prebid.js runs (in
remote.html). It needs to be a cross-domain host so that Prebid.js can execute in a secure environment that doesn’t affect the AMP page.
- It uses the
amp-adelement, which loads an iframe from a different domain (which is what we call the “cross-domain host” below). This element contains some JSON configuration info which is sent to the cross-domain host.
- It has a
The creative (
creative.htmlin the diagram) is what your ad ops team loads into your ad server. It’s a mostly standard Prebid.js creative with a few tweaks to allow it to work in AMP-land, and it’s what serves into the iframe defined by the
When the creative is delivered into the
amp-adelement, it posts a message to the cross-domain host (
remote.html) asking for Prebid creatives.
The cross-domain host (
amp.publisher.com/remote.htmlin the diagram) runs a Prebid auction, fetching creatives for each of the ad slots defined in the content page.
The cross-domain host, having run the auction across N bidders and fetched creative content for each ad slot, posts a message back to the creative with the actual content to render.
- The creative renders the creative content it receives from the cross-domain host, and an ad is shown to the user.
For more information, see the AMP example in our Github repo (which uses the same filenames as in the diagram below), and the Related Topics list at the bottom of this page.