Delivering Episode 12: Is it time to embrace AMP for Email?

In this episode of Delivering, host Jason Rodriguez looks back at (nearly) two years of AMP for Email, its implications for the industry, and tries to answer the question of whether or not email marketers should embrace Gmail’s most recent innovation.

Episode Transcript

Welcome to Delivering, a podcast about email design, strategy, copywriting, development, and the email marketing industry. I’m your host, Jason Rodriguez. Delivering is brought to you by Litmus—the only platform trusted by professionals to help you send email with confidence, every time. Over 600,000 marketing professionals use Litmus’ tools to build, test, and analyze better email campaigns faster.

Head over to litmus.com to start your free 7-day trial of Litmus, and start sending better emails today.

Be sure to subscribe to Delivering on iTunes or Spotify to listen to future episodes and join the conversation on Twitter using the hashtag #DeliveringPodcast.

—

In February of last year, the Gmail team announced a new initiative called AMP for Email. In the original blog post, Google called it an “opportunity to modernize one of the most popular places where people spend their time” as well as “a powerful way for developers to create more engaging, interactive, and actionable email experiences” for the over 270 billion emails sent every day. Although the announcement linked out to some introductory documentation, the post was light on details other than the fact that companies like Pinterest and Booking.com were using AMP for creating those more interactive experiences.

Despite limited information and a fuzzy timeline around AMP for Email rolling out “later this year”, the email industry was immediately dominated by blog posts and Twitter discussions about the latest feature from the Gmail team.

Opinions were mixed.

Some email marketers hailed the announcement as an amazing step forward for the industry. Others looked at the implementation, the very public criticisms of Google’s overarching AMP project, and Google’s history with Gmail features and killing off products without much warning, and bemoaned the announcement as a step in the wrong direction.

I’ll admit that I fell firmly into the latter camp. In a blog post on my personal site published a few days after the Google announcement, I said:

Logistically, I just don’t see Google getting the adoption it needs to make AMP for Email work across ESPs and other email clients. I absolutely think the Gmail team should be working to bring interactive and dynamic emails to their users, but they should do it in the context of improving support for proper HTML, CSS, and JavaScript (if they can wing it).

A lot has changed in the nearly two years since the original AMP for Email announcement. I wanted to use this episode of Delivering to readdress AMP, its implications for email marketers, developers, and subscribers, and try to answer the question, “Is it time to embrace AMP for Email?”

I guess the first thing we should start with is a definition. What is AMP for Email?

At its most fundamental level, AMP for Email is a new markup specification that can be added on top of traditional HTML emails to provide extra functionality in the inbox.

Ever get an email notification when someone commented on your Google Doc? Notice how you can now comment back directly in Gmail, providing feedback without ever leaving your inbox? That’s AMP for Email in action.

AMP allows you to add interactivity in the inbox, from basic image carousels to ratings, dynamically updated content, and even advanced calls back to your own server. All of this happens using AMP markup that looks like HTML but is a new specification. That code is written in a separate email file, delivered using an additional MIME type (on top of the existing HTML and text types already sent with a marketing email), and requires a bit of additional tooling to test and send.

While there haven’t been too many AMP-powered emails seen out in the wild yet, companies like Pinterest, Booking.com, and Indeed have been doing some cool things with AMP. Folks from all three have even spoken at our own conference, Litmus Live, the past two years, sharing their experiences with AMP.

Pinterest has created some cool emails where people can browse, save, and organize pins directly in a campaign. Booking can now show and update trip deals and details in realtime. And Janie Clarke and Rohan Kapoor from Indeed showed off a lot of the work they’ve been doing at Litmus Live Boston this year, including an email where job hunters can view details and start the application process in the inbox.

Hopefully that description makes answering the next question, “Why would you want to use AMP?”, easy. AMP lets you do things in email that were previously either impossible or very hard to implement. Although email interactivity has been around for years powered by HTML and CSS, AMP effectively takes things to the next level.

