Increase ad competition with multi-size & fluid ads in AMP
AMP’s smart ad size policies ensure great UX
This post is part of a larger AMP monetization series that you can read about here.
I wish we could go back to the early days of the web and establish a policy that didn’t allow 3rd party content to resize elements on the host page. Such a policy would have created enough incentive for publishers to define a fixed size ad placeholder before making the ad request. In such a scenario, even if the ad retuned later vs content, as it regularly does, the page wouldn’t reflow in a way that would cause the user to have to readjust to the new layout.
Sadly, that’s not the world we live in. Since more ad competition per ad slot leads to better ad revenue for the publisher. It’s common to see a publisher requesting a range of sizes to fill an ad slot. No matter which ad comes back, content reflow is guaranteed.
In AMP, we took a user first approach to always reserve the space for an ad before an ad request is made.
Does that mean that AMP can’t support multi-size ads or fluid ads? No! AMP supports both multi-size & fluid (size-less, responsive) ads. Anecdotally, publishers make-up close to 90% of the revenue from the way AMP implements this support and some even 100% if they are okay with a lot of whitespace around the ad.
For those ad networks in AMP that support it (DoubleClick & YieldMo), you can use an attribute called
data-multi-size to specify additional eligible sizes, increasing ad competition.
<amp-ad width=300 height=250
AMP will reserve the primary size defined in
height but will also include the sizes from
data-multi-sizeon the ad request. By default, only secondary sizes that are 2/3rds the size of the primary ad size are included in the ad request (you’ll see why below) but this can be overridden by using the attribute
data-multi-size-validation='false`to include all secondary ad sizes.
Depending on the location of the ad relative to the viewport and the ad size returned, AMP can render the ad in a few different ways. If the ad size returned is the same as the primary request ad size, the runtime simply renders.
If the ad renders below the viewport and if the final ad size is different vs the primary ad size, then the runtime will automatically resize the ad below the viewport because that wouldn’t cause any visual reflow to the user.
If the ad renders in the current viewport and the final ad size is different vs the primary ad size, then the runtime will center the ad and place it in the middle of the reserved ad space. AMP added the ‘secondary size must be at least 2/3rds the primary size’ policy to ensure there wasn’t too much whitespace. We’ve seen some publisher override this size restrictions and have more sizes competing by placing the ad well below the first viewport and therefore ensuring that the ad would have resized by the time user got to it.
You can find more implementation details for multi-size ads here.
“Fluid ” ads
“Fluid” means that a primary ad size isn’t required at request time. The returned responsive ad will take up the entire width of the viewport and adjust it’s height according to the desired aspect ratio. To accommodate this, AMP won’t reserve a primary ad slot and will only render the ad if it isn’t in the current viewport (see how to get around this in the next section). Therefore, it’s recommended to avoid placing fluid ads in the first viewport.
You can find more implementation details for fluid here.
Using fluid as part of multi-size ads
Fluid ads are compatible with multi-size ads as long as the fluid size is the primary size. This works okay but has the same issue as standalone fluid ads — that is, the fluid ad won’t render if the ad is in the current viewport. To get around this, we are adding a feature to support fluid ads as secondary size. You can follow the approach and progress of the feature here.
The most successful AMP publishers I’ve seen have been able to transfer their existing non-AMP ad map to AMP pages and then tweaking where necessary to accomodate AMP’s static layout policies. Note, none of these features have to be AMP-specific. You can probably take these design principles and apply them to your own site. Your users will likely notice and appreciate an improved reading experience.
As always, look forward to your feedback or thoughts on this!