AMP

How Goibibo Got Started With AMP For Email – And How You Can Too

Email

Editor’s Note: the following article was originally posted on Medium by Varun Kumar, Full Stack Developer, Goibibo

Email is still the preferred method of communication for marketing campaigns, transaction alerts, handling customer grievances, mass communication, etc. According to The Radicati Group Inc., the number of worldwide email users will increase to over 2.9 billion by the end of 2019. Over one-third of the worldwide population will be using email by the end of 2019. But can it be even more powerful? Can we make email more engaging and interactive as if someone is browsing a website? Can we serve real time dynamic data no matter when an email is opened? Can we collect information from within the email itself without leaving our Inbox?

Yes, yes. With the AMP Project introducing AMP for Email, all these things are now possible.

What is AMP for Email aka dynamic email?

It is a new technology introduced by the AMP Project in 2018 which lets you use a subset of AMP components in your email to make it more engaging. It is part of AMP Project (open source project to provide a user-first format for web content, supporting the long-term success of every web publisher, merchant, and advertiser) and it offers Javascript-like functionality for email. 

Wait, I have heard about AMP

You must have. But AMP for Email is different from AMP for HTML, though both are open sourced and part of AMP project. AMP for Email has a few more rules than AMP for HTML in order to ensure a smooth email experience for users; for example, file upload using <input type=”file” /> is not supported (as of now) in AMP for Email but it’s there in AMP for HTML.

Okay, but how is it going to work?

Email consists of MIME (Multipurpose Internet Mail Extension) parts such as text/plain for plain text email and text/html for an HTML email. To make the email clients recognize the AMP for Email, a new MIME type text/x-amp-html was introduced. This MIME part will contain AMPHTML markup.

Most email sending libraries and services already started support for this new MIME type e.g. Nodemailer (a library to send emails in node.js) put support in v6.1.0.

Hmm, interesting. Show me AMP for Email in action

Yes, of course. Here is one demo in which an imaginary company “Beautiful Flowers Shop” is asking its customers to provide feedback for different flowers offered by company.

Awesome! I want to learn AMP for Email too. Tell me everything.

To develop a dynamic email, you will need the following four things:

1. A valid AMP for Email markup. This would be your email template which would be rendered in Email. You can validate your markup here at https://amp.gmail.dev/playground/. A sample hello-world markup would be something like:

<!doctype html>
<html 4email>
<head>
 <meta charset="utf-8">
 <script async src="https://cdn.ampproject.org/v0.js"></script>
 <style amp4email-boilerplate>body{visibility:hidden}</style>
</head>
<body>
 Hello, AMP4EMAIL world.
</body>
</html>

2. An email library which supports text/x-amp-html MIME part in email body. You can use Nodemailer in node.js. An example snippet can be found here. If your dynamic email is going to contain API calls then you will have to meet CORS requirements

Official documentation :

Gmail https://developers.google.com/gmail/ampemail/security-requirements

Mail.ru https://postmaster.mail.ru/amp

Outlook https://docs.microsoft.com/en-gb/outlook/amphtml/

res.set({
'Access-Control-Allow-Origin': origin,
'AMP-Access-Control-Allow-Source-Origin': sourceOrigin,
'Access-Control-Allow-Source-Origin':
'AMP-Access-Control-Allow-Source-Origin',
'Access-Control-Expose-Headers':
'Access-Control-Allow-Origin' +
', AMP-Access-Control-Allow-Source-Origin' +
', Access-Control-Allow-Source-Origin'
});

3. Testing dynamic email in Gmail. Gmail won’t allow dynamic emails to be rendered (it would be rendering html instead) unless your email address is officially whitelisted by the Google team (step 4). But to test your email on some particular Gmail account, you can use the dynamic email developer setting to whitelist from address. https://developers.google.com/gmail/ampemail/testing-dynamic-email

4. Whitelisting your email (sender address) by Gmail so that your dynamic email is rendered to end users. Once you are ready with your production email, you will have to send it to ampforemail.whitelisting@gmail.com for whitelisting along with filling the registration form. A complete guide can be found here.

Note that Gmail doesn’t whitelist per domain, the whitelist works per email sender (e.g. if sender@example.com is whitelisted, it doesn’t apply to all @example.com addresses).

The last two steps are Gmail specific. If you are using Microsoft Outlook, equivalent steps will have to be performed there as well. You can refer to Outlook’s official documentation. Information about AMP for Email on mail.ru can be found here.

I am overwhelmed by so much information

That’s okay! Take your time. When we at Goibibo started this Proof Of Concept, it took us only 2 days to develop a dynamic email and test it in our personal Gmail accounts, but it took us 2+ weeks to make our email use case production-ready and get it whitelisted by Google so that we could send it to our end users. We wanted to send our hotel partners a dynamic email to collect feedback about Extranet (hotelier’s platform for managing rates & inventory) and this is what we came up with:

We specifically used AMP for Email to allow hoteliers to “Reply to Reviews” from their checked-out guests. For example, after a customer stays at the hotel, checks out, and leaves a review, the hotelier has the ability to respond to the review within their email.

Earlier we tried this using a hyperlink to Hotelier’s platform called Extranet, and this used to have a B2B email open rate of 14% to collect replies to reviews from the Hoteliers (B2B). During Proof Of Concept, which we ran on 2 different occasions, we got an amazing response with path-breaking email open rates.  

Conclusion

AMP for Email is really promising and we at Goibibo are going to use it moving forward in our email campaigns. There are some initial challenges like setting up infrastructure for handling AMP API requests and training our email-design and marketing teams, but the end results are going to be really awesome.

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

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