Folks like Mark Robbins and the team at Rebel—which was recently acquired by Salesforce—have spent a lot of time adding advanced interactivity to email campaigns. What started with simple image carousels eventually evolved into things like dynamic Twitter feeds and full-blown surveys and checkout experiences in an email. All of that was largely powered by what’s called “the checkbox hack”. Email developers took advantage of the way HTML checkboxes worked to track state in an email and conditionally show and hide content based on what subscribers were doing in the email. Combined with passing information via URL parameters, dynamically updated content using CSS and some server-side scripting, email devs had a fair amount of power at their disposal.

But creating those emails required a specialized skillset, ample testing, and the understanding that interactivity didn’t work across all email clients. For a lot of teams, interactivity was out of reach.

The promise of AMP is that advanced interactivity and functionality is now accessible to anyone with a relatively simple, lightweight markup language that should be easy to get started with for anyone that’s familiar with HTML. With a few lines of code, email marketers can now include accordions, animations, carousels, lightboxes, surveys, feeds, polls, ratings, and more in any email campaign, with the default HTML and CSS version as a fallback.

AMP promises enhanced functionality and, with it, increased engagement from subscribers. For email marketers desperate to take advantage of the 11 seconds most subscribers spend in an email, AMP looks like an amazing tool.

With promises like that, why wouldn’t you want to use AMP for Email?

For me, the criticisms break down into two categories: implementation and fragmentation.

From an implementation perspective, AMP for Email isn’t quite there yet. As I mentioned before, the code that powers an AMP-based email lives inside a separate file that requires a third MIME type to be delivered alongside your HTML and plain text emails. As of right now, only a few email service providers actually support sending that third MIME type. While that list can be expected to grow in the coming years, for many, lack of support is a non-starter.

Even if your ESP does support the AMP MIME type, you’re not out of the woods yet. Using AMP for Email requires a few additional technical settings, including a Google-specific header to be delivered with your message, and strict security settings for senders, like the use of DKIM, DMARC, SPF, and TLS encryption when sending AMP messages. Unfortunately, none of this is well-documented on the AMP site, leaving a lot of email marketers confused when testing out messages.

The AMP code itself also requires strict validation, falling back to the HTML version if you leave out necessary markup. Whereas HTML and CSS make an effort to render what they can, AMP effectively shuts down in the face of errors. Fortunately, the AMP team has released a solid online playground and validator building and testing AMP-powered campaigns.

When it comes to email clients actually displaying AMP-powered emails, support is likewise limited. As of right now, AMP is only supported in Chrome and Firefox for desktop and, as of a few days ago, on the Gmail mobile apps on iOS and Android. Outside of the Gmail ecosystem, AMP is in beta and slowly rolling out to users of Yahoo! Mail and Outlook.com, as well as Mail.ru.
For everyone else, AMP-powered emails probably won’t be happening anytime soon.

Although Gmail is the second most popular email client according to our research, and Yahoo! Mail and Outlook.com are both in the top ten most popular email clients, there are still millions upon millions of users using alternatives. For those folks, the likelihood of AMP coming to them is slim, especially for the masses using legacy email clients like older versions of Outlook that usually only get security updates, not new features.

On a philosophical level, AMP introduces even more fragmentation to an already massively fragmented ecosystem. There are dozens, if not hundreds, of email clients and ESPs in popular use—all of which adhere to their own rules when rendering the code that powers emails.

Not only is there a complete lack of standards with HTML and CSS in email, but email marketers’ skill with those two languages varies wildly. While some teams are comfortable writing lean, accessible, and interactive HTML and CSS, others are still using templates and techniques that haven’t been updated in the last decade.

Introducing a third flavor of markup, one that is largely controlled by one company and likely to change in the future, is problematic. Wouldn’t Google’s massive resources be better put to use improving support for HTML and CSS—standardized languages on the web—across email clients? Why introduce yet another standard for people to implement when we can already accomplish so much with the existing standards? Why not embrace interactivity with HTML and CSS like Salesforce has recently done by introducing interactive content blocks in Salesforce Marketing Cloud that are powered by HTML and CSS instead of AMP?

