-
Notifications
You must be signed in to change notification settings - Fork 3.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AMP Ads For AMP Pages ("a4a") #3133
Comments
LGTM 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 |
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. |
Closing this as routine clean-up since there this has been launched. |
gexjo__ |
Motivation
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.
Requirements
The design proposed here is constrained by the desires of publishers, advertisers, and the AMP page's security and user experience requirements.
Proposed Design
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):
<amp-ad>
tag may include a new configuration parameterdata-3p-ad-request-transform-src="https://…"
. If so, the ad-network-contributed code should perform an XHR to that URL (async CORS XHR withCredentials), telling the publisher's server the constructed ad request URL and giving the publisher a chance to modify it before the request goes to the ad network. The details of this request/response/modification is TBD; as described here, its design is entirely up to the ad network.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.
window.crypto.subtle.verify
/window.crypto.webkitSubtle.verify
). This verification happens asynchronously and off of the main JS thread. (A crypto.subtle polyfill which runs on the main JS thread is not appropriate here.)<amp-a4a>
element.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:
Wouldn't That be Better Explained by a Picture?
Perhaps it would.
Initial Steps
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.Ads in AMP format will require runtime support for use cases currently handled in JavaScript. Probably the most pressing example is viewability measurement, a need which will be met by work like #3110 . Others will surely arise.
Alternatives and Future Directions
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.
The text was updated successfully, but these errors were encountered: