Nov 27, 2018
Use AMPHTML ads for better ad performance, page usability & user safety
This is how we’d design ads on the web if we were to start from scratch
This post is part of a larger AMP monetization series that you can read about here.
Up until now, this monetization series was about ensuring you made the most revenue from existing JavaScript(JS) based ads served to AMP pages — which have a number of challenges independent of the web page. In this post, let’s talk about how we may approach improving the display ads ecosystem.
We’ve made a lot of progress in delivering a user-first advertising experience on AMP pages, but along the way we’ve learned that the principles of AMP pages can be transferred to display ads to make a step function improvement.
We set out to solve the issues of security & performance using AMPHTML ads (FKA A4A/ AMP ads) and have the benefits available not only to AMP pages, but also to any environment where display ads are served — regular web pages & mobile apps.
AMP’s tech lead, Malte, wrote about AMPHTML ads’ humble beginnings in this post (I’ll summarize most of it below but you should also consider reading it to know where we started and how we’ve evolved over time).
We’ve come a long way since then, and today I’d like to talk about:
- What AMPHTML ads are
- What AMPHTML ads aren’t
- Why publishers should want AMPHTML ads
- Why advertisers should want AMPHTML ads
- Support status of AMPHTML across the display ads ecosystem
What AMPHTML ads are
AMPHTML ads is a framework that gives ad developers, advertisers, ad servers and publishers, the building blocks to create and deliver ads that are performant and secure.
Similar to AMP, an AMPHTML ad is only valid if it’s made of HTML + CSS + the JS from the open source AMP Project repo.
AMPHTML ads are a strict subset of the AMP page spec and ships with many good-by-default ads UI components, an analytics measurement framework, a spam detection system, viewability measurement and other goodies.
A simple AMPHTML ad
<!doctype html>
<html ⚡4ads>
<head>
<meta charset=”utf-8">
<title>My amphtml ad</title>
<meta name=”viewport” content=”width=device-width,minimum-scale=1,initial-scale=1">
<script async src=”https://cdn.ampproject.org/amp4ads-v0.js"></script>
<style amp4ads-boilerplate>body{visibility:hidden}</style>
</head>
<body>
<a target=”_blank” href=”https://www.ampproject.org">
<amp-img width=”300" height=”250"
src=”https://www.ampproject.org/static/img/docs/ads/amp-300x250.png"></amp-img>
</a>
</body>
</html>Notice, no arbitrary JavaScript and all the code is declarative.
What AMPHTML ads are not (at least, not yet)
AMPHTML ads don’t ensure that the visual content of the ad is high quality.
Why publishers should want AMPHTML ads
When an ad is developed in AMP, the ad will have minimal performance impact to the web page and it gives back publishers control over the user experience of the page.
Ad creators vary a lot. Even a well-intentioned advertiser could create an ad that could lock up the CPU, janking the webpage and resulting in your visitors quitting your site. Then, there are a small minority of malicious advertisers set out to serve themselves ahead of your experience and your users. These issues can give knowledgable visitors another reason to install an ad blocker. One of the main reasons for this behavior lies in early design decision for legacy ads on the web allowed embedding ad iframes with arbitrary (a lot of times with terrible performance) JS.
Wouldn’t it be great if we could guarantee that the JS used within an ad is always performant and doesn’t deteriorate the page performance by too much? We expect AMP to meet that bar and since the code is all open source, anyone can review it and suggest changes to improve further. In addition, the following properties of AMP solve a number of issues of the display ads ecosystem:
Statically analyzable
All AMPHTML ads are statically analyzable, which means that ads can’t run:
- any code that isn’t part of the public AMP GitHub repo
- additional JS that isn’t part of the rendered ad code
Trustworthy
All of the code in the AMP repo is open source which is carefully reviewed. Therefore, it can’t have things like JS that takes advantage of a chipset level vulnerability which could steal passwords entered to your websites. If a malicious actor tried to add such code, the AMP maintainers have a process in place to ensure that such code isn’t merged into the repo.
Rapid & universal upgradeability
If we discover a vulnerability in the AMP code or at lower level stack that’s taking advantage or stealing user information from your site, the AMPHTML ads runtime can be updated and most users will have the latest version of the secure ads runtime within a day.
Self-aware of page performance
Animations within an ad can have a lot of impact to page performance. AMPHTML ads automatically pause animations when they are off-screen saving precious battery & CPU.
Caching a single library
Another performance benefit of using a single ads runtime standard is that different ad functionality can reference the runtime that is in the cache across multiple AMPHTML ads served to the same browser. As the volume of AMPHTML ads increases on the web, more users will have the ads runtime available in the browser cache. Contrast this to loading two different libraries for two separate functionalities, both of which are less likely to be available in the browser cache.
Efficient rendering in same-orgin iframes
For AMPHTML ads, the ads script can serve them into iframes on the same origin as the script tag which is more efficient compared to loading the ad into a cross domain iframe. This is only possible because AMPHTML can’t have custom JS and therefore reduce risk from a security perspective.
Why advertisers should want AMPHTML ads
Built-in ad UI components
AMPHTML ads ship with a number of UI components that allow ad creators to build great looking ads, with full access to the web animations API, a first-class analytics framework and viewability support. These built-in modules are developed with performance in mind, so advertisers can be assured they are using the best in class browser/app APIs to build this functionality.
Viewability measurement without discrepancies
Viewability is probably one of the most important metrics advertisers care about, and publishers, advertisers and ad tech, each want to verify viewability on their own resulting in each inserting their own JS to collect viewability data.
Problem is, each one of them uses their own technique to collect viewabilty. This is not only a terrible waste of CPU, it leads to viewability mismatch between the three collectors. AMPHTML ads rely on browser native APIs like Intersection Observer to collect the most accurate viewability measurements and send them to anyone that requests it. Since all of this code is open source, an advertiser can inspect the collection methodology themselves if they choose to.
Development-time validator
A lighter / more performant ad leads to more clicks and higher viewability. This should be pretty straightforward to reason, because one can’t click or view an ad if it doesn’t render on screen fast enough. This means that an advertiser should be incentivized to build a performant ad so they get more ROI on the same spend.
However, given the typical separation between advertisers, media agencies & creative agencies, the advertiser has little control over the performance of the ad created by the creative agency. AMPHTML ads ship with a development time validator which gives a boolean answer to developers as they are building an ad if it’s valid AMPHTML. If it is valid, the creator can be assured that the ad would be performant.
Create once, deliver everywhere
In the near future, an advertiser would be able to create a single AMPHTML ad and deliver across web pages, AMP pages & mobile apps. AMPHTML ads will also natively support the SafeFrame API and the MRAID API, so advertisers can take advantage of advanced host (web or app) level functionality in a uniform way.
Ecosystem Status
It takes a village to make transformational changes like these, but some industry thought leaders have already spent significant amount of time & resources in helping bring more AMPHTML ads to the web. You can note current status of each of these below:
What’s the end goal?
With AMP’s new governance model and industry participation, we think we can help advertisers and publishers use AMPHTML ads to deliver every single ad served on the web and mobile apps. If we accomplish this, we will be in a world where:
- Ads will be respectful to users’ devices and publishers’ web pages
- Ads won’t impact the performance of a publisher page, earning them better revenue
- Ads will earn advertisers higher ROI including better viewability
- Users will be more secure on the web and therefore find fewer reasons to install ad blockers
I hope you’ll join the AMP team in helping solve one of the most important and interesting challenges on the open web — advertising.
