Google has been actively pushing AMP (Accelerated Mobile Pages) since it launched last year. The company prioritizes AMP in the news carousel (increasing search traffic) and AMP pages are also showing up as regular search results, not just news searches.
But AMP still has a way to go. In pursuing speed, the open-source project limits ad formats and makes techniques like header bidding a work in progress. Only baseline functionalities work at the moment.
Despite these issues, AMP’s improvements in speed create other advantages. More than 80% of 150 AMP publishers see higher viewability rates, according to Google. Ninety percent of AMP publishers saw improved click-through rates and most saw higher average CPMs.
Heading up the AMP project is Craig DiNatali, the global director of emerging products at Google. He talked to AdExchanger about AMP’s progression and what’s in store for the project.
AdExchanger: How far have you come in correcting the disconnect between content load and ad load in AMP, and how much further do you have to go?
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?
They both exist to prioritize speed and make the web great, and do it in fundamentally two different ways. The Washington Post, as an example, just announced implementation of AMP and PWA. Publishers are starting to think about “What is my first experience,” whether it’s search or social platform, to “What is my ongoing experience on my website?” Right now, AMP lets you choose what that ongoing experience would be. You can link to your own website, or the Post can link to their PWA experience. From the ad experience perspective, because AMP limits the JavaScript that could be run and used on the site, there is a little bit more limitation right now in actual creative units [than with PWA].
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.
