AMP Roadshow is coming to Atlanta & Berlin!
AMP

AMPproject.org moves to amp.dev!

Websites

It’s been over 2 years since the current version of ampproject.org launched, just before the very first AMP Conf in early 2017. Since then the AMP Project has grown a lot and launched entirely new applications of AMP on the web like emails and stories. Additionally AMP resources were scattered across multiple websites like ampbyexample.com and ampstart.com. So we decided to bring everything together into something new, better organized and easier to use.

To bring all of AMP under a new home, we’re thrilled to announce amp.dev! The all new amp.dev will replace ampproject.org in order to provide developers (and their business counterparts) everything they need to know about AMP across all its various forms. And of course, it’s built entirely with AMP, using AMP optimizer to make the site load even faster when not served from a cache.

The all new amp.dev homepage

On amp.dev you’ll find information for all the applications of AMP- sorted by color across websites, stories, ads and email. Overall the documentation section was designed to make navigation as straightforward as possible. Guides and tutorials are sectioned by stages in the AMP developer workflow. This will give you the resources and confidence to build successful AMP sites at each step in your process!

Documentation across websites, stories, ads and emails

All of the existing ampbyexample.com resources, as well as the templates on ampstart.com have been migrated and integrated into various sections of amp.dev. We also have new sections like Use Cases, where you can find a gallery of different possibilities of creating with AMP. While this section only as a few items at the moment, it will continue to grow in the coming months.

The Use Cases section of amp.dev

For a brief time we’ll be leaving AMPproject.org up to allow for a smooth transition to the new site. However, in the near future we’ll be setting up redirects as we begin to turn down AMPproject.org. For now, we have banners on each site to indicate the upcoming change. The blog (what you’re reading now) has already moved to blog.amp.dev.

Finally, just as the AMP Project is a community effort, we invite you to share your feedback on the site so we can make it the best it can be. We’ve created a feedback form linked from the bottom banner of every page so we can ensure to get your thoughts and issues if something needs fixing. As with before, amp.dev is maintained on the docs repo of the AMP Project on Github, so everything is publicly viewable. You’re able to file Github issues there as well.

A big thanks to our friends at Jung von Matt TECH who have been working on this for many months. We’re excited to continue to evolve amp.dev alongside the AMP Project and to show you bits of how we did it at AMP Conf in Tokyo next month.

Posted by the core maintainers of amp.dev: Paul Bakaus, Sebastian Benz, Crystal Lambert, Matt Ludwig

Guest Post: AMP Email

Email

Editor’s note: The below was originally posted on gregable.com by Greg Grothaus, Software Engineer, Google

Google just officially launched AMP Email, with support from other webmail providers. I work for Google on AMP and worked on some aspects of this project. I thought I’d add my own thoughts on the announcement. My opinions are my own and not those of my employer.

The press has focused on the user experiences in AMP Email. This makes total sense, given the audience. My take, however, is that the more interesting development is the step towards standardizing of HTML Email. Let me explain.

Let’s take a step back and consider non-amp HTML email. The basic idea is that the sender provides two variants of each email using MIME type encoding. Here’s a simplified example:

From: "Senders Name" <sender@gregable.com>
To: "Recipient Name" <recipient@gregable.com>
Content-Type: multipart/alternative; boundary="bdac7942f697eecfbdac7942f697eecf"

--bdac7942f697eecfbdac7942f697eecf
Content-type: text/plain;

Some text content.

--bdac7942f697eecfbdac7942f697eecf
Content-type: text/html;


Some bolded html content.




--bdac7942f697eecfbdac7942f697eecf

An email client is free to choose which of these 2 alternatives to display and more importantly how to render the bytes.

An email client is not itself a web browser, even if it runs within one. Allowing arbitrary HTML email to run with the full API of a web browser simply fails. The first thing most marketers would do is add a redirect to their own site the moment the email loads.

Simply mitigating redirects and similar is insufficient. The privacy of the user reading the email must be protected. In the case of Gmail and many other webmail clients, the client actively prevents the sender from learning the user’s IP or browser fingerprint. This is fundamentally different from how web browsing works, so browsers fail to provide protection. When browsing, your browser sends your IP address, browser name, and capabilities along to every page that you visit.

A webmail client must then contort it’s presentation of HTML, a language not designed with email in mind. Webmail clients only have two ways of doing so:

  1. Show only the text version of an email.
  2. Modify the HTML before delivery such that the resulting document is safe.

Webmail clients do both. In some cases, the client falls back to text. In most cases, it modifies the HTML.

This is typically called “HTML sanitization”. For some examples:

  • <script> tags removed completely.
  • Image URLs are rewritten to load the images from the webmail provider.
  • Some or all CSS is removed completely.

In many cases, the HTML gets horribly mangled and then shown to the user completely broken, but at least it does not violate the user’s privacy expectations.

A sender must ensure that the email sent will not arrive completely broken.

Each webmail provider sanitizes HTML emails slightly differently. In some cases, not so slightly. The rules for the sanitization are necessarily complex, as HTML is complex. As a result, the documentation describing these rules is often poor or even missing. It’s almost never the case that two email providers will treat the same email the same way.

Some references to support my point:

Webmail Rendering Explained: Why Preprocessors are the enemy:

“Most preprocessors err on the side of being overly restrictive and remove anything with even the slightest potential to affect the layout of their email client.”

Developing HTML Emails for Gmail: 12 Things You Must Know:

“Many email developers know how tricky it is to develop HTML emails for Gmail – it’s one of the more temperamental clients out there (although it’s no Outlook).”

Mailchimp: Testing Emails:

“If you’re a web designer, you’re probably used to testing web pages in a few different browsers, like Internet Explorer, Mozilla Firefox, and Safari. And you’re probably familiar with a few annoying inconsistencies between all the browsers, and you have a couple hacks to make things look right. For email design, multiply all that by ten. There are tons of email applications out there that you need to test on, and they all render HTML email in their own annoying ways.”

See Mailchimp’s Email Client CSS support matrix to get an idea of the mess you can expect if you want to write an HTML email.

Beyond documentation, none of the major webmail companies provide testing tools. This has resulted in a small industry of services that exist simply to help you test whether or not an HTML email will render correctly.  Try this query to get an idea: [html email testing tool]. These services work by maintaining accounts on major mail providers, automating test emails, reverse engineering the sanitization layers, and staying on top of changes.

AMP improves on some of these problems.

With AMP Email, there is a specification for an email sender to develop against. That specification is complicated and evolving, like the others. The documentation is incomplete, like the others.

What’s different about the AMP Email spec?

There is a single specification which multiple webmail companies are implementing. The announcement lists Gmail, Yahoo Mail, Outlook.com, and Mail.Ru. The list is incomplete, but is a solid start.

Open source tooling can validate an AMP Email. Developers get detailed error codes including line numbers and documentation links. The tooling can be run locally as an NPM library or online:

A screenshot of the AMP Validator showing an example AMP Email error.

If a developer meets the specification, the promise is that the email will be correctly rendered in every supporting html mail client using every modern browser. The spec and the web mail implementations continue to guarantee the privacy of the user reading the email.

That’s the punchline as I see it: AMP Email is a consistent format that “just works” for developers trying to send HTML email.

There are a few other concerns that have been raised, but I feel some of them are uninformed, while others may be valid:

This is a proprietary format

The specification is open-source and is just a subset of HTML, but it is managed by the governance of the AMP Project. Also note that in effect HTML Email is a set of proprietary formats. No web mail provider supports arbitrary HTML.

Email should be plain text

Perhaps. There is certainly an argument to be made here. I personally suspect that users may be making the wrong dichotomy here: not that HTML email is bad, but junk email is bad and junk email tends to use HTML formatting.

Furthermore, AMP HTML Email does not change the story. No mail provider that currently does not support HTML email also does support AMP HTML email.

HTML email usage seems to be increasing. Simply bolding text or adding an image to an email makes it HTML email, which can be a better experience for most users.

AMP HTML Email still includes a text fallback mime type for users who prefer it.

Yet another format

The concern here is that since not all email clients support AMP HTML email, this effectively added 1 new mime format in each email, rather than simplified anything. This is a valid concern. However, any proposal that requires all email providers to make a simultaneous change is doomed to fail. In the long run, hopefully this simplifies and improves the state of email.

Posted by by Greg Grothaus, Software Engineer, Google

App like animation experiences in AMP

UI

The AMP UI Working Group is responsible for AMP’s visual components & interactions and AMP’s overall accessibility and experience. This means we often work on visual polish for existing components in an effort to improve a website user’s experience. As a result, existing AMP pages on the web automatically get the improved user experience with zero effort on the side of the engineering teams that deployed them. Sepand Parhami, an engineer on the core AMP team, recently worked on creating more like app animation experiences for <amp-lightbox-gallery>, showing this idea in action.

