On AMP for Email

February 16, 2018

I’m an email guy. I’ve written three books on email, spoken at a bunch of conferences on the topic, and help build tools for other email folks at my day job. I love seeing the email platform grow and evolve. I love seeing people working on interesting ideas that make email more valuable for the subscribers that receive them.

So, you’d think I’d be thrilled by Google’s announcement about adding dynamic content and interactivity to Gmail with AMP for Email. You’d be wrong.

Although I do love the idea of making emails more interactive and (in theory) more valuable to subscribers, I have severe reservations about Google’s approach to doing so and their ability to make it happen.

AMP for Email is an offshoot of the Accelerated Mobile Pages (AMP)project, which “is an open-source initiative aiming to make the web better for all”. It’s goal is to allow publishers to create better performing pages for mobile audiences. Less bloat, faster load times, happier users.

While the stated goals of AMP are noble, there has been a massive backlash from the developer and publisher communities against how AMP for the web has been implemented. From concerns about a Google monopoly to accounts of even more bloated pages, the response from the web community has been full-throated and harsh.

As an email geek, I’m liable to disagree with a lot talk in the web world but not in this case. I think AMP for Email is a bad idea. An interesting idea with some cool demos, sure, but poorly executed by Google.

Here’s why:

• Although it’s touted as open-source, Amp is fundamentally controlled by Google. They set the agenda and everyone else falls in line.
• That agenda benefits Google first and the web and email next (if at all). If it was just about building faster mobile pages, there wouldn’t be amp-ad. Granted, AMP for Email doesn’t have an ad component (yet), but who wants to bet against me that it will eventually? Anyone?
• Amp goes against web standards. It’s essentially creating a fourth, proprietary language beyond HTML, CSS, and JavaScript.
• Amp for Email uses that language instead of HTML and CSS. We have enough problems with basic HTML and CSS in email clients, now we need to worry about yet another markup language?
• People are already creating rich, interactive experiences in email using tools already available to everyone. Why not put your collective might behind improving that strategy instead of creating another one? Answer: Google wants to create and own its own version of the web and, now, email, too.
• From a practical standpoint, AMP for Email requires the use of an additional MIME type beyond the standard HTML and plain text ones.
• No ESPs support that MIME type and I don’t expect any to add support in the near future, making AMP for Email a non-starter for nearly everyone.
• Gmail is the only client that will be supporting AMP for Email off-the-bat. And we’re not even sure which version of Gmail will get that support. Even though it’s an open spec, so any email client provider could implement it, do you think anyone will anytime soon? I don’t.

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).

Philosophically, I’m completely against Google’s AMP project and AMP for Email, too. I will always side with the open web and the standards that power it, and AMP is actively working against both. I’m all-in on a faster web for everyone, but I just can’t get behind Google’s self-serving method for providing that faster web.

What do you think? Email me or join the conversation over on the Litmus Community.

---

Permalink: https://rodriguezcommaj.com/blog/on-amp-for-email