Currently <amp-ad> elements can request ad creatives written in classical HTML+JS, which therefore must be sequestered inside cross-domain iframes and loaded only after a delay, to mitigate the potential UX degradation they could cause. Even so, long-running JS inside the ads can degrade scrolling, swiping in the carousel, etc.
We propose a new ad rendering path which continues to allow HTML+JS ads in cross-domain iframes, but also allows an ad request to instead return an ad written in AMP HTML. If the ad response is AMP, then the ad can be rendered early by splicing it into the surrounding AMP page, with no need for iframing or delays, without risk to the page's UX. As a side benefit, we speed up HTML+JS ads as well, because the ad request will still run earlier than it does today; only the rendering will be delayed.
The design proposed here is constrained by the desires of publishers, advertisers, and the AMP page's security and user experience requirements.
The a4a proposal is built on the ability to prove that an ad response is valid AMP by sending a cryptographic signature for the ad along with the response. The ad gets validated and signed before serving. Validation+signing is done by a new signing service that will be run by the AMP Project, reusing the validator binary that powers cdn.ampproject.org. An HTTP API to the validation service will be open to all users. (There is an open question of which pieces of AMP functionality should be allowed within ads; the validator may enforce some ads-specific policies at signing time.) The signature gets cryptographically verified by the AMP runtime in the browser, using public keys which it fetches from cdn.ampproject.org.
We will implement this plan by adding a new custom extension, "amp-a4a", and experimentally filling the<amp-ad> slot with an <amp-a4a> element with the new behavior described below. (The script to enable the extension will be automatically loaded by amp-ad if needed — no retagging.)
Early in page rendering (starting at AmpA4A.buildCallback time):
The ad response will be processed by ad-network-contributed code, which will render the response through one of two pathways.
One possible response to the XHR is a Signed AMP Ad Creative, whose handling can continue to run without delay.
If the response is not a signed AMP creative, or if the fast rendering path fails for any reason (bad signature, browser lacks crypto, etc), then the extension instead gets to render the ad at AmpA4A.layoutCallback time, after the usual runtime-determined delay. The ad must render inside of an iframe. We plan to explore a few options for this rendering mode:
Perhaps it would.
We intend to implement the a4a infrastructure, along with model uses of it by amp-ad elements of types "adsense" and "doubleclick". We will also generate experimental AMP ads for several types of ads in which the HTML is constructed by Google's servers. New ad rendering paths can be subtle, and we will run A/B experimentation to be sure of their effectiveness.
We considered a template-based system in which ads were broken up into cacheable templates, which could be proxied through cdn.ampproject.org for validation, and simple strings, which could be expanded into the templates without breaking the validity of the document. This could have better scaling properties than needing to re-validate every ad at serving time. But it seems more difficult than the full-ad-signing approach proposed here: decomposing arbitrary AMP ads and safely re-combining a cached template with validated strings in the browser seems hard. If a template-based alternative is viable and is appealing to other ad networks, it could coexist as another form of XHR response leading to the early-rendering code path.
If web browsers implemented AMP validation as a native operation, then the cryptographic signing, or the template expansion alternative, would be unnecessary.
I'm very excited by this. It is a real chance to solve the "coordination problem" for display advertising.
One thing that should be spelled out and planned for is additional validation for ads. We should probably go with an extension whitelist (e.g. no amp-iframe) and also do additional checks on the CSS.
Will a4a distinguish between mobile and desktop clients and deliver the appropriate ads?
@dkolba A4A itself will be agnostic -- it will be up to an individual ad network's implementation to check client state and deliver an appropriate creative. (Either because the network's sub-class of A4A itself checks and crafts an appropriate URL request or because the ad network server, say, detects user agent and chooses a creative to deliver based on that.)
Hello all. Regarding the "HTTP API to the validation service will be open to all users" in the Proposed Design section above, that's of interest to me. I'm not sure the best way to help with this project but I'm interested in being involved. I maintain the Yeoman Build A Banner workflow.
What's the best way to be of help in the A4A project?
@johnfmorton A4A will have stricter rules than AMP itself and might even have a different document marker to signify being an ad instead of a doc. For now passing https://www.npmjs.com/package/amphtml-validator would be a great start. We will definitely add support for A4A validation to that module when it becomes more final.
@cramforce Thanks for the quick reply. I'll look into that.