Happy new year!!! One year ago we announced our New Year’s resolution to help the open-source ecosystem become a little bit more sustainable. This is our one year funding report. For 2019 we intend to continue on our path with significantly increased investment.
We believe it is increasingly clear that relying on people’s volunteered free time to drive mission critical open source software is not a sustainable mode of operation. As a community we need to find new ways to fund the valuable work on such projects. We strive to provide at least some financial support to projects that we directly depend on and that are accepting support.
Last year 400 of us gathered in AMPsterdam to share the latest AMP news, and learn from the hundreds of developers engaged with the open source project. The framework has continued to evolve since our time in the Netherlands, including a new governance model and many new publishers and e-commerce websites building with AMP. In fact, we’ve seen remarkable results and growth across the Asia-Pacific region in particular. With recent examples like Indian publisher Times of India, Australian car insurance website Greenslips.co.au, and Japanese CMS EC-Cube.
This is why we’re thrilled to invite you to join us at the next AMP Conf being held in Tokyo on April 17 and 18. Come to learn from those working on contributing to AMP, those using the format, and the new committees managing the project’s governance. Whether you speak English or Japanese, you’ll find the talks engaging as we’ll be translating all the presentations into both languages. We’ll have speakers from the web developer community, core AMP contributors and companies and websites who have implemented AMP. Additionally get the latest updates on AMP stories, AMP for email and AMPHTML ads.
We also want to continue the tradition of including the broader community voices by inviting you to submit ideas for talks. We want to hear about the most interesting things you’ve done with AMP, your challenges with AMP in production, how you’ve approached building AMP pages or how AMP’s place in the web ecosystem.
To apply for a spot at this year’s AMP Conf, fill out this registration form. You can also express interest to apply for a limited number of scholarships for those who may need travel support, especially from underrepresented communities. If you’re unable to attend in person, we’ll be recording and live streaming all of the talks, so subscribe to the AMP YouTube channel to catch those videos.
Stay tuned for details on the specific talk agenda as we get closer to the event! We look forward to seeing many of you in Tokyo in less than 100 days!
Posted by Matt Ludwig, AMP Project marketing lead at Google
At LaterPay, our mission is to turn casual users into paying customers for digital content or services such as journalism, videos, and software. Our technology enables payments and micropayments without upfront registration and payment, facilitating the “use now, pay later” approach. This allows users to consume paid content and services on the internet with one or two clicks — without prior registration or having to pay in advance. It is only when the online tab’s limit is reached that users are prompted to register and pay via one of many popular payment methods. By decoupling purchases from payments, LaterPay lowers the entry thresholds for users to consume digital goods and services.
It’s almost exactly a year since we announced the launch of AMP Access LaterPay, the first AMP-enabled paywall and subscription platform that can be utilized by all publishers. The platform integrated LaterPay directly into AMP pages, allowing publishers to easily include a paywall and subscription model, in their AMP monetization strategy.
One year later, however, we continue to be amazed at how slowly the industry is moving to leverage AMP. After launching with our first customers in the US this year, and we wanted to encourage publishers to more embrace the solution and to share the lessons that we at LaterPay have learned when it comes to implementing new and innovative approaches to subscription growth.
1. Publishers should consider new monetization strategies.
The industry needs to embrace the opportunity that technology companies offer, rather than appearing more focused on explaining the reasons for failure.
One remark that repeatedly came up in connection to AMP was the claim that “Google just built AMP in order to have another way of delivering its ads to people. We don’t really trust it.” The first time I heard this it blew my mind since it’s 100% false, and it has continued to puzzle me ever since. It got me thinking about whether publishers truly prioritize user experience (an argument could be made that they probably do not) and whether they want to do business based on journalism or if they just want to keep shadow boxing an imaginary opponent who silently serves as a scapegoat for their woes.
We’ve had to engage in many educational conversations backed by hard numbers in order to explain and demonstrate how publishers can use AMP to generate incremental revenues and try out different monetization models, like the ones integrated in the LaterPay conversion funnel. What they liked best is that with AMP and LaterPay they are able to create their own conversion funnel by mixing up engagement models and payment models.
2. With great user experience driving AMP adoption, publishers should embrace technologies that bridge AMP and HTML
Publishers who truly care about a better user experience and delivering fast content need to put AMP to use and then figure out ways to monetize the traffic. The stories of how Jeff Bezos supported super-fast load times at the Washington Post, together with research proving that each second of page load time loses up to 20% of their users, probably convinced many publishers that user experience matters and fast content delivery is crucial in today’s digital world, where users start tapping on the table in impatience if they don’t see something on their screen within two seconds.
While the Post, the New York Times and a few other publishers can monetize AMP traffic outside of the advertising space, the majority cannot do so. In fact, we often hear in discussions with publishers that almost anyone who is not a top 10 publisher has the same problem: they need ways to monetize AMP content but can’t afford to build their own solution like the Post or the Times.
Nic Newman from Reuters helped identify the reason. He postulated that publishers with existing paywalls start to reach a plateau – a saturation in subscribers – at which point they simply have to think about how to continue growing. This has to happen by looking at anything supporting or complementing subscriptions and this is where LaterPay can help. AMP offers a chance to test monetization outside of existing subscription models – and this is where we started to find open doors.
3. Publishers should leverage AMP to engage and convert consumers in to paying customers.
We had to make sure publishers understood the unique value proposition that LaterPay brings to the table in general – and also specifically in the context of AMP – in order not to be dismissed as just “doing something with payments.”
We positioned LaterPay to publishers as a “metered model 2.0” that complements subscriptions and generates incremental revenues while also offering a frictionless way to monetize AMP traffic. The AMP spin is to understand that users who are not yet subscribers but have an impulse to contribute to the publisher should be given a tool to make a monetary contribution with a single click, and only be required to pay later. This works either via our contributions model (contribute now, pay later) or the single purchase model (read now, pay later). Impulse purchases have to be facilitated within seconds or they are gone and our own numbers show that 78% of all purchases enabled by LaterPay’s technology on publishers’ sites are made within 7 seconds.
Using LaterPay as a means to identify and segment heavy news consumers – consumers who are more likely to pay – across websites also helps publishers upsell users into higher priced models and create tailored offerings for them. We introduced the idea of monetizing both regular and AMP content outside subscriptions with the goal of establishing the value of the content, nurturing that value and then generating potential subscribers over time. We believe that this will help publishers understand and monetize their audience across platforms.
We backed this up by several examples, like the one small publisher, Kevelaerer Blatt, who, since starting to use LaterPay, generates 35% from selling individual articles and 53% from subscriptions, with now 200% in growth of subscription revenues.
Establishing value with every click is a path to onboarding users and converting them into paying users. Combining a la carte models to harness the great user experience that AMP offers with time passes to establish value and to practice nurturing value, in order to increase overall revenues and to increase the number of subscribers, is essential.
From LaterPay’s perspective, AMP is a huge boon to publishers, making it fast and easy to engage an audience that is increasingly prioritizing mobile search over desktop. And yet the industry continues to drag its feet. Given that AMP was designed specifically to provide a consistent experience, with rapid page-loads, isn’t it time that we all embrace it?
Over the past year we’ve been extremely excited to share that AddThis released Share Buttons available as an AMP component. Our team has been tracking the AMP project since its announcement in 2016. As the web becomes increasingly mobile, it’s important for publishers to transform into this mobile era. At AddThis, we want to make sure that we’re part of this new community and bringing value to publishers.
Our first task was figuring out what we should initially build. We love iteration here at AddThis, so we asked ourselves what our smallest usable feature set could be to ship, and then over time, we could expand our features and product offerings. AddThis offers many different tool types, but our sharing tools are by far our most used. We decided that our best bet was to get sharing supported in AMP first, and then eventually invest in adding more features and more website tools. With that in mind, we decided our Inline Share Buttons and Floating Sharing Sidebar were best suited for our first AMP release.
Building for AMP
The AddThis team is no stranger to building for and working with open-source projects. What struck us most was how supportive the AMP development community was as we went on our journey of building our extension for best-in-class sharing and social engagement tools. As soon as we declared our intent to build support, the AMP team worked with us at every stage of the process. As we hit roadblocks, we all worked together to come to solutions that made the most sense for AddThis and AMP. From submitting our first PR right up to the present day, it has been great watching such a helpful community thrive.
What’s the benefit of using AddThis Share Buttons?
Our Share Buttons come with more than 200+ global social networks and services, auto-personalized for your website visitors. Not to mention, you can customize the buttons to match your design needs.
We also provide an analytics dashboard with all our free tools to give you basic metrics such as site visits and referral data, as well as powerful statistics on sharing trends in real time and over the last 24 hours, including:
What content is being shared and driving traffic back to your site
How visitors are sharing, including address bar copy/pasting
Sharing breakdown by mobile and desktop
Email alerts when important spike changes occur
Additionally, our 24-hour support team is always on call, ready to answer any questions you may have.
We believe users should still have the same functionality on AMP that they have on other platforms, such as WordPress. With that in mind, we’ve recently released our Inline Share Buttons and we’re dedicated to making additional website tools available as an AMP component.
Posted by Alberto Medina, AMP and WordPress Developer Advocate, Google
Enabling a first-class AMP experience on WordPress is one of the ways the AMP Project aims to bring a user-first experience to websites and content on the web. There has been a lot of work over the last year to improve the quality of the official AMP plugin and today we are releasing version 1.0-stable of the Official AMP Plugin for WordPress.
Version 1.0 of the plugin integrates AMP content creation seamlessly with standard WordPress content creation workflows across both classic editing, or Gutenberg-based editing. In particular, a native AMP experience is supported in this release, allowing for WordPress sites to be built entirely with AMP, without a duplicate AMP version of a page in ‘paired mode’.
Features and capabilities of the 1.0 release include:
Content sanitizers: to help substituting HTML tags for their corresponding AMP components ones, implement optimizations, and feed validation information to the plugin compatibility’s tool (see below)
Compatibility tool: to assist the development of AMP experiences by enabling AMP debugging based on exposing extensive and detailed information about validation errors that may exist, the markup/scripts causing them, and the specific components on site (e.g theme, plugin, core) bearing the responsibility of that page content.
CSS Tree Shaking: to assist in the process of putting the CSS-house in order in cases where existing CSS rule exceed the maximum limited permitted on single AMP pages.
Core theme support: enabling full AMP validity for four default themes (i.e. 2015, 2016, 2017, 2019).
Gutenberg integration: enabling AMP content creation fully integrated with Gutenberg, the new and powerful editing experience in WordPress.
Native AMP experiences support: enabling full-site AMP experiences without sacrificing by one-bit the flexibility of the platform, or the fidelity of content.
A myriad of code, performance, and developer experience improvements: from customization flexibility, to better UI flows, internationalization, accessibility, etc. Check the full list in the release post.
Opti-in/Opt-out support: all functionality is available in an opt-in manner. And users that do opt-in have the option of enabling AMP only on specific sections of their site, and also disable AMP at a granular level (e.g. on a single post)
Compatibility enforcement: to ensure that a site stays AMP compatible and that only AMP-valid content is ever served
We invite you to try the new release by:
Upload the plugin to the /wp-content/plugins/ directory in your site
Activate the plugin through the ‘Plugins’ menu in WordPress
If you currently use older versions of the plugin in Classic mode, it is strongly encouraged to migrate to Paired or Native mode
The official AMP plugin for WordPress provides essential tools and functionality for AMP content creation, the WordPress way. It is important to note that the plugin is not a completely turn-key solution to “AMPlify your site”, but instead functions as a key enabling technology for a fully AMP compatible WordPress ecosystem.
The journey ahead is one along the road of ecosystem adoption. As we advance on this road, more plugins and themes will be available with full AMP-compatibility provided out-of-the-box, and site owners will easily find AMP-compatible components to assemble full sites when selecting plugins from WordPress.org plugins/themes page.
In the future, we expect there to be turn-key solutions site owners can leverage to easily provide awesome AMP experiences regardless of their level of savviness. Our ultimate aim is for high-quality AMP content in WordPress-powered sites to be ubiquitous.
Join us as we continue on this journey and please share your feedback on the latest release. We’re enthusiastic about the potential the plugin has to improve the user experience on the web and look forward to what is ahead.
Over the past two years, the AMP Project has been working with Igalia to identify bugs and missing features within iOS WebKit and then fix them. We create repro cases, write web platform tests, perform debugging and analysis, and, of course, write patches to actually fix things. We think this is particular rewarding work, because it helps ourselves achieve our goals faster, but also makes the web more predictable for developers overall.
In this blog post, we provide an overview of the work done in 2018 with hints about when improvements will be available in iOS releases or when they will have to be handled by Apple. Some of this work is still in progress and we keep proposing new ideas and reporting bugs.
We submitted patches for the following bugs which are now fixed in the latest iOS 12.1 releases:
We have been watching some improvements and verified that they are included in the latest iOS 11 releases. These two items were handled by Igalia in 2017 thanks to support from the AMP project:
Improving frame sandboxing, including implementations of new sandbox attribute values such as allow-popup-to-escape-sandbox, allow-top-navigation-without-user-activation and allow-modals flags. This allows apps to more securely sandbox ads from doing bad things.
Fixing flickering for fixed positioned elements in iframes when touch scrolling is on. See bug 175135
These bugs triaged by us were fixed by other WebKit developers:
We have collaborated with Igalia’s and Google’s Web Platform engineers to make the following features available in WebKit trunk. Apple does not comment on future releases but we keep watching them to verify when these improvements arrive in iOS releases.
We are thrilled to continue collaboration with Igalia and other browser developers in order to keep improving WebKit’s web platform implementations. Next year, we plan to continue the effort on the current tasks but we also have various other ideas related to networking, UI and more. Stay tuned!
Originally posted on Medium by Vamsee Jasti, Product Manager for AMPHTML ads at Google.
We’ve made a lot of progress in delivering a user-first advertising experience on AMP pages, but along the way we’ve learned that the principles of AMP pages can be transferred to display ads to make a step function improvement.
We set out to solve the issues of security & performance using AMPHTML ads (FKA A4A/ AMP ads) and have the benefits available not only to AMP pages, but also to any environment where display ads are served — regular web pages & mobile apps.
AMP’s tech lead, Malte, wrote about AMPHTML ads’ humble beginnings in this post (I’ll summarize most of it below but you should also consider reading it to know where we started and how we’ve evolved over time).
We’ve come a long way since then, and today I’d like to talk about:
What AMPHTML ads are
What AMPHTML ads aren’t
Why publishers should want AMPHTML ads
Why advertisers should want AMPHTML ads
Support status of AMPHTML across the display ads ecosystem
What AMPHTML ads are
AMPHTML ads is a framework that gives ad developers, advertisers, ad servers and publishers, the building blocks to create and deliver ads that are performant and secure.
Similar to AMP, an AMPHTML ad is only valid if it’s made of HTML + CSS + the JS from the open source AMP Project repo.
AMPHTML ads are a strict subset of the AMP page spec and ships with many good-by-default ads UI components, an analytics measurement framework, a spam detection system, viewability measurement and other goodies.
What AMPHTML ads are not (at least, not yet)
AMPHTML ads don’t ensure that the visual content of the ad is high quality.
Why publishers should want AMPHTML ads
When an ad is developed in AMP, the ad will have minimal performance impact to the web page and it gives back publishers control over the user experience of the page.
Ad creators vary a lot. Even a well-intentioned advertiser could create an ad that could lock up the CPU, janking the webpage and resulting in your visitors quitting your site. Then, there are a small minority of malicious advertisers set out to serve themselves ahead of your experience and your users. These issues can give knowledgable visitors another reason to install an ad blocker. One of the main reasons for this behavior lies in early design decision for legacy ads on the web allowed embedding ad iframes with arbitrary (a lot of times with terrible performance) JS.
Wouldn’t it be great if we could guarantee that the JS used within an ad is always performant and doesn’t deteriorate the page performance by too much? We expect AMP to meet that bar and since the code is all open source, anyone can review it and suggest changes to improve further. In addition, the following properties of AMP solve a number of issues of the display ads ecosystem:
All AMPHTML ads are statically analyzable, which means that ads can’t run:
any code that isn’t part of the public AMP GitHub repo
additional JS that isn’t part of the rendered ad code
All of the code in the AMP repo is open source which is carefully reviewed. Therefore, it can’t have things like JS that takes advantage of a chipset level vulnerability which could steal passwords entered to your websites. If a malicious actor tried to add such code, the AMP maintainers have a process in place to ensure that such code isn’t merged into the repo.
Rapid & universal upgradeability
If we discover a vulnerability in the AMP code or at lower level stack that’s taking advantage or stealing user information from your site, the AMPHTML ads runtime can be updated and most users will have the latest version of the secure ads runtime within a day.
Self-aware of page performance
Animations within an ad can have a lot of impact to page performance. AMPHTML ads automatically pause animations when they are off-screen saving precious battery & CPU.
Caching a single library
Another performance benefit of using a single ads runtime standard is that different ad functionality can reference the runtime that is in the cache across multiple AMPHTML ads served to the same browser. As the volume of AMPHTML ads increases on the web, more users will have the ads runtime available in the browser cache. Contrast this to loading two different libraries for two separate functionalities, both of which are less likely to be available in the browser cache.
Efficient rendering in same-orgin iframes
For AMPHTML ads, the ads script can serve them into iframes on the same origin as the script tag which is more efficient compared to loading the ad into a cross domain iframe. This is only possible because AMPHTML can’t have custom JS and therefore reduce risk from a security perspective.
Why advertisers should want AMPHTML ads
Built-in ad UI components
AMPHTML ads ship with a number of UI components that allow ad creators to build great looking ads, with full access to the web animations API, a first-class analytics framework and viewability support. These built-in modules are developed with performance in mind, so advertisers can be assured they are using the best in class browser/app APIs to build this functionality.
Viewability measurement without discrepancies
Viewability is probably one of the most important metrics advertisers care about, and publishers, advertisers and ad tech, each want to verify viewability on their own resulting in each inserting their own JS to collect viewability data.
Problem is, each one of them uses their own technique to collect viewabilty. This is not only a terrible waste of CPU, it leads to viewability mismatch between the three collectors. AMPHTML ads rely on browser native APIs like Intersection Observer to collect the most accurate viewability measurements and send them to anyone that requests it. Since all of this code is open source, an advertiser can inspect the collection methodology themselves if they choose to.
A lighter / more performant ad leads to more clicks and higher viewability. This should be pretty straightforward to reason, because one can’t click or view an ad if it doesn’t render on screen fast enough. This means that an advertiser should be incentivized to build a performant ad so they get more ROI on the same spend.
However, given the typical separation between advertisers, media agencies & creative agencies, the advertiser has little control over the performance of the ad created by the creative agency. AMPHTML ads ship with a development time validator which gives a boolean answer to developers as they are building an ad if it’s valid AMPHTML. If it is valid, the creator can be assured that the ad would be performant.
Create once, deliver everywhere
In the near future, an advertiser would be able to create a single AMPHTML ad and deliver across web pages, AMP pages & mobile apps. AMPHTML ads will also natively support the SafeFrame API and the MRAID API, so advertisers can take advantage of advanced host (web or app) level functionality in a uniform way.
It takes a village to make transformational changes like these, but some industry thought leaders have already spent significant amount of time & resources in helping bring more AMPHTML ads to the web. You can note current status of each of these using this link.
What’s the end goal?
With AMP’s new governance model and industry participation, we think we can help advertisers and publishers use AMPHTML ads to deliver every single ad served on the web and mobile apps. If we accomplish this, we will be in a world where:
Ads will be respectful to users’ devices and publishers’ web pages
Ads won’t impact the performance of a publisher page, earning them better revenue
Ads will earn advertisers higher ROI including better viewability
Users will be more secure on the web and therefore find fewer reasons to install ad blockers
I hope you’ll join the AMP team in helping solve one of the most important and interesting challenges on the open web — advertising.
EC-CUBE, one of the largest open source ecommerce CMSes in Japan, has released a beta plugin to use AMP for their ecommerce stores. The plugin was built by EC-CUBE’s well known partner SUNDAY SYSTEMS, Inc. in collaboration with Mobile Solutions Consultants from Google, in just one month . For websites who use EC-CUBE, you can try the plugin here.
A PHP based CMS with more than 1.8M downloads and 30K+ live merchants, EC-CUBE was seeking further opportunity to satisfy the UX of their end users. They just released their major update v4.0.0 in October 2018 which focused more on the backend performance and architecture. Now they have decided to put effort in optimizing the frontend as well, leveraging AMP and key PWA technologies. The newly released AMP plugin is still in an experimental phase but already has some remarkable features which provide faster and optimized UX/DX.
To reuse existing assets and work with their PHP developer community, the AMP plugin will convert current PHP Twig templates into valid AMP templates. No need to struggle with AMP specific syntax!
The plugin is fully integrated into the CMS admin interface. Developers will be able to turn on/off the plugin, customize layouts, build components and edit the converted AMP templates directly from a dedicated UI.
Developers will have the option of “paired AMP mode” and “AMP first mode”. In paired AMP mode the main site is unaffected, but the first landing page (such as from a search engine) is optimized using AMP. In AMP first mode, the whole site is changed to always return AMP for all pages on the site.
It also works as a PWA. Having Service Worker and Web App Manifest bundled in the plugin, developers can now add an EC-CUBE store to the homescreen of a mobile device and even think about offline use cases.
EC-CUBE has performed a trial with their default template (an ice cream shop) and have seen a significant improvement in speed, as well as their canonical features being converted correctly to AMP. For example, using `amp-sidebar` for the slide menu, fetching product options with `amp-list`, changing the price once the user selects the option with `amp-bind` etc.
In their trial, they also experimented PWA features such as add to home screen and offline browsing. Merchants can now start thinking about leveraging these App-like features in their business strategy.
We’ve seen steady growth over the past year in AMP Stories and we are delighted to see the various ways content creators have taken advantage of the rich, immersive canvas for storytelling. We’ve been testing this with a handful for pilot partners and today, we are excited to give all content creators an opportunity to monetize their stories.
Introducing Story Ads
Story Ads are fullscreen ad placements that appear in AMP stories. When we set out to create the advertising experience for story ads, we built it on top of three principles:
1. Immersive We wanted to ensure that story ads were immersive and engaging. Like AMP story content, story ads use the entire screen to convey a brand or message using a combination of video, image, or animations. A user continues the tap gesture to skip over the ad if uninterested but also has a consistent way to explore the ad using the call to action button. In addition, every ad has a ‘consistent’ ad attribution label, so users are easily able to distinguish between an ad vs organic content inside a story.
Ad placement & insertion are orchestrated by the runtime and therefore story ads are shown to the user only once they have fully loaded. As a result, story ads by definition are 100% viewable.
3. Open Continuing in the AMP project’s footprints, we wanted to create an ad ecosystem where any ad provider could participate in delivering monetization solutions for story creators. AMP now has close to 100+ ad network integrations, and we hope to achieve a similar level of diversity for publishers. If you are an ad provider that wants to integrate with AMP stories, please reach out to us.
Today, we are launching support with Google Ad Manager to deliver direct sold ads.
Editor’s note: The following was posted on Medium by Martin Schierle, Mobile Solutions Consultant at Google.
Accelerated Mobile Pages (AMP) are a great and easy way to build very fast pages, and as we know speed is key — for every second delay in mobile page load, conversions can fall by up to 20%. So obviously the first thing people do after they built their first AMP is to A/B test it, sometimes just to find out it may not perform well…
In fact it’s not as trivial to test AMP as it may seem at first. There are a few things to be aware of when you go down the AMP path of speed, and by keeping these in mind you should be just fine!
When testing AMP, different audiences often look for different metrics. Conversions are often a good target, but it’s important to keep in mind that AMP will have less impact the farther the conversion is from the AMP page. If the conversion is at the end of a 10 screen purchase funnel, it may not help much to just AMP the initial landing page, when the user might still have to navigate through nine slow pages afterwards to finish the conversion. For publishers, ad revenue is a compelling metric, but it’s often overlooked that the incremental uplift through AMP will not necessarily be seen in CPM, but rather in traffic and user engagement. For publishers it therefore makes more sense to look at revenue per session, rather than just revenue per page.
One of the most interesting and misleading metrics is the bounce rate. As page speed is directly correlated to bounce rates, and bounce rates very often directly correlate to conversions and ad revenues, this is what most people look out for when testing AMP.
And — surprise! — it’s more than likely that you’ll see higher bounce rates when testing AMP!
It is said that when the British army introduced metal helmets in WW1, the rate of head injuries increased afterwards — which seems more than puzzling. However, giving more thought to it the reason becomes clear — a lot of the soldiers who would have died without a helmet now survived (and thus, the number of absolute injuries went up). This effect is called the survivorship bias — you only measure the ones which survived, thereby introducing bias.
The same frequently happens for slow websites — your analytics package of choice might kick in really late during the loading process, and will only measure the users which made it that far. The users bouncing before analytics fires are not seen and not measured.
Consider this graph showing the cumulative bounces over the total load time of an example page.
This page loads in 15 seconds.
We add the moment in time when the Analytics provider fires the first ping: 10 seconds.
This means that we are only measuring 20% of the visitors that are bouncing before the page is fully loaded.
If we would fire the analytics ping after 3 seconds, we’d measure 45% of the visitors that bounce before the page is fully loaded.
When putting the load times and analytics pings next to one another, we can see that the AMP page measures more of the bounces that are happening.
Even if AMP outperforms the normal page, the measured bounce rate might still be higher, since we capture more of the bouncing traffic. You can solve this by improving analytics load time on canonical, or by measuring real load abandonment as described here.
The Low Bar
In a time where most websites are too slow, it often takes really dedicated users to complete a purchase funnel on mobile — whoever is willing to wait ten or twenty seconds for a website to load, is probably very determined to finish the task she came for. So if AMP gets introduced, relative conversions might seem to go down — as the bar is now so low, that even less dedicated, loyal or interested users make it to your website who might convert less frequently. Be aware that this is still incremental traffic and incremental conversions, just that the relative conversion probability might seem lower. In these cases it might be worthwhile to also look at absolute conversions and general traffic.
Many websites offer an alternative native app which shows the same content as the website, and the mobile phone might open up the native app for URLs to this domain (but not for the same content on AMP cache). So if an app user visits a page on the AMP cache and then clicks through to regular website, the native app will open instead. As most analytics packages define a bounce as a session with only one hit, such a user flow would count as bounce — even though the user didn’t bounce but potentially finished her journey successfully in the native app.
Luckily, this scenario only applies for companies with a high app penetration in the market, but is still important to keep in mind.
Visual and Functional Parity
Historically many websites implemented AMP as a parallel version of their website, as a fast entry point from search (‘paired AMP’). In some of these cases AMP was intentionally or unintentionally not equivalent to the regular page — maybe due to oversight, maybe to save resources, or maybe the two versions got out of sync over time. However — given most companies are going through massive efforts and A/B testing to get their landing pages as optimized as possible, it seems obvious that the AMP version of the same page might not perform well, if not being functionally and visually identical (at least with respect to all critical content and user actions). For a fair A/B test, the pages need to be comparable. From a visual perspective you can use the Chrome screenshot tool to create screenshots of AMP and canonical, and compare them manually or through an image diff tool (there are many available, e.g. this one). From a functional perspective it’s worth clicking through the main user actions on both versions, and make sure they feel and behave the same way — look out especially for autofills, autocompletes, search auto correction etc.
There are certain user actions on a website, which you might want to count as a successful page visit (e.g. watching a video, filling a lead form etc.). Normally a page visit with such actions is not counted as a bounce, even when the user directly leaves the page afterwards. Within Google Analytics these events are called ‘interaction events’ in contrast to ‘non-interaction events’, where a bounce is still counted. So if the regular website has many interaction events defined, but the AMP site not, this will directly influence bounce rates of both versions, and will make them impossible to compare. For Google Analytics this can be verified easily for both versions via the Google Tag Assistant Extension.
Two of the core value proposition points of AMP are AMP Caches and Prerendering. However, the delivery from the AMP cache means the initial landing page is delivered from a different host than the regular site. Given that most analytics vendors are using first party cookies (due to third party blocks as e.g. introduced through Safari’s ITP), it means a user will be assigned two different cookies with two different user ids on her journey from AMP to canonical website. This is known to (artificially) inflate user ids, sessions and bounce rates, and is explained in more detail here.
The solution is to have a unique user ID across both hosts — AMP offers this with its AMP Linker, which can be integrated by 3rd party analytics vendors, and is also integrated in Google Analytics. However — not all analytics vendors support this, and if not implemented correctly it may fail. Then the AMP visit would be erroneously counted as a bounce, as the same user wasn’t seen again on canonical. So it’s important to verify that your analytics package is sending and using a consistent client id across AMP cache and canonical — this can be verified manually through Chrome DevTools or potentially dedicated troubleshooting tools from your analytics vendors. For Google Analytics, this can be easily checked with the Tag Assistant recording feature. Here you can navigate from search result page to AMP from cache to canonical, and then doublecheck in the recording that there is only one user session counted, which started on the AMP page, and uses the same user ids across all page hits.
So what are the things to keep in mind when testing and evaluating AMP?
Make sure to verify visual and functional parity (e.g. through Chrome screenshot tool and by trying all CTAs).
Make sure that analytics on regular mweb doesn’t fire much later than on AMP, and stay aware of the blind spot and the survivorship bias.
Make sure to not measure against a goal which happens much later in the funnel after the AMP page. If you measure conversions, try to focus on those happening on AMP itself (e.g. clickout).
Be sure to keep in mind the bias through your native app, in case it has significant market penetration.
Click through the whole journey from search to regular mweb, and verify that your analytics records only one user session, which starts on AMP, and uses a consistent user ID. You can do this via dedicated troubleshooting tools from your analytics provider (if available), via Chrome DevTools (look out for user identifiers in analytics pings) or via the Tag Assistant recording feature for Google Analytics.