That leads us to one final criticism of AMP for Email. The answer to those questions is control. Although AMP is an open source project, it is, for all intents and purposes, completely controlled by Google. As we’ve seen with AMP for the web, Google has used AMP as a way to drive advertiser spending. AMP-powered websites are given priority in Google search results, and there is even an amp-ad component that makes it easy for companies to leverage Google Ads. Who’s to say that, someday soon, AMP-powered emails are given preference in the Gmail inbox over every other campaign? That lock-in, while good for Google, is dangerous for other email clients, senders, and subscribers.

This all leads us back to the main question proposed at the beginning of this episode: Is it time to embrace AMP for Email?

Before mucking about with AMP, there are important questions to ask yourself and your team.

Can you actually send an AMP-based email? Is your audience Gmail-heavy? Do you have the time and resources to learn a new markup language and test new campaigns? Do you have an actual use case for AMP in your email program or are you just chasing the latest fad?

Any time a new feature or technique rolls out in the email industry, I’m reminded of a Twitter thread from email luminary Fabio Carneiro. In the face of the criticisms I leveraged above, I think it’s worth reading in its entirety. Here’s what Fabio had to say all the way back in 2015:

The idea that email clients will modernize if email developers simply stop coding for them is, frankly, irresponsible and idiotic.

It’s an idea that puts your average recipient in the crossfire between email client providers and email developers, which is silly.

We don’t make people suffer just because we’d like for things to be better; users aren’t currency, and they deserve better treatment.

We code to provide the best experience we can given the environment we have. Improving that environment shouldn’t come at the cost of UX.

If email developers have to yell at client providers until they’re blue in the face just for the hope that things will change, well…

That’s part of the gig. Strap in for the long fight.

The criticisms I have of AMP for Email run afoul of Fabio’s point. While I don’t particularly agree with Google’s method of adding interactivity to email, I do see the benefit to consumers and subscribers who are increasingly expecting more from email. For better or worse, Google is an absolutely massive company and Gmail is an equally massive player in the industry. People use Gmail. They see these features as they roll out. They get used to using AMP—even if they don’t know what it is—when they reply to comments on a Google Doc right from the inbox. They expect their tools to work how they want.

As a developer, I wish Google would embrace standards like HTML and CSS, both of which can already be delivered through any ESP in existence without additional setup on our end.

As a consumer, I really love the idea of AMP and using it for things like Google Docs comments. Like so many others, I’m firmly entrenched in Google’s world, and the sheer convenience provided by Gmail and GSuite is hard to live without—despite my increasing anxiety over surveillance capitalism and reliance on one single company for so much.

So, going back to our original question around whether or not email marketers should embrace AMP. The answer is: Yeah, probably. If you can.

There are challenges, sure. There are ethical concerns, of course. But at the end of the day, we’re working for our subscribers, not ourselves. If there is a valid and compelling use case for AMP, then we should look into whether or not we have the infrastructure and resources to start sending AMP emails. And, as AMP rolls out to more platforms, more and more subscribers are going to be expecting richer experiences that help them get what they need to do done, with as little friction as possible.

Back when AMP was announced, I wrote, “I just don’t see Google getting the adoption it needs to make AMP for Email work across ESPs and other email clients.” I was hardly alone. Most of us saw a future where AMP went the way of Grid View or Inbox by Gmail. There was no future where AMP actually got off the ground and existed in the wild.

But it’s there. It’s coming, and Google is bringing everyone along for the ride—ESPs, email clients, and subscribers alike.

AMP for Email may not be the best solution for enriching the inbox, but it’s no longer a solution we can ignore. I’m excited—if a little tentative—to see how it changes the email marketing landscape and subscribers’ expectations of what can be done in the inbox.

—

Delivering is brought to you by Litmus.

Litmus is the only platform that helps you send email with confidence, every time. Over 600,000 marketing professionals use Litmus’ tools to build, test, and analyze better email campaigns faster.

Head over to litmus.com to start your free 7-day trial of Litmus, and start sending better emails today.

Be sure to subscribe to Delivering on iTunes or Spotify to listen to future episodes and join the conversation on Twitter using the hashtag #DeliveringPodcast.

The post Delivering Episode 12: Is it time to embrace AMP for Email? appeared first on Litmus Software, Inc..

from Litmus Software, Inc. https://ift.tt/2P100iG
via IFTTT