App like swipe to dismiss in <amp-lightbox-gallery>

When dismissing an image while exiting lightbox mode, the transition back to the inline image is sudden as you can see below:

Inspired by apps such as Google Photos and Apple News, Sepand worked on making this interaction more intuitive and delightful for users. While transitioning out of lightbox mode, we wanted the user to:

  • Know when they have crossed the threshold of interaction after which they are dismissing the lightboxed image.
  • Identify the position of the image inlined into the original page they were viewing.

This information is provided by the size of the image and the lightbox background changing as the image moves from lightboxed state to it’s inline position. You can see the improved experience below:

Improved transitions for entering and exiting lightbox states

Another bit of visual polish we’ve added to <amp-lightbox-gallery> is the improved transitions for all images going to and from lightbox mode. Often the inline image is cropped or scaled to focus on the important part of the image, while the lightbox view shows the entire image. This has been a hard problem to solve, as it involves interpolating between two images of different positions and sizes.

As you can see above the inlined assets are cropped to focus on the important aspects of the image worth calling out in the article. However, you can see the full image when it is in lightbox mode. You can play with this demo here.

Creating a new animation library

To create the experiences stated above Sepand open sourced an animation library which helps you transform an image from one position/size to another. In addition to scaling up, this also supports changing the ‘crop’ of the image as defined by the object-fit CSS property. He shares his learnings in creating this library here. The blog post highlights the difficulties he came across while generating keyframes, catering for CSS properties like object-fit and object-position and testing his code.

Check out the library (code, documentation, demos) to see how to deploy the library on your own page. It is also available via npm.

Continued adoption of best-practices

To ensure we are providing site users a great experience by default, the AMP team has also been ramping up another experiment that automatically lightboxes <amp-img>s on a page that meet a certain criteria. The criteria includes factors like image size and whether or not it has an action associated with it or it’s ancestors. This allows end users to better explore the images on a page without developer teams having to make extensive changes to their codebase.

Improvements like the ones highlighted above are great examples of how engineering teams who use AMP get the benefits of all of the lessons learned by other teams that contribute to the AMP Project (e.g. Google, Pinterest and AliExpress). As the AMP Project finds incremental ways of improving the end-user experience through research and experimentation, we can upgrade extensions to provide improvements to end users without the involvement of the engineers working on deploying AMP sites.

Posted by Naina Raisinghani, Product Manager, AMP Project at Google

Building the future of email with AMP

Email

The AMP Project’s mission is to enable more user-first experiences on the web, including web-based technology like email. For most of us, not much has changed in email functionality since the first time we were introduced to email. Because AMP is inherently fast and secure, we brought AMP technology to email in order to give users an interactive, real-time experience that also keeps inboxes safe.

AMP now enables all-new email experiences like being able to submit RSVPs to events, fill out questionnaires, browse catalogs, or respond to comments right within the email. Emails can also stay up to date, displaying the freshest content from comment threads or the latest recommendations.


Dynamic email built using AMP by Ecwid

Bringing AMP emails to major email providers

The AMP for email spec has engagement from major email providers around the world including Gmail, Yahoo Mail, Outlook.com, and Mail.Ru. As each of these providers launches support, senders will scale the reach of their AMP emails to users.

After a developer preview with top email senders, Gmail is launching general availability of AMP for Email today. You can head to the Gmail blog to see some illustrative examples of the email recipient experience. You can also check out these provider specific pages for additional information:

We aim to provide the highest quality email experiences for our consumers and we are excited to be one of the first providers to participate in the AMP for email spec. This allows us to enable fast, responsive, and high-performing experiences right within email.

Marcel Becker, Director Product Management for Yahoo Mail

If you develop an email provider and would like to consider adding AMP for email support, you can find more information here.

Start creating AMP emails today

Email senders can begin creating AMP emails by using the playground which allows you to edit markup and see real-time changes to your email. For more information about the supported features and syntax, head over to amp.dev. It’s important to note that some providers may have sender whitelists that limit who is eligible to send AMP emails, so be sure to register with providers if that’s the case.

If you rely on a third party for your emails, please ensure they have AMP support. The following email products already support the AMP spec or in the process of launching support soon:

  • SparkPost, an email delivery and analytics platform
  • Litmus, an email design and marketing tools suite
  • Twilio SendGrid, an email platform for transactional and marketing emails that is used by over 80,000 companies.
  • Amazon SES and Amazon Pinpoint, cloud-based email sending and analytics services for transactional and marketing emails
  • More are in progress, so contact your email service providers to find out if they support AMP email

AMP emails are designed to be compatible in the current email ecosystem with the introduction of a new MIME part. This design allows emails to fall back to HTML if a provider or email client doesn’t support AMP emails yet—learn more about the spec and recommended guidelines.

New AMP email working group

To make AMP the best user-friendly email experience, we need your help to contribute to its direction. This is why we created the AMP for email working group under AMP’s governance model, a way to channel feedback from senders and providers to support ongoing spec improvements.

The two goals of this group are to:

  1. Increase email provider knowledge sharing to promote higher cross-provider compatibility of sender emails
  2. Channel community feedback to senders and providers to support ongoing innovation of the spec

If you are an email provider, sender or would simply like to get involved in the AMP for Email working group, you can file discussion issues on the ampproject/wg-amp4email repository or come chat with us at #wg-amp4email on Slack.

With the email spec being open source, strong multi-vendor support, a gradual migration strategy, and an open working group to have everyone’s voice heard, we’re looking forward to building a better email experience for everyone.

We look forward to your involvement!

Posted by Vamsee Jasti, Product Manager, AMP Project


Encouraging More Voices in AMP

Governance

Last year we implemented changes in AMP’s governance model to encourage a wider variety of voices in the AMP community and to make it more clear how people can have a voice.  I’m happy to provide some updates on our progress towards these goals.

AMP’s Technical Steering Committee and Advisory Committee have started meeting

As part of AMP’s new governance model the Technical Steering Committee (TSC) sets AMP’s product and technical direction and the Advisory Committee (AC) provides advice to the TSC.  With these two groups we have representatives from nearly 20 companies & open web advocates helping to guide the AMP community towards our vision of “a strong, user-first open web forever.”

The TSC has now had several meetings, covering a range of topics from GitHub repository best practices to what AMP’s first set of Working Groups should be.  The AC also had their first meeting where they kicked off a conversation regarding horizontal reviews, a topic on which the TSC has asked for input.

If you have something you’d like to raise with one of these committees, you’ll find out how to do this in their “working mode” documents (TSCAC).

Working Groups are ready for you to get involved

One of the TSC’s first acts was to establish the initial set of AMP Working Groups (WGs).

Working Groups are where the day-to-day work in AMP gets done.  A Working Group is responsible for a certain part of AMP, such as the Stories WG, which is responsible for AMP’s story format.

The Working Groups are intended to make it easier for people to keep track of different parts of AMP and to get involved.  To help with this, each Working Group has a GitHub repository that documents how to get updates on the Working Group’s work and how to get involved–from participating in discussions on issues and Slack to contributing bug fixes, features or other improvements.

I encourage you to find the Working Groups responsible for the areas you’re passionate about and to get involved!

We’ve made our process for making changes to AMP more clear

Although we’ve always said we strongly encourage contributions to AMP, we’ve heard it can be challenging to figure out the process for proposing and making changes and even to know where to get help.

Due to this feedback we’ve been working to improve and clarify the process for making changes in AMP, inspired by Chromium’s process for launching features.

Some of the highlights of these updates:

  • We’ve made it more clear that small changes are easy to make without a lot of process overhead.
  • We’ve added a slightly more formal launch process for significant changes, including the use of Intent-to-implement (I2I) and Intent-to-ship (I2S) issues and a more well-defined way of getting approval for making significant changes.
  • We’ve made it easier to find a reviewer who can help you through the process of getting your change built and launched.

With AMP’s new governance model and contribution process updates in place we hope it’s easier than ever for you to stay up-to-date on what’s happening in AMP and to get involved! 

Posted by Joey Rozier, AMP Engineering Manager at Google

What’s new in AMP, Q1 2019: Improvements to consent, videos, forms and lists

Roadmap

Video improvements

We have all experienced a situation where we want to watch a video and the related notes simultaneously. Good examples are a video of a recipe along with the instructions, or a video along with its transcript. The dock attribute on <amp-video> now supports minimizing the video to the corner of the viewport when the user scrolls. Developers can also customize where and how the video docks.

We also launched <amp-video-iframe>, which allows developers to include a custom-built video player that will obtain all the features available in the AMP Video Interface (e.g. autoplay, dock, etc.)

Tasty.co uses <amp-video-iframe> for their video recipes. Their custom player loops the video between a predefined start and end time. This allows them to use one video for different recipes by only seeking to the relevant segment of the video in each recipe.

Increased engagement and better resize with <amp-list>

<amp-list> now also allows developers to specify when they want the container to resize on user interaction, for e.g, when the <amp-list> contains an <amp-accordion> that a user taps on.

Additionally, we are experimentally adding infinite scroll capabilities to the component, so when the user reaches the end of a list of items (search results, product cards, etc), the list is populated with more items. A huge shout out to Chris Papazian from the Pinterest team for kicking this off. The AMP UI Working Group picked this up from Chris’ initial work and is excited to see this feature enabled in AMP to help publishers’ increase engagement!

Input masking in forms

To help make the task of filling in forms a bit easier, we’ve enabled input masking. This allows developers to add formatting like spaces and interstitial characters, which helps users fill out forms more efficiently. Dates, payment details and phone numbers are all great examples of inputs that could benefit from input masking.

Better transitions in <amp-lightbox-gallery>

The AMP UI Working Group has also been working on polishing already launched components to create a more delightful experience for end users. One such example is improved transitions for all images going to and from lightbox mode. This has been a hard problem to solve, as it involves interpolating between two images of different positions and sizes. You can visit our open source animations project for more details. Stay tuned for a technical blogpost that shares more insights into this work.

<amp-consent> now supports 3rd party integrations

We launched <amp-consent> in AMP a few months ago to simplify how publishers could collect data collection user consent on AMP pages. A number of publishers rely on 3rd party consent management platforms (CMP) to integrate with their web pages to manage consent status across various vendors. AMP now allows CMPs to easily integrate with AMP. If you are a publisher, you can also inline the configuration allowing you to show your own consent UI inside AMP. If you are a CMP, you can find instructions to integrate here.

Enhancements to <amp-ima-video>

The <amp-ima-video> component provides an easy to monetize publisher video with video ads from any video ad network that supports the IMA SDK. Our big thanks to Rebecca Close, an engineer working at Buzzfeed, who contributed and tested the following updates to the AMP project:

The best of the rest

  • The <amp-date-display> component renders date information in various date formats and in different locales. A good use case for this is the news ecosystem, where users can see publishing dates for an article in their local time.
  • AMP Stories now support Real Time Config when used with the Google Ad Manager ad implementation, allowing you to enhance the ad request with additional targeting information.

Upcoming features worth a shout

Below are a few things the AMP team has been working on:

  • A dedicated component for typeahead autocomplete in AMP. If you have any thoughts please file feedback here.
  • A new carousel experience that we are looking to launch soon over the upcoming months.
  • An easy-to-deploy Service Worker library for AMP. You can learn more about it over in its GitHub repo.
  • A component that helps developers integrate reCaptcha v3 on AMP documents. For more details, see the GitHub issue.
  • We have made a number of updates to AMP Stories including support for links in the top 80%, a hamburger menu, hold to pause, a new desktop UI, and attachments. Stay tuned for a full post with updates soon.

* * *

Thanks to the AMP development community for your work and feedback. As always, please let us know if you have any issues or feature requests.

Posted by Naina Raisinghani, Product Manager, AMP Project at Google

Using AMP to make display ads safer, faster and better for users

Ads

Editor’s note: The following post was originally published on the Google Ads Blog by Vamsee Jasti, AMP Product Manager at Google.

The performance benefits and security guarantees offered by AMPHTML ads, which are display ads created using the AMP framework, translate to better advertiser ROI, publisher revenue and overall better user experience. Because of this, Google has expanded serving AMPHTML ads not only to AMP pages, but also to regular web pages. As of January this year, 12% of all display ads served by Google are now AMPHTML ads.

All of the code in the AMP repository is open source which is carefully reviewed by the project maintainers before being merged. As a result, ads written in AMP start performant and stay performant. Such a process also drastically reduces the likelihood of AMPHTML ads having code that takes advantage of chipset level vulnerabilities or drain CPU by crypto-mining from users’ devices. 

