By the end of February, Google will deploy at full scale its Accelerated Mobile Pages project by sending search results to amp-html pages. Because it integrates all monetization instruments —advertising, analytics and now subscription systems— Google’s AMP is likely to rally scores of publishers.
Over 5000 developers registered to the Github repository of Google’s Accelerated Mobile Pages (AMP) program. Some are just sniffing around, others actually work for large or small organizations and are truly committed to build something.
In a few weeks, Google will open the floodgates connecting AMP to its search engine. Twitter and Pinterest will follow. A request from a mobile phone will call a AMP-coded page (when available) that will load at blazing speed. That’s the plan. For a glimpse of what it will look like, try the demo version from your mobile, or add “/amp” at the end of any Guardian page’s URL. Tested from a poor mobile connection, the result is compelling.
How does Google pull this off? AMP redesigns core components of the Internet’s historic Hypertext Markup Language, now re-christened “amp-html”, and supports it with a massive distributed caching system in which Google hosts pages for a few seconds or hours, in multiple caches spread around the world to be closest to the user. All publishers have to do is provide two versions of their pages, one for direct access from a well-connected desktop, and an AMP version for mobile. I goes like this:
When a page is called from a mobile through search, Twitter or other, the user is directed to the super-fast page. Et Voilà. (More about the whole concept in this previous Monday Note and on AMP official blog, written in plain English.)
As of today, Google is reluctant to speculate about the number of publishers that will be on board when the AMP program launches late February. Expect several hundreds in Europe and in the United States. All the big players are working on AMP, from the New York Times to Vox Media; it will spread quickly as specifications cover more web components. As the number of publishers rises, the system will become more visible in Google search pages thanks to a larger corpus of news elements coded in AMP.
A positive effect of page ranking
The snowball effect will also apply for another simple reason: AMP-HTML coded items will show better in Google SERPs (Search Engine Results Pages.) If Google product managers adamantly insist on the absolute neutrality of Search, it is a known fact that rendering speed is a key contributor to better rankings. In itself, this factor should act as a powerful stimulus to create AMP pages.
Other incentives center on the monetization side of the program. On the advertising side, most ad servers (not just Google-owned DFP) will be able to send ads in AMP pages. Some work remains to be done on the formats that will be deemed acceptable in AMP pages.
Privately, Google people make no mystery of their intention to clean the advertising mess. They want to get rid of the invasive formats that, by ruining the user experience, contributed to the explosion of ad blockers and threatened a large segment of the digital economy. To that end, the AMP ecosystem is their weapon of choice
Between Google’s AMP engineering team and the advertising community, interests collide. The former are focused on accelerating the rendering of mobile pages and restoring a decent user experience on mobile; the latter prioritizes value extraction of above all other considerations.
Even if the company won’t publicly admit it, Google plans to lean on AMP to curb advertising excesses on media sites. Hence the initial idea to constrain the formats allowed in the AMP ecosystem. According to Google indisputable argument, pages that render four times faster on a smartphone will cause users to increase their page-views per session and to see more ads as a result.
For their part, ad buyers face pressure from creative people who want to splashiest possible formats to fit the (presumed) aspirations of their brands clients. From the mobile user’s perspective, fluffy ads translate into pages that take forever to load, and into a strong incentive to jump elsewhere: about half of users will leave a mobile site that takes more than 6 to 10 seconds to load.
Nevertheless, the advertising community now seems on board with the AMP project. Richard Gingras, head of News at Google and project lead, wrote this in a recent blog post:
[Media] Buyers have also been engaged: Annalect (Omnicom Media Group) is currently reviewing the project (…) Advertising companies that have expressed their intention to support AMP include: Outbrain, AOL, Taboola, OpenX, DoubleClick, AdSense, Pubmatic, Integral Ad Science, Moat, Smart AdServer, Krux, Polar, Nativo and Teads.tv.
I’m not so sure that having on board internet nuisances such as Outbrain or Taboola is such good news. With remarkable consistency, these two disfigure thousands of sites across the world by inserting grotesque promotional or editorial recommendations in news pages. As for Teads.tv, it created many unseen-before video formats that should be rewarded by ad blocker companies for their ability to trigger user rejection. It will be interesting to watch how Google contains these companies’ propensity to impact user experience in such negative fashion.
For good measure, let’s also mention that AMP places a bet on native ads integration; Google will propose its own product as well as third party solutions such as the Polar platform.
From Google’s standpoint, the priority given to speed justifies a certain inflexibility in its drive to use AMP as the prime argument to get rid of bad ads. Even if some rapprochement is under way, the ad community seems a bit too slow to respond while publishers don’t feel like they are in a position to pressure them…
To me, the surest way to make progress is a decisive move from the creative advertising side. Instead of fighting for the status quo, agencies should devote more resources to come up with truly creative formats that fit AMP specs. And publishers should take the user’s side.
In building AMP, Google had to deal with the multiple flavors of analytics asked (and sometimes actually used) by publishers. News media have a strange relationship to analytics. They want to use most of them as if they would warrant performance. But, unlike e-commerce sites, media are not culturally accustomed to make intensive use of data. Instead of embedding just a couple of analytics code segments in their pages, some sites end up using dozens of those. Such non-choice proves efficient at slowing down the rendering of these pages. Smartly, the AMP team decided early on to team up with Chartbeat, probably the preferred analytics tool in the news community. Today, multiple web metrics providers are on board, including Moat (who partner with Chartbeat), Nielsen, ComScore, Parse.ly, ClickTale, Adobe Analytics, etc. It is unclear, though, how AMP will be able to discourage publishers to install too many of those.
A major break, through the paywalls
One of the most complicated issue the AMP engineering team had to deal with was the implementation of paywalls. These are insistently asked by publishers ranging from The Wall Street Journal, The New York Times and European publishers such as the FT or Les Echos. Due to the widely distributed architecture of AMP in which a single page could be replicated hundreds of times all over multiple caches, reproducing a metered system, the partial display of a story, or a login flow was quite a task.
The good news is: It’s done.
This week, AMP’s engineers will release the version 0.1 of the code that allows publishers to implement paywalls in the AMP ecosystem. This is a critical feature for the economy of quality news media — an advantage that Facebook’s Instant Articles, or Apple’s News are nowhere near to offering.
How does AMP paywall support work? Let’s start with a simplistic sketch summing up today’s situation:
The main drawback is obvious: each time users flush their cookies, they start over for free. That’s why the most stringent paywalls require a registration. This carries two advantages: cheating is more difficult, and the user can be followed from one device to another. Then, why did so few publishers elect to not require a registration? Again: the non-choice syndrome. They want to win on both ends, subscription and advertising.
Now, let’s move to the AMP-implemented paywall. It carries two complications: the caching system and the dual nature of the documents with the AMP pages coming from search, social etc, and non-AMP pages, that are not cached —in the latter case, the system works as described above.
Then let’s focus on the AMP-pages paywalls. Publishers involved in discussions came up with demands (not only is the publisher poor, rarely tech savvy, but also demanding and sometimes arrogant —just kidding.)
The requirements were:
— A metered system with a number of free articles
— [or] Limited viewing of a document (as the WSJ does when the main part of the article is masked to non subscribers)
— Ability to customize the user experience for subscribers, such as removing ads.
Naturally, publishers wanted to have full control of the parameters for the metering system, the login/authentication process, the tracking the users and the possibility of changing all sorts of settings on a per document level… “Vaste programme” would have quipped General De Gaulle.
It goes like this (the chart below is based on numerous discussions I had with the engineering team. It is a bit simplistic.)
Again, for the sake of clarity I passed over several features, including many events on the reader side that occur right within the browser’s AMP Runtime. As you might have noticed, AMP introduces several new components such as the AMP Reader ID, a unique reader identifier as seen by AMP and issued by it. At some point, the AMP Reader ID will be reconciled with the regular cookie issued by the publisher, to highlight a returning reader, or a known subscriber for instance. Also not shown are three elements provided by the Publisher: the Access Content Markup which defines which part of the document are visible under which circumstances; the Authorization endpoint that sends back a response stating which part of the document the reader can view; and the Pingback endpoint used to send the “view” impression of the document. Go to Github today or later in the week for complete specs.
Summing up, when it comes to implementing paid subscriptions support, the AMP team has gone way further than expected. What is still a preliminary version of specs already allows numerous paywall fine-tuning possibilities. And there is more to come.
Original URL: http://feedproxy.google.com/~r/feedsapi/BwPx/~3/_nW93UBcFn8/