We would like to configure one of the ad calls on our AMP pages to accommodate multiple sizes. I mentioned this on Friday's Ads Working Group call and was told that this may be possible as long as we are comfortable with potential white space. The ad call we are interested in adjusting is the 1030x590 (displays at approximately 345x420). We would like to also be able to call a 300x250 to that ad slot.
We would like this change to made across all browsers and device types
This has always been an issue and affects all versions of AMP
I'm not sure this is a good experience, but it might work well for creatives further down a page. Would this be for DFP specifically?
@cramforce On the call (no pun intended), we explored the possibility of amp-ad taking additional sizes as input (in addition to the primary w and h - additional sizes need to be smaller than primary sizes), pass those sizes along to the ad server (Could be any ad server, but let's take DFP as an example - because it supports multi-size). If the ad server returns an ad with primary size, do nothing and display ad - if ad returned is smaller, render smaller ad but fill remaining space with whitespace. If technically possible, it'd be great to fill remaining space with color of the parent.
@cramforce Confirming we use DFP. @jasti This would be a perfect strategy for us. Can you clarify what you mean by filling the remaining space with parent color? Would that be the background color of the page?
@nedward3 By parent color: instead of filling with 'white' space, if technically possible, fill with the color of the surrounding element so the 'white' color doesn't stand out in contrast.
Background color of the page may be one option but I'm thinking of a scenario where the background color is different than an element that surrounds the ad.
I think the color stuff is fully up to the page. I believe the ad starts out transparent.
This is definitely something that can be implemented. Just needs to be prioritized against other work. Also happy to guide external contributors, of course :)
@nedward3 any chance you or anyone from the team is willing to contribute? Think it'll be an awesome feature to have that'd help a lot of publishers.
@jasti Definitely. @elitetruong from our Partner Platforms team can help with this.
@nedward3 Excellent. @elitetruong Welcome! https://github.com/ampproject/amphtml/blob/master/DEVELOPING.md
Hi @jasti! We're currently figuring out when we can work on this with our internal revenue teams and getting priorities together. In the interim, what would be our next steps to test or implement dynamic ad calls?
Thanks, @elitetruong. @cramforce, would you be able to guide please?
@michaelkleber what's the best way to pass in an optional multi-size on amp-ad, so the ad server extension can take advantage of requesting a multi-size request to the adserver? (As JSON parameter on amp-ad or as a new optional attribute in amp-ad? Something else? )
Key restrictions is that the additional size should be smaller than width and height defined on the primary W and H attributes.
Also, we should think about what/ how we fill the 'whitespace' difference between primary ad request size and the ad size returned - if the two are different.
Most straight forward would be to support passing dimensions down as JSON. In this proposal, they always be smaller then the slot, right?
Correct, always smaller than W and H on amp-ad.
I can imagine two ways this could work. Roughly:
(1) AMP allows an iframe that's the only child of a fixed-sized div to resize itself any time without user interaction, even if it's on-screen. Then any ad network that supports multi-sized ads could use their existing multi-size mechanism with a postMessage to AMP to ask for a resize. The
(2) Ad networks support a request of the form "Give me an ad of any of the following sizes, but pad it out to WxH for me." Then no change from AMP is needed.
Both of these require real effort on the part of the ad networks, though, right? I don't see how AMP could implement this without changes on the ad serving side.
I was hoping this would be more straightforward, without any work on the ad server. We definitely don't want to do 2) (Invasive & large changes on the server side for every ad server).
Sending a multi-size request to the ad server is a trivial change but : a) Receiving smaller size and b) padding with whitespace (transparent/ publisher defined), both need to happen on the client side.
@nedward3, @elitetruong : Can you think of any AMP (client) side solutions for a) and b)? It's hard to make the case for ad server side work. Thoughts?
Doubleclick.js code already has a notion of the slot width being different from the request size (hxW) parameters as mentioned here: https://github.com/ampproject/amphtml/blob/5c2710de99a55b0c8c5a6008734db54a558efb93/ads/google/doubleclick.md#ad-size
could we extend the override height & widths to take more than one size (as long as in the multisize case, all of them were less than the slot width & height or else ignore the ones that were larger) and pass those values to the ad request (GPT would already handle it, Glade will need some changes...)... the contract remains that the slot created is of the slot size specified and if the d response returned is of a smaller size it gets white /transparent space around it?
The work is a composite of: (1) making a multi-size ad request. (2) resize or pad ad slot while ad is loaded
For (1), it seems to be very ad network specific. I don't feel the need for a common setting.
For example, DFP has this Flexible Sizes support, it let you define ranges but not exact sizes. We should let 3P code to deal with the configuration.
For (2), basically 3P ad iframe needs to tell runtime the size of the loaded ad. we could potentially have that info sent with the render-start event. @michaelkleber is this something easy to get at ad rendering time?
@lannka Not right now, no. You're talking about every ad in the world exposing a new API, right? When AMP wanted empty slots to collapse, we only needed to add a postMessage to the thing that's returned when there is no ad. That's much easier than adding a postMessage to every ad!
It's certainly possible to do in the future, but would require work on the ad serving side (from every ad network that wanted to support this).
Hey @ampproject/ads team. Any ad servers that are willing to support multi-size requests, please chime in.
DFP is beginning to work on a feature to pass creative width and height on creatives returned.
From what I understood after reading this thread:
Is that a correct understanding? Also, I'm guessing, the postMessage applies for units that load with one size, but resize after a user interaction?
When yieldmo-rao is right, then this is already possible using window.context.requestResize(width, height), see readme.md
@yieldmo-rao you're right that the resize can be initiated by the creative, however, right now it doesn't work if the creative is in nested iframes. It's an ongoing effort to make it work though. To my understanding, iframe needs to load a JS to be able to use the API.
I was thinking of having runtime to initiate the resize. It can be triggered by the render-start event. If 3P network sends the size as the payload, runtime will try to resize. It should be a simpler solution to 3P network. It also comes with other benefit once you implemented render-start event.
@lannka Thanks for that! So you're saying that we listen to render-start and return a size as the return payload for that event? We have some formats wherein it resizes after the 1st resize pass - e.g. initial ad loads, causes a resize. User then starts interacting with the ad and it resizes again. So for such use cases, we will be using a combination of render-start + regular resize?
@yieldmo-rao for those creatives, yes, creatives have to use the resize API.
Changes for AMP runtime include:
#4588, amp-ad supports render-start event API, this provide a way for AMP runtime to be aware that ad is rendered is ready to resize. #4720 is an improvement to render-start API. so that only one of render-start/no-content will be listened.
#4842 modify render-start API, ad server that support multi-size ad can pass in the returned ad size. AMP runtime will try to resize amp-ad when this message is received.
work on our end is done.