Since AMPHTML ads can be trusted, they can be rendered into a more performant same-origin iframe. This performance boost results in the ad rendering faster on page which translates to higher publisher revenue and better advertiser ROI.

Experiment results from GPT.js rendering AMPHTML ads in a same-origin vs cross-origin iframe

AMPHTML ads on AMP pages deliver even better ROI

An AMPHTML ad delivered to an AMP page has better performance compared to the same ad running on a regular web page. This is due to the inherent design of AMPHTML ads outlined here, giving advertisers better click through rates and viewability.

AMP pages have seen steady growth over the past few years and advertisers now have access to well over 1 billion impressions/day worth of premium (from a user experience & ad experience standpoint) inventory. In addition, more than 35 percent of ads served to AMP pages are already AMPHTML ads.

Publishers and Advertisers seeing success with AMP pages and AMPHTML ads

The news publisher EL PAIS partnered with Volkswagen, one of their advertisers, to run a multivariate A/B test measuring how Volkswagen’s display ads created in AMPHTML vs HTML5 would perform on AMP vs regular pages.

Simply moving from a standard HTML page to an AMP page (with the same HTML5 ad) resulted in a 26 percent CTR increase. Moving further to an AMP page with AMPHTML ads resulted in an additional 48 percent CTR increase.

Increase in performance metrics when combining AMP pages with AMPHTML ads

You can read the full case study here.

Getting started with AMPHTML ads for advertisers

AMPHTML ads are a subset of the AMP spec and ships with many good-by-default ads UI components, an analytics measurement framework, a spam detection system, viewability measurement and other building blocks to create a good and measurable ad.

We encourage you to read more about the benefits of using AMPHTML ads, but if you want to jump ahead to start creating them, this is a good place to begin.

Once you have created the ad, you can choose one of the following options to serve AMPHTML ads: 

  1. Work with an Authorized Buyer that allows to target just AMP or regular inventory 
  2. Use Google Ads to target inventory in the Google Display Network
  3. Direct buy with publishers using Google Ad Manager
  4. [Coming Soon] Display & Video 360 support to deliver AMPHTML ads to AMP pages

Google continues to invest in delivering better user ad experiences by increasing the share of AMPHTML ads vs regular ads. Once mobile app support launches in Q2, 2019, advertisers can fully transition to creating a single AMPHTML ad and have it render across all environments and devices.

We hope you’ll take full advantage of the performance, security benefits and the increased ROI by choosing to build & serve AMPHTML ads in your next campaign.

Posted by Vamsee Jasti, AMP Product Manager at Google

Volkswagen and EL PAÍS increase conversions by 76% with the first end-to-end AMP campaign

Ads

Volkswagen, one of the world’s largest automotive companies, sought to improve the user experience of potential customers for their 2019 Tiguan TDI 150 R Line. Given their business goals and desire to test the state-of-the-art in speed and performance, they decided to test AMP technology for both their landing page, and the ad  creatives that would drive users there. 

EL PAÍS, a company within the Prisa Group, is the world’s leading Spanish-language news medium, in its digital format. It has 64.7 million unique users per month worldwide. Digital transformation is key to Prisa’s business, and they maintain a position at the forefront of digital innovation.

EL PAÍS was an early adopter of AMP technology, launching their first AMP version of EL PAÍS in 2015. They have been using this technology since then, to serve fast high-quality content to their large audience on mobile. Similarly, EL PAÍS was one of the first adopters globally of AMPHTML ads (ad creatives built with AMP).

Objective

Many news and entertainment publishers already use AMP to deliver beautiful, fast pages to end users across devices. However, the creatives that serve to these pages are typically built with standard HTML, which tend to result in degraded performance and therefore lower ROI for advertisers.

Volkswagen and EL PAÍS, together with the creative agency DDB, media agency PHD, and with the support of Google, have conducted a test to evaluate the benefits of AMPHTML ads.

The Test

EL PAÍS conducted the experiment by configuring four different line items in their ad server, featuring a 2×2 combination of environment (AMP vs. non-AMP) and creative type (AMPHTML vs. HTML). This allowed them to compare the performance characteristics of the AMPHTML creative and its original HTML equivalent, both in an AMP environment and within traditional mobile Web. Additionally, they tested two flavors of landing pages (HTML and AMP), allowing for a full comparison of results throughout the conversion funnel.

Results

