How Airbnb is putting AMP at the core of its digital strategy

Accelerated Mobile Pages (AMP) is an open-source initiative that aims to render and deliver content at high speed on mobile devices.

Originally aimed at publishers (who have had a love-hate relationship with AMP to date), AMP has since been adopted by ecommerce sites including eBay and has been incorporated into elements of Google AdWords, DoubleClick and AdSense. It would be fair to say that Google has been a very vocal supporter of the initiative from day one.

AMP utilizes a stripped back version of HTML and JavaScript to provide much faster page load times. Search results that are coded in AMP HTML are accompanied by a blue lightning bolt and users can swipe through similar stories.

In practice, we often find that making things faster can be a very slow process. And AMP is no different.

Although providing a better user experience sounds like an obvious choice for a brand to make, there are some significant logistical implications when AMP is implemented. The AMP version of a page is shown in search results and sits alongside the original version in the site architecture, which brings with it a range of challenges for many websites.

As such, it is always fascinating to hear how brands are assimilating AMP into their existing workflows.

At TechSEO Boost, Gil Birman and Brian Ta from Airbnb delivered an enlightening presentation that revealed how the company is using AMP to help prioritize speed within their customer strategy.

Undoubtedly, a slicker and faster experience could improve conversion rates. Birman and Ta talked through the mitigating factors that needed to be taken into account first, before discussing the novel solutions they had to devise to get AMP code working on such a complex site.

Prioritizing sections of the site

The three main hierarchical levels of the Airbnb (Read more...) are the homepage, the search results pages, and the listings pages for each property. These are referred to as P1, P2, and P3, respectively, by the internal teams at Airbnb.

Although specific to this type of company, these should still be recognizable for most marketers as the home page, the category level, and the product level.

The four criteria in the screenshot above (traffic impact, page volatility, technical challenges, and page ownership) were assessed for P1, P2, and P3 of the site to decide which would receive the AMP treatment first.

Striking the right balance proved a challenge, given that the aim is to showcase the positive change AMP can bring in terms of traffic and revenue, without causing excessive disruption to valuable pages during the process.

For example, the homepage performs very well in terms of traffic, but it would require approval from numerous teams and is updated very frequently. As a result, the team decided against implementing AMP on the homepage.

The search results pages (P2) were chosen as the most suitable testing ground at the end of this assessment. They receive enough traffic to show a marked difference if AMP is effective and changes at this level would cause less disruption than they would on the homepage.

Although very specific to Airbnb, there are lessons here for any marketer planning to implement AMP. It is essential to draw up a list of decision criteria and apply these consistently across the site, as it is advisable to test AMP on one section before switching over the whole domain. This depends on the number of pages in play, of course, but for any larger site this should be seen as a best practice approach.

Building the minimum viable product

The team at Airbnb aimed to get AMP off the ground by building a minimum viable product that could showcase the technology’s capabilities and help to iron out any bugs before rolling it out across other sections of the site.

This was approached by tackling some essential questions up front:

How does AMP work within the existing website framework?
How would implementing AMP across search results pages (P2) interfere with the rest of the site architecture?
What does adding AMP do to the workflow of other developers at the company?
How does AMP affect design, user experience, and the overall Airbnb product?

These questions provide a useful starting point for any business planning large-scale technical changes. It is imperative to understand how this new code will assimilate with the existing product, of course. But the human element needs to be considered, too. Implementing AMP will affect a range of internal teams, so it is advisable to hold the requisite meetings before launch to avoid challenges further down the line.

The initial questions led to a list of considerations to be assessed as the project progressed:

How could AMP be developed into a fully functioning product across all sections of the site?
How will the added complexity be managed as the site evolves?
What will it take to get other teams to engage with the project?
Who will own and maintain the project?

Although these may not be the most exciting points to ponder, their answers can mean the difference between sustained success and protracted failure.

Additionally, having these considerations in mind provides a framework against which progress can be judged. As the team at Airbnb found out, there is no guarantee that meticulous planning will lead to favorable results. However, the right planning can help to correct course if things do go wrong.

Even the best-laid plans go awry

Websites resemble living organisms. They are constantly moving and evolving. To create a parallel version of a full section of a complex website brings an inevitable degree of disruption to this delicate ecosystem.

When that disruption occurs, issues tend to arise. Occasionally foreseen, they are often impossible to predict as they result from an entirely new interaction.

This was the case with the implementation of AMP at Airbnb.

One such obstacle was the server-side time-out that started to occur when a page render exceeded 500ms.

Although AMP creates a faster loading experience for the end user, it does create more requests on the server side. Google should redirect users to the canonical version of the page (ie. the non-AMP version) in these instances, but instead it simply showed an error message.

As a result, the user sees nothing but a blank page.

This started to happen 16% of the time with AMP-enabled pages, so a solution was required quite urgently.

To minimize the distances between server and user, content delivery network (CDN) caching was implemented. CDN caching allowed stored files to be held, ready to load at an accelerated pace. Therefore, the time-out issue could be circumvented and users would see the AMP-enabled version of the page.

There were other obstacles to surmount before AMP was up and running. The team at Airbnb found that logged out or first-time visitors to the site on a mobile device would be served the AMP-enabled version of the search results pages.

Logged in users were dropped into an inconsistent experience, however. Typically a logged in user will see a personalized version of the site, based on their preferences and past behavior. With AMP enabled, Google was showing the logged out experience to all users, meaning that anyone with an Airbnb account would not see any of the usual features, such as their received messages or past bookings.

This issue is resolved if the user clicks through again to the main site, but it is far from an optimal experience and the team is still working to arrive at a suitable solution.

The Airbnb team also found that AMP overrides deeplinking, meaning that Google would no longer pull content from within the Airbnb app. Customers are not always aware that deeplinking has occurred, as they click on a search result and are met with suitable content. Nonetheless, this content is often pulled from the company’s app and tends to provide a better user experience.

Airbnb, like many similar companies, feels that the app provides a more efficient booking journey, so this was a significant drawback for the AMP project.

This led the team to conclude that in this guise, AMP was not viable for wider implementation. The potential benefits were too rewarding to ignore, so Airbnb has instead focused on a new solution that brings increased speed without the technical issues.

The ‘Magic Carpet’ solution

Magic Carpet is a landing page system that has allowed Airbnb to create a new experience for first-time visitors to the site via SEO. The new page contains all the functionality of the typical site experience, but it also features clear calls to action so users know exactly what to do.

The screenshot below highlights the differences between the standard search results page (on the left) and the ‘Magic Carpet’ version (on the right):

This solution is a clear example of a team taking on board lessons from the initial experiment. Where users may initially have been confused by the Airbnb experience as a first-time visitor, they are now met with an AMP-enabled, simple booking journey. Due to the recent nature of the project, results were not available to share, but the team has plans to roll this out globally in the near future.

Although the presentation took a different narrative route to the traditional case study, which often covers up the bumps in the road to present a glossy set of exceptional results, the Airbnb talk provided an instructive look at real-world problems. The AMP implementation has not been without its hiccups, but there is a widespread understanding at the company that speed will be a competitive advantage if they can get it right. It just might take some time to make things faster.