Should you AMP-lify your site in 2018?

This is a question on the mind of many publishers. To help answer it, this post is going to dive into case studies and examples showing results different companies had with AMP.

If you’re not familiar with Accelerated Mobile Pages (AMP), it’s an open-source project aimed at allowing mobile website content to render nearly instantly. This initiative that has Google as a sponsor, but it is not a program owned by Google, and it’s also supported by Bing, Baidu, Twitter, Pinterest, and many other parties.

Some initial background

Since its inception in 2015, AMP has come a long way. When it first hit the scene, AMP was laser-focused on media sites. The reason those types of publishers wanted to participate in AMP was clear: It would make their mobile sites much faster, AND Google was offering a great deal of incremental exposure in Google Search through the “Top Stories news carousel.”

Basically, you can only get in the Top Stories carousel on a mobile device if your page is implemented in AMP, and that made AMP a big deal for news sites. But if you’re not a news site, what’s in it for you? Simple: providing a better user experience online can lead to more positive website metrics and revenue.

We know that fast-loading websites are better for the user. But what you may not be aware of is how speed can impact the bottom line. Google-sponsored research shows that AMP leads to an average of a 2X increase in time spent on page (details can be seen here). The data also shows e-commerce sites experience an average 20 percent increase in sales conversions compared to non-AMP web pages.

Stepping outside the world of AMP for a moment, data from Amazon, Walmart, and Yahoo show a compelling impact of page load time on metrics like traffic, conversion and sales:

You can see that for Amazon, a mere one-tenth of a second increase in page load time (so one-tenth of a second slower) would drive a $1.3 billion drop in sales. So, page speed can have a direct impact on revenue. That should count for something.

What do users say about AMP? 9to5Google.com recently conducted a poll where they asked users: “Are you more inclined to click on an AMP link than a regular one?” The majority of people (51.14 percent) said yes to that question. Here are the detailed results:

This poll suggests that even for non-news sites, there is a very compelling reason to do AMP for SEO. Not because it increases your rankings, per se, but because you may get more click-throughs (more traffic) from the organic search results. Getting more traffic from organic search, after all, is the goal of SEO. In addition, you’re likely to get more time on site and more conversions.

How the actual implementation of AMP impacts your results

Before adopting any new technology, you need understand what you’re getting into.

At Stone Temple Consulting, we performed a research study that included 10 different types of websites that adopted AMP to see what results they had and what challenges they ran into. (Go here to see more details from the study.)

Let’s get right to the results. One site, Thrillist, converted 90 percent of their web pages over a four-week period of time. They saw a 70 percent lift in organic search traffic to their site — 50 percent of that growth came from AMP.

One anonymous participant in the study, another large media publisher, converted 95 percent of their web pages to AMP, and once again the development effort as approximately four weeks long. They saw a 67 percent lift in organic search traffic on one of their sites, and a 30% lift on another site.

So, media sites do well, but we knew that would be the case. What about e-commerce sites? Consider the case of Myntra, a company that is the largest fashion retailer in India. Their implementation took about 11 days of effort.

This implementation covered all of their main landing pages from Google, covering between 85% and 90% of their organic search traffic. For their remaining pages (such as the individual product pages) they implemented a Progressive Web App, which helps those pages perform better as well. They saw a 40% reduction in bounce rate on their pages, as well as a lift in their overall e-commerce results. You can see detailed results here.

Then there is the case of Event Tickets Center. They implemented 99.9% of their pages in AMP, and opted to create an AMP-immersive experience. Page load times on their site dropped from five to six seconds to one second.

They saw improvements in user engagement metrics, with a drop in bounce rate of 10%, an increase in pages per session of 6%, and session duration of 13%. But, the stunning stat is that they report a whopping 100% increase in e-commerce conversions. You can see the full case study here.

But it’s not always the case that AMP adopters will see a huge lift in results. When that’s not the case, there’s likely one culprit: not taking the time to implement AMP thoroughly. A big key to AMP is not to simply use a plugin, set it, and forget it.

To get good results, you’ll need to invest the time to make the AMP version of your pages substantially similar (if not identical) to your normal responsive mobile pages, and with today’s AMP, for the majority of publishers, that is absolutely possible to do. In addition to this being critical to the performance of AMP pages, on November 16, 2017, Google announced that they will exclude pages from the AMP carousel if the content on your AMP page is not substantially similar to that of your mobile responsive page.

This typically means creating brand-new templates for the major landing pages of your site, or if you are using a plugin, using their custom styling options (most of them allow this). If you’re going to take on AMP, it’s imperative that you take the time to get this right.

From our research, you can see in the slide below the results from the 10 sites that adopted AMP. Eight of those sites are colored in green, and those are the sites that saw strong results from their AMP implementation.

Then there are two listed in yellow. Those are the sites that have not yet seen good results. In both of those cases, there were implementation problems. One of the sites (the Lead Gen site above) launched pages with a broken hamburger menu, and a UI that was not up to par with the responsive mobile pages, and their metrics are weak.

We’ve been working with them to fix that and their metrics are steadily improving. The first round of fixes brought the user engagement metrics much closer to that of the mobile responsive pages, but there is still more work to do.

The other site (the retail site in yellow above) launched AMP pages without their normal faceted navigation, and also without a main menu, saw really bad results, and pulled it back down. They're working on a better AMP implementation now, and hope to relaunch soon.

