AMP for Ads


In our previous Lift Letter, we discussed AMP generally (see here: AMP Overview). Publisher monetization is a core piece of AMP, though handled separately. As discussed, AMP often substitutes conventional HTML tags with AMP tags for various purposes (generally to ensure fixed sizing and deferred and asynchronous loading of assets). For ads, the AMP version is the amp-ad tag. Generally, the javascript that controls AMP is called the AMP runtime, and for the purpose of ads, all sorts of decisions are made by the AMP runtime that simply don't exist in the normal web environment. 

The amp-ad tag is very complex, and actually bifurcated by the nature of the ad tag. AMP does not necessarily need to load AMP ads. If the ads are not AMP ads, the AMP tag amp-ad creates a special environment for the ad where no javascript from the ad can load at the level of the container AMP document. This ensures that the requirements of AMP, such as making the content load first and not allowing remote assets to block content loading, are enforced. This environment is called a "sandbox" and it enables the browser to tamp down aggressive animations or CPU utilization. 

If the ad is rendering inside a "sandboxed" iframe, its rendering is delayed until content etc has loaded. This sandboxing also has the effect of not allowing ads to measure certain user behaviors and also ensures the ad doesn't negatively impact the speed that the ads are loaded. The AMP sandbox even allows the AMP runtime - if it decides there are too many "sandboxes" on the page - to simply unload some sandboxes from the page (prioritizing those the user has scrolled past). This means the AMP runtime can elect to delete ads on the page if it so chooses. While this is extreme, it does speak to the level of control and authority that is given to the AMP runtime when rendering ads - or anything, for that matter - on an AMP page. AMP does not allow an ad to measure its own viewability (because it can't interact with the top-level AMP document which gives it the necessary information about when it's in view), there is a function that ads can use to call when they're viewable. This will call enable the ad to specify a that the AMP runtime will call when the ad is viewable, though it's not immediately clear to me how this allows third parties to independently verify viewability. 

The ad called by the amp-ad tag can also be written in a subset of AMP, as a special AMP-compliant ad. In this case, because the sizing etc is known, the amp-ad tag will render the ad directly into the page, and not in a sandbox. It is immediately rendered (in something called a shadow DOM).  This process, and its interaction with the AMP runtime, is many times faster, but does create many more restrictions for the developer of AMP ads. Fundamentally, AMP ads can only access just a subset of AMP functionality and are restricted in various ways by the AMP runtime. 

Normal ads can load arbitrary javascript and completely control the environment in which they operate. AMP, in general, only allows things that are visible to animate. AMP ads are likewise restricted, but will be further throttled - before anything else - if the page cannot animate at 60 frames per second (an industry standard for a fluid experience). It may turn off animations of the ad altogether if the AMP runtime cannot achieve the necessary frame rate. AMP ads do not allow autoplay of any video content (even volume off). For viewability, however, AMP provides analytics packages that can be used for measurement. 

AMP ads are further restricted in a number of ways. There is an absolute limit to the length of the ad's CSS, it only allows certain CSS transitions / animations, AMP ads cannot call other AMP ads (meaning pass-backs etc are more challenging), and only a subset of all HTML is allowed. Further, because the AMP ad would be integrated into the layout of the AMP page like normal AMP content. AMP can't trust that any old ad request will return proper AMP, though, so AMP-compliant ad servers have to be blessed by the AMP team and return special cryptographic information. 

AMP, at its core, is about loading and rendering content immediately, and handling everything else later. Ads are part of the "everything else" - and if you visit an AMP site, you will likely see that the AMP ads are slow to load, if they render at all. AMP is not good for publishers if they can't monetize. One main reason is that because, as previously discussed, the content of the page is cached and loaded very quickly - it is ready very quickly. Ads still load at their normal speed, which is less quick, and since they're further demoted by AMP, it's even less speedy than AMP. You can't cache ads the same way because that wouldn't work in a real-time context. The AMP 4 Ads initiative was meant to achieve something of a compromise - to allow ads to be rendered quickly (though not as quickly). It is very early in its development (TL is an early supporter), but - as discussed above - is not without its own flaws. 

The AMP initiative is open source and hosted on GitHub. It is actively being developed. With several publishers recently pulling out of Instant Articles, there is likely going to be increasing momentum behind AMP. As a result, it is likely that many of the current shortcomings will eventually be addressed in one form or another - so, while it's still somewhat difficult today - I'm optimistic that AMP will be successful for mobile web monetization in the future. Eventually.