After collecting data from more than 2M impressions on mobile devices, AMP technology has shown strong performance increases relative to standard HTML:

  • AMP pages and ads versus standard HTML pages and ads
    • +87% CTR
    • +36% viewability rate
    • +81% visits to landing page
  • AMP Landing Page relative to standard HTML Landing Page
    • +76% conversion rate
    • -43% cost per acquisition

Simply moving from a standard HTML page to an AMP page (with the same standard HTML ad) resulted in a 26% CTR increase. Moving further to an AMP page with an AMPHTML ad resulted in an additional 48% CTR increase.

The AMP page also add an extra +76% Cvr versus the standard HTML page.

Conclusions

Prisa’s test demonstrated that AMP’s superior performance characteristics can deliver meaningful ROI benefits to advertisers. Improved viewability and conversion rates result in lower user acquisition costs, and the benefit is multiplied when AMP pages and AMPHTML ads are deployed together. And not only does AMP provide positive ROI for publishers and advertisers, it does it while improving the end user experience, yielding a more sustainable web for everyone. 

Posted by Pilar Sanchez, Mobile Specialist, Google

AMP Conf 2019 が東京で開催されます

AMP Conf

この記事は AMP プロジェクト マーケティング リード、Matt Ludwig による Accelerated Mobile Pages Project の記事 “Announcing AMP Conf 2019: Tokyo” を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

昨年 2 月アムステルダムにて AMP というオープンソースプロジェクトの最新情報や学びを共有すべく AMP Conf 2018 が開催され、400 名もの方々が集まりました。この AMP というフレームワークはそれ以降も進化のスピードを止めることはなく、新たなガバナンスモデルを導入し、多くのパブリッシャーや E コマースのウェブサイトに採用され続けています。その中でも注目すべきははアジア・パシフィックでの普及です。たとえば最近の事例では、インドのパブリッシャーである Times of India やオーストラリアの自動車保険の Greenslips.co.au そして日本の CMS の EC-CUBE など、この地域での盛り上がりには目を見張るものがあります。

AMP Conf 2019 はついに東京へ!

このような盛り上がりを受けて、2019 年の AMP Conf は 4 月 17 日、18 日に東京で開催することが決定されました。AMP のコアデベロッパーやコントリビューター、AMP を利用してサイト制作をしているエンジニアやデザイナー、そして新たなガバナンスモデルを形成しているコミッティーのメンバーと一緒に、AMP の最新情報や事例を見ていきましょう。コアな AMPHTML のトピックだけでなく、AMP stories、AMP for email、AMPHTML ads などの新しいフォーマットに関するアップデートも予定されています。またすべての方に楽しんでいただけるよう、コンテンツは英語だけでなく日本語でも聞けるように通訳される予定です。

そして今年も多くの方からの声や意見を反映するため、セッションの一般募集が行われています。皆さんが取り組まれた AMP の面白い使い方や、本番環境で利用するにあたっての苦労話、開発プロセスにおける工夫や、ウェブ エコシステムの中での AMP の捉え方など、さまざまな話題をご応募ください。

AMP Conf に参加するにはこちらのフォームからお申込みください。また、数に限りはありますが、一部の支援が必要なコミュニティなどを対象とした旅費の援助も検討されていますので、ご希望の方は登録時にお申込みください。もし東京に来れない場合は、ライブストリーミングやセッション動画の公開も行われますので、AMP YouTube チャンネルに登録してください。

開催日が近づくにつれ、より詳細なトーク コンテンツが更新される予定ですので、ぜひともご確認ください。もうすぐ(あと100日以内で 😲)皆さまとお会いできることを楽しみにしています。

Reviewed by Yusuke Utsunomiya – Mobile Solutions Consultant, Google

A year of open source funding

Uncategorized

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.

Total funding: $32,900

The projects we supported are

ProjectsTotal contributionDescription
Babel$12,600The most used transpilation system for JavaScript. Used in AMP’s development pipeline to support modern JS syntax in older browsers.
Preact$12,000Super tiny React alternative. Used in AMP’s upcoming component model rework.
webpack$6,000The most popular build tool for web applications and core to our amp-script strategy.
document-register-element$1,200Document-register-element is the custom element we are using to drive AMP.
Rollup$1,100Rollup is a super efficient bundler for JavaScript modules.

We’re super glad we’ve been able to support these amazing projects and are looking forward to do even more in 2019!

Posted by Malte Ubl, Member of the AMP Project Technical Steering Committee