When Google shared their vision for a new paradigm for email, they chose to ride on their ambition of AMP, the Accelerated Mobile Pages Project. Google’s “modern” email project would offer native support for dynamic and interactive elements. Overall, the email ecosystem would see more engagement and provide more value to the subscriber.
Aakash Sahney, Gmail Product Manager, revealed the plan to turbo-charge email using the AMP engine. The Gmail Developer Preview of AMP for Email is supposed to be a new way for developers to improve interactivity and engagement in emails. Mr. Sahney presents AMP for Email as the panacea for adding dynamism, recency, and a more actionable side to good ol’ email.
It’s been a few bumpy years since Aakash’s announcement. Isn’t it perhaps the right time to consider the milestones around the technology. As expected of any tech with any hint of complexity, there are arguments for and against AMP for Email. There’s also a plethora of opinions in-between. Let’s go over some of the expert narratives around AMP for Email.
Eight Things That Make AMP for Email Not Tick
#1 – AMP for Email: Perhaps a Little too Early for Its Time
Fresh Inbox’s Justin Khoo acknowledges Google’s noble goal to make mobile web pages load faster regardless of bandwidth and processor power. Eliminating JavaScript is a pillar feature in implementing AMP.
Think of it, have you received any emails where you can swipe through product images, make purchases, or complete surveys from your inbox? Despite the trade-offs, there’s only been a slow march towards mainstream adoption of AMP. Modern non-Google email clients seem to be actively looking the other way, even if that way leads to oblivion.
It’s unprecedented that an open-source initiative as promising as AMP for Email is still only available as a Developer Preview (not for every developer) on Gmail webmail.
#2 – A MIME Part We Still Don’t Know
This feature might easily be AMP for Email’s biggest headache: that all content come in its not-so-shiny text-x-amphtml MIME part.
Email Service Providers (ESPs) such as Mailchimp and Salesforce Marketing Cloud understand the challenge of offering support for this MIME part. It’s not too long ago that they found a stable way to support responsive email solutions. It’s probably realistic to expect them a few years to figure out the AMP question.
The API-based ESPs might use this as an additional edge over the long term.
It’s not a simple matter of swapping out one MIME type for another. An email should have two MIME types: one for the plain text and another for the HTML part. AMP emails introduce a requirement for a third MIME type to support AMP email deployment. Now you see why only the tech-savvy ESPs may be eager to play.
#3 – Here’s a New Language, Devs
Traditional HTML is the language of email. AMP only supports basic HTML. Why should this matter? Well, it turns out that a developer needs to have a firm understanding of JavaScript-like syntax that’s still not JavaScript. That’s the only way they can take advantage of the interactive features of AMP for Email.
HTML and CSS, as you know them, do not suffice for AMP, and only a small number of these developers will embrace AMP to an appreciable degree.
#4 – AMP is Not Email Development as Usual
AMP for Email should build upon current email development practices. But, it appears to be tearing everything down. There’s no support for the img tag, the !important selector, inline styles, and background attributes. These are the essential components of HTML email development.
AMP’s radical deviation offers an obscure amp-img tag that features a unique array of restrictions, such as requiring height and width attributes.
We have to mention the perplexing fact that while there’s zero support for table background attributes, the background-image CSS property has a field day in AMP for Email. And yes, your CSS limit is 50kb.
#5 – AMP Cares About Validation
Email devs understand the culture of using tiny hacks to ensure their code runs perfectly on various email clients. But, performance and stability are important to the gods of AMP. If the content is not clean, AMP will gracefully fall apart.
All this means is that all unsupported attributes and tags will only make AMP not render.
#6 – Is AMP Good With Tracking Yet?
Interactivity such as hover-based events or sequential clicking is natural in AMP email. These are actions that the ESP or CRM may have difficulties tracking. How do you measure email campaign performance when you cannot track anything?
#7 – Will You Have the Time to Build an AMP Email?
AMP for Email is open-source, but not everyone is as open to using it. The reason is that it takes time to build an AMP email for decent traction. Be aware that this process also requires special codes that make the process work.
#8 – How About the Subscriber?
It’s a fact that the best technology is useless without consideration for the user. One of the essential points of AMP email is that the content can change after deployment. Is this something users want? Would you be receptive to emails with content that changes every time you open it?
Imagine the inevitable trust issues arising with subscribers not familiar with AMP.
Wrapping Things Up
The future is still hazy for AMP for Email, and many such as TechCrunch’s Devin Coldewey consider it a terrible idea. However, AMP is certainly not a technology to dismiss. It requires more knowledge than regular HTML email coding, as that’s the only way to ensure that your subscribers see your AMP email just as you intended.
Emma’s Logan Bird notes Google’s influence on email marketing over the years and believes AMP for Email will further push the envelope. He sees AMP as a way for email marketers, designers, and developers to grab attention, create more opportunities, and define new user experiences across the board. Whether AMP for email will become more than a trend remains debatable. There are benefits and downsides. Nevertheless, it’s budding technology, and it might be worth checking out, even if just for its immense potential.
