Facebook says the idea for adding Accelerated Mobile Pages and Apple News support to its Instant Articles toolkit came from frustrated publishers asking for an easier way to produce all three formats.

That rings true; format fragmentation is a growing burden for news publishers. But generating Accelerated Mobile Pages (AMPs) from Instant Articles seems like a strange answer to the wrong question. Instead of looking for incremental improvements to the underlying problem, publishers and platforms should revisit the premise that all of these formats are necessary in the first place. What if one distribution format could work across multiple platforms?

Consider AMP, Instant Articles and Apple News, which are essentially three different ways of presenting news articles.

Of those, AMP is the only non-proprietary format — and by far the most flexible. Instant Articles policy forbids ads above the fold, limits ad frequency and blocks ad networks except Facebook’s Audience Network. Facebook restricts the types of links allowed and where they can appear. With no navigation to the publisher’s website, Instant Articles keep the consumer in Facebook’s app.

Facebook’s restrictions (and lack of compensatory reach) have led several major publishers to pull back or abandon Instant Articles entirely, shifting their focus to the more open, revenue-friendly AMP format. In that light, it’s hard to see how an AMP generated from an Instant Article — inheriting its limitations — would be very useful. Publishers could modify the AMP code to insert the elements Instant Articles disallows, but then how much effort is saved by using Facebook’s tools?

It makes more sense to use AMP as the common distribution format. The AMP standard didn’t exist when Instant Articles and Apple News were first launched — but now that it’s established and ubiquitous, it can provide the control and performance platforms require and improve publisher ROI. It could lower the cost of participating in walled gardens and possibly lure back some of the defectors.

There are a couple of ways this could work; here’s one idea using Facebook as the example:

A Facebook AMP cache?

Contrary to common belief, AMPs don’t have to be served by Google. For example, web performance and security company Cloudflare has a white-label AMP cache to serve AMPs on publishers’ own domains.

Facebook could manage an AMP cache as well, which would allow it to do three things:

  1. Ensure super-fast delivery, like Instant Articles.
  2. Serve validated AMPs from its own cache instead of cdn.ampproject.org.
  3. Make certain modifications to the AMPs it presents in its own environments.

Such modifications could include stripping out forbidden elements, or even replacing ad tags and analytics tags. Publishers could consent to these modifications as part of their inclusion in the platform’s products. (Arguably, Facebook should just present AMPs in their original state as long as they pass validation and let publishers make their money; the point is that platform-specific rules are possible.)

The experience might be less pristine than today’s Instant Articles, but it could be just as fast — and still much cleaner than standard mobile articles. Publishers could focus on optimizing a common format, and Facebook could become an influential partner in the AMP Project instead of trying to sustain Instant Articles.

Platforms already using AMP

Other platforms have already embraced AMP. Twitter recently started linking to AMPs from its mobile web app and plans to start surfacing AMPs in its iOS and Android apps soon. LinkedIn presents AMPs in its news feed, and Bing displays AMP results in it search app. (None of these platforms has its own AMP cache; they’re using Google’s cache, Cloudflare’s cache or linking directly to the publisher AMP.)

For most platforms, using AMP is a no-brainer. They get the performance benefits of a standardized format without having to convince publishers to build anything new. At this point, only a platform with the clout of Facebook — or the installed base of Apple News — has the ability to make publishers jump through hoops to produce a proprietary format.

And there’s still a big, valid reason why they’d hesitate to give that up.

Control and governance

Here’s the hang-up: It would be surprising for Facebook or Apple to make a significant investment in AMP while Google holds so much influence over the format’s direction and features. The AMP Project is collaborative and open-source, but Google still manages the roadmap.

Hopefully, this state is temporary. Google seems to want to help AMP leave the nest, and the company takes every opportunity to disavow proprietary ownership of the format. Participation by Facebook, Apple and other platforms would provide a counterweight to Google in the AMP Project, opening the door for even greater ecosystem investment and ultimately benefiting everyone, including publishers and Google. The transition to a new governance structure will be delicate and bumpy, but necessary.

Publisher influence

Rather than simply reacting to the choices platforms put in front of them, publishers can guide this discussion. Platforms are more engaged with the publishing industry than ever before — and they are looking for wins. The AMP Project itself was the result of publishers working with Google to address major performance and engagement problems with the mobile web — and publishers continue to advance the AMP standard by advocating for the capabilities they need.

When it comes to the problem of proprietary format fragmentation, publishers must continue to use their collective leverage and ask for the right things. In this case, that means challenging all of the platforms to live up to the principles of collaboration and efficiency they espouse. That would be a huge win for everyone.

Some opinions expressed in this article may be those of a guest author and not necessarily Search Engine Land. Staff authors are listed here.

About The Author

It's only fair to share...Share on Facebook0Tweet about this on TwitterShare on Google+0Pin on Pinterest1Email this to someone