CRAIG DINATALI: Going from four seconds to 700 milliseconds is a dramatic improvement. The goal of AMP is to load ads and content as instantly as possible. We think there is still innovation that can happen on top of this
Do you have an AMP standard for advertisers? What are you doing to advise them?
It’s important we start getting agency and advertiser attention toward solving this problem, but it’s early on that front. We have talked with some of the creative shops about AMP for Ads. We’ve shared the open-source code and asked them to start creating mock creatives to see what kind of improvements can be made to workflow or the weight of how that creative would be sent over. There is a general industry acknowledgment that this exists, but there hasn’t been innovation on how to solve it, because I think we’ve leaned more into the never-done-before sexy creative, and less on the performance side for the consumer experience. We think you can do both.
What about options for header bidding within AMP?
There is no header [in AMP], so it’s a different implementation. But we and others like OpenX and Index [Exchange] are working to create more elegant solutions for this. We created some baseline support for it, and they are doing hard work tuning it and making it better. We are all for it, as long as it’s prioritizing speed and content first.
Besides AMP, publishers might also work with Facebook Instant Articles or speed up the mobile experience on their own. How should they choose what to do?
The industry hasn’t been doing the best job helping them prioritize these things. One of the things AMP was initially designed to solve was to make content units portable. They could publish it once and render it in many different places, which is why we have done the outreach and talked to the Twitters and Pinterests and LinkedIns of the world, so if they believe in AMP as a publisher, we wanted them to get as much use and scale on the mobile web from it as possible, and not have to do one for [each platform].
Could you link to an AMP article from Facebook if you wanted, or would you not want to do that?
You can. It’s up to the publisher.
The AMP road map includes “greater alignment between Progressive Web Apps (PWA).” What would that alignment look alike?
How much more flexible can AMP for Ads can get?
You won’t see things that cause content reflowing, things that move the content around or obfuscate or block the content. You will also start to see us innovate on the truly native or sponsored content units critical for publishers’ business in mobile. We wouldn’t have launched if we didn’t support native. Polar and Nativo have built support, but we want to allow more flexibility and creativity in how they’re implemented while not disrupting the content.
If publishers decide to speed up their pages on their own rather than use AMP, does Google benefit the same way?
We have AMP in the search carousel. We announced that we would be launching AMPs in the organic bluelinks, because we’ve seen such good results and engagement from publishers. If publishers tune their website in such a scalable way that they can create the same speed and the same experience as they can through AMP, that’s great from our perspective. As long as speed and user experience is the priority, Google is happy. AMP is one way to do that, Progressive Web [Apps] is another, and we know that others have other ways to do that.
What’s ahead for publishers using AMP?
A lot of publishers have used programmatic only, and have started to put in direct campaigns and productized offerings within AMP. They should also see continued improvements and enhancements in how programmatic works in AMP. On the open-source side, they should continue to invest and be involved with the product. We have a few publishers that have started to engage as ad tech companies in AMP, in order to bring in creative ad formats that have been proprietary to their business into the AMP environment.
This interview has been condensed and edited.