Leverage rich media ad support in AMP pages
Take advantage of delivering direct-sold, engaging ads to AMP pages
This post is part of a larger AMP monetization series that you can read about here.
For more than 99% of the existing ads in the world, the publisher and the advertiser don’t have to do anything to get display ads working on AMP pages. Most ads ‘just work’.
Less than 1% of the ads may require some work, but this isn’t work that’s AMP specific. Before I explain what I mean, it’s useful to understand the current state of rich media ads across the display ads industry.
The term rich media is confusing because it means two distinct things lumped into a single term.
Type 1, Expressive Ads: it’s when an ad is more expressive in its default state post rendering. For example, it’s one that has video or audio or has animations versus a simple image or text ad. Lets call this type 1 for ease of reference later. Type 1 ads are supported in AMP by default because all AMP does is render the JavaScript ads (unless you are delivering AMPHTML ads, which will be explained in a separate topic) into an iframe and execute them as is. Therefore, for example, if the ad uses a HTML5 video player or has JavaScript based GreenSock animations, they will render just fine.
Type 2, Interactive Ads: it’s the ability for an ad to show a different state of the ad when the user interacts with it. For example, on interaction, an ad that expands to the full screen of the device and allows the user to play a video game within the ad itself. Let’s call this rich media type 2.
Type 2 is what we’re going to address in more detail here.
Creative APIs in AMP
All ad networks that serve display ads to a publisher page serve them into non-friendly cross-domain iframes. You want these to serve as unfriendly iframes so that the ad can’t do things like manipulate the content of the parent page or expand themselves beyond the iframe container. There are a crop of “innovative” ad format companies that cheat same-origin policy by having publishers host a “buster” file on the host domain which make the cross-domain relationship, friendly. This has two issues:
- If the ad format company is compromised, the publisher has opened themselves up to a large amount of risk, including the ability to steal credit card form information from the parent page.
- The ads themselves are obnoxious & intrusive which may result in users not wanting to return to the publisher site or worse installing an ad blocker.
Needless to say, users and publishers are protected from such bad behavior on AMP pages. Since a lot of AMP pages are loaded from the AMP cache, hosting a buster file on the publisher domain doesn’t help with making the iframe friendly.
The IAB and the ad industry have a solution to this problem called SafeFrame which establishes a line of communication with the parent page to bring the type 2 behavior to ads with the parent page’s permission.
Use the IAB’s industry standard — SafeFrame API support in AMP pages to have the ads interact seamlessly with the parent page
AMP pages support the SafeFrame API and as long as the ad network serving the ad also support the API, the type 2 rich media ads should have no problem rendering interactive ads on AMP pages.
Google Ad Manager (formerly DoubleClick for Publishers) supports the SafeFrame API and by default serves all ads into a SafeFrame. Note that AMP pages have specific rules around causing reflow without user interaction, so be sure to read about the Google Ad Manager’s SafeFrame API support in AMP pages. In addition, AMP also supports additional methods that aren’t shipped with the standard spec. For example, a purpose built position tracking API & the ability to shrink ads as well.
AMP supports more than 100 ad networks and, since not all ad networks support the SafeFrame API, AMP created it’s own API called the ‘window.context API’. In addition to providing similar functionality to the SafeFrame API, it also exposes important page level information like the top level domain and more to the ad network.
Serve direct sold ads to AMP pages
For large publishers, direct sold ads can represent a large share of their revenue and those are also the ads which are custom hand built that fall into the rich media type 2 category. AMP wants to ensure that publishers are able to maximize revenue for ads that generate the maximum yield. Instead of opening yourself up to security vulnerabilities across the ad ecosystem, simply ask your ad creator to support the SafeFrame API and have that ad work consistently across the web.
Summary
Given the many players in the display ad ecosystem, it can be confusing to figure out whether a certain creative is compatible with AMP pages. In almost all cases, a JS-based ad would just work. For publishers who want to confirm, you can simply ask your ad creators/ vendor if they support the SafeFrame API; if they do, chances are the ad will work as is or with the slightest of changes.
The simplest way to check might be to render the ad in a test page. If you find a case that isn’t supported, we’d be happy to work with you to incorporate support for it. GitHub is a great place to reach out to the AMP team.