So, when you think about implementing AMP, you have to go all the way with it and invest the time to do a complete job. That will make it harder, for sure, but that’s OK — you’ll be far better off in the end.

How we did it at Stone Temple (and what we found)

Here at Stone Temple Consulting, we experimented with AMP ourselves, using an AMP plugin versus a hand-coded AMP web page. I’ll share the results of that next.

Experiment No. 1: WordPress AMP plugin

Our site is on WordPress, and there are plugins that make the task of doing AMP easier if you have a WordPress site — however, that doesn’t mean install the plugin, turn it on, and you’re done.

Below you can see a comparison of the standard StoneTemple.com mobile page on the left contrasted with the default StoneTemple.com page that comes out of the AMP plugin that we used on the site called AMP by Automatic.

You’ll see that the look and feel is dramatically different between the two, but to be fair to the plugin, we did what I just said you shouldn’t do. We turned it on, did no customization, and thought we were done.

As a result, there’s no hamburger menu. The logo is gone. It turns out that by default, the link at the top (“Stone Temple”) goes to StoneTemple.com/amp, but there’s no page for that, so it returns a 404 error, and the list of problems goes on. As noted, we had not used the customization options available in the plugin, which can be used to rectify most (if not all) of these problems, and the pages can be customized to look a lot better. As part of an ongoing project, we’re working on that.

It’s a lot faster, yes… but is it a better user experience? Looking at the data, we can see the impact of this broken implementation of AMP. The metrics are not good.

Looking at the middle line highlighted in orange, you’ll see the standard mobile page metrics. On the top line, you’ll see the AMP page metrics — and they’re all worse: higher bounce rate, fewer pages per session, and lower average session time.

Looking back to the image of the two web pages, you can see why. We were offering an inferior user interface because we weren’t giving the user any opportunities to interact. Therefore, we got predictable results.

Experiment No. 2: Hand-coded AMP web page

One of the common myths about AMP is that an AMP page needs to be a stripped-down version of your site to succeed. To explore whether or not that was true, we took the time at Stone Temple Consulting to hand-code a version of one of our article pages for AMP. Here is a look at how that came out:

As you can see from the screenshots above, we created a version of the page that looked nearly identical to the original. We also added a bit of extra functionality with a toggle sidebar feature. With that, we felt we made something that had even better usability than the original page.

The result of these changes? The engagement metrics for the AMP pages on StoneTemple.com went up dramatically. For the record, here are our metrics including the handcrafted AMP pages:

As you can see, the metrics have improved dramatically. We still have more that we can do with the handcrafted page as well, and we believe we can get these metrics to be better than that of the standard mobile responsive page. At this point in time, total effort on the handcrafted page template was about 40 hours.

Note: We do believe that we can get engagement on the AMP by Automatic plugin version to go way up, too. One of the reasons we did the hand-coded version was to get hands-on experience with AMP coding. We’re working on a better custom implementation of the AMP by Automatic pages in parallel.

Bonus challenge: AMP analytics

Aside from the actual implementation of AMP, there is a second major issue to be concerned about if you want to be successful: the tracking. The default tracking in Google Analytics for AMP pages is broken, and you’ll need to patch it.

Just to explain what the issue is, let’s look at the following illustration:

The way AMP works (and one of the things that helps with speeding up your web pages) is that your content is served out of a cache on Google. When a user clicks on the AMP link in the search results, that page lives in Google’s cache (on Google.com). That’s the web page that gets sent to the user.

The problem occurs when a user is viewing your web page on Google’s cache, and then clicks on a link within that page (say, to the home page of your site). This action means they leave the Google.com page and get the next page delivered from your server (in the example above, I’m using the StoneTemple.com server.)

From a web analytics point of view, those are two different websites. The analytics for StoneTemple.com is going to view that person who clicked on the AMP page in the Google cache as a visitor from a third-party website, and not a visitor from search. In other words, the analytics for StoneTemple.com won’t record it as a continuation of the same session; it’ll be tracked as a new session.

You can (and should) set up analytics for your AMP pages (the ones running on Google.com), but those are normally going to run as a separate set of analytics. Nearly every action on your pages in the Google cache will result in the user leaving the Google cache, and that will be seen as leaving the site that the AMP analytics is tracking. The result is that in the analytics for your AMP pages running on Google.com:

• Your pages per session will be about one
• Bounce rate will be very high (greater than 90 percent)
• Session times will be very short

Then, for the AMP analytics on your domain, your number of visitors will not reflect any of the people who arrive on an AMP page first, and will only include those who view a second page on the site (on your main domain). If you try fixing this by adding your AMP analytics visit count to your main site analytics count, you’ll be double counting people that click through from one to the other.

There is a fix for this, and it’s referred to as “session stitching.” This is a really important fix to implement, and Google has provided it by creating an API that allows you to share the client ID information from AMP analytics with your regular website analytics. As a result, the analytics can piece together that it’s a continuation of the same session.

For more, you can see how to implement the fix to remedy both basic and advanced metrics tracking in my article on session stitching here.

Wrapping up

AMP can offer some really powerful benefits — improved site speed, better user experience and more revenue — but only for those publishers that take the time to implement the AMP version of their AMP site thoroughly, and also address the tracking issue in analytics so they can see the true results.