AMP Page / Ads Status in the Bid Request

[Haskell Garon]

Hi all,

Here is a Google proposal for 2.6+ to indicate whether a page is AMP and the requirements for AMP ads in the request.  We'll follow up later with a seperate proposal around returning AMP ads in the bid response.  

Due to sharing settings on our docs, I may need to approve comment access individually, so bear with me.

Haskell

[Ian Trider]

Hi Haskell,

There's something I've never quite understood about this. Can you elaborate or point our where I'm going wrong with this line of thinking:

1. Ads are invoked on an AMP page using the <amp-ad> element, right? 
2. An IFRAME is spawned inside of which the ad provider can run arbitrary HTML and JavaScript.
   
3. The ad provider could be an exchange (say, AdX).
4. The arbitrary JavaScript from AdX could further output more arbitrary HTML and JavaScript (within the IFRAME sandbox), such as that which would come from a DSP in an ordinary bid response.
5. Therefore, DSPs don't need to take any special action to access inventory on AMP pages -- the ad provider must provide an AMP-compliant means of invoking ads, but from there out its no different than ordinary.

I'm sure I'm missing something here, because that line of thinking implies that no special indication of AMP would be necessary in the bid request and there wouldn't be an AMP-specific ad creative needed in the response.

Thanks!

[Haskell Garon]

Hi Ian,

That's correct.  Today, DSPs can return non-AMP ads to any pages whether they are AMP pages or not, and no special action is required from DSPs, as you mentioned.  This proposal is primarily for future proofing; there are 2 pieces:

1. Indicate whether a page is AMP or not (Site.amp in the proposal) -- which may be useful to DSPs who want to optimize or report on whether a page is AMP.

2. Indicate any requirements or behavior around AMP ads (Imp.ampad in the proposal).  Today, AMP ads are not required on AMP pages.  In the future, some publishers may either choose to render AMP ads immediately and non-AMP ads with a delay, may require AMP ads only, or perhaps may not allow AMP ads.  

Let me know if that clarifies.

Best,

Haskell

--
You received this message because you are subscribed to a topic in the Google Groups "openrtb-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openrtb-dev/0wyPsF5D07Q/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openrtb-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[boke...@gmail.com]

Various questions:

• If you think this flag is going to impact how the DSP selects creatives, shouldn't it be part of the "Banner Ad Types" list (section 5.2)? Or Protocols (section 5.8) - though that seems to be just for video at the moment? It feels to me like we're starting to see a bit of Frankenstein's monster syndrome with all of these different formats and media types added piecemeal, and it would be great to see this reunified - perhaps that's in 3.0.
• I personally would prefer simplicity to precision - as you mention on my comment in the document, it *could* impact DSP decision-making to know whether amp ads will get rendering precedence, but in practice I can only think of one case where a DSP would actually factor that in: if it had identical amp and non-amp alternatives for the same creative. But... if AMP ads don't get precedence, I can still safely return the AMP creative. So the flag doesn't really create meaningful value for the DSP. Omitting this detail makes it easier to move amp support into an existing list.
• Most important - how does the DSP indicate that the creative returned is in amp format? I think we need this so that the publisher/SSP can drop the necessary AMP framework JS as needed if it's not in an AMP page. Again, it would be great to overload something that exists already instead of adding new AMP-specific fields. It's possible that this is part of creative pre-registration, but I don't think all SSPs require that.
• Does it make sense to think about how to use the AMP analytics framework to allow the DSP to register for events that may not be in the creative? This is currently all sitting in VAST grossness in the video case, and jammed into creative HTML in the banner case. A content-aware version of OpenRTB could be very powerful.

On Friday, February 17, 2017 at 10:50:26 AM UTC-5, Haskell Garon wrote:

[Haskell Garon]

Hi Brian, thanks for the questions.  Answers inline below.

On Wed, Feb 22, 2017 at 1:55 AM, <boke...@gmail.com> wrote:

Various questions:

• If you think this flag is going to impact how the DSP selects creatives, shouldn't it be part of the "Banner Ad Types" list (section 5.2)? Or Protocols (section 5.8) - though that seems to be just for video at the moment? It feels to me like we're starting to see a bit of Frankenstein's monster syndrome with all of these different formats and media types added piecemeal, and it would be great to see this reunified - perhaps that's in 3.0.

Tying this to Banner Ad Types is problematic in that AMP ads will support <amp-video>, and therefore we would prefer not to tie this explicitly to the banner object.  That said, if others feel strongly that this enum should be represented elsewhere, we're not religious that it needs to be in the Imp object.  Agreed on the broader point that there is ample room for general cleanup in 3.0  

• I personally would prefer simplicity to precision - as you mention on my comment in the document, it *could* impact DSP decision-making to know whether amp ads will get rendering precedence, but in practice I can only think of one case where a DSP would actually factor that in: if it had identical amp and non-amp alternatives for the same creative. But... if AMP ads don't get precedence, I can still safely return the AMP creative. So the flag doesn't really create meaningful value for the DSP. Omitting this detail makes it easier to move amp support into an existing list.

I'd be curious to hear from other DSP companies on this point, but another case would be if a bidder has an AMP ad, but may bid differently (or not at all) based on whether that AMP ad will be early rendered or not -- as this could significantly impact performance of AMP ads.

• Most important - how does the DSP indicate that the creative returned is in amp format? I think we need this so that the publisher/SSP can drop the necessary AMP framework JS as needed if it's not in an AMP page. Again, it would be great to overload something that exists already instead of adding new AMP-specific fields. It's possible that this is part of creative pre-registration, but I don't think all SSPs require that.

The Google team is still working on the proposal for how AMP ads should be returned in the bid response; we'll follow up once we have something ready for broader review. 

• Does it make sense to think about how to use the AMP analytics framework to allow the DSP to register for events that may not be in the creative? This is currently all sitting in VAST grossness in the video case, and jammed into creative HTML in the banner case. A content-aware version of OpenRTB could be very powerful.

The AMP creative is fully compliant with the events listed in amp-analytics, and DSPs / creatives can opt into receiving these events.  Do you have a list of specific events in mind?  We'd be open to feedback on how to improve or expand this.

 

On Friday, February 17, 2017 at 10:50:26 AM UTC-5, Haskell Garon wrote:

Hi all,

Here is a Google proposal for 2.6+ to indicate whether a page is AMP and the requirements for AMP ads in the request.  We'll follow up later with a seperate proposal around returning AMP ads in the bid response.  

Due to sharing settings on our docs, I may need to approve comment access individually, so bear with me.

Haskell

--

[Haskell Garon]

Following up on the bid request proposal, attaching proposal for bid response and overall RTB flow for DSPs and exchanges.