Heard about Google’s recently announced AMP for Email project?
AMP, or Accelerated Mobile Pages, was developed by Google to efficiently load modules within web pages, specifically on mobile devices. A few weeks ago, Google announced they’ll be bringing this same technology to inboxes, allowing for what they’re calling “engaging, interactive, and actionable email experiences.”
Currently being tested by Pinterest, Doodle and Booking.com, it’s being used to include dynamic content and real-time pricing and availability, all within email.
Example of Pinterest using Google’s Amp for Email
But is this something you need to start learning right away?
Since I have the coding knowledge of about a 2nd grader, I turned to James Wurm and Rowdy Gleason, both Senior Email and Web Developers out of our Chicago and Seattle offices, respectively, to get their thoughts.
And I’d love to hear yours below in the comments.
Okay, so what are some good AMP for Email use cases?
RG: AMP is already used on the web for things like carousels, image galleries, hamburger menus, embedded video. With the new AMP for Email announcement, we can use those same modules within email. It’s even possible to theoretically load applications, demonstrated in the form of JSON, or JavaScript Object Notation, and interact with APIs.
I’d imagine for our typical client, the primary use cases would be simple carousels and hamburger menus. Although, the more exciting tech is dynamic and real-time content. Think real-time shipment tracking on your online orders.
JW: Versions of this type of programming already exist in some brands’ shipping confirmation emails, or other communications that provide status updates. For example, delivery tracking emails that are continually updated as more info is provided by the shipper. Right now, we use third-party vendors such as Movable Ink and Liveclicker for similar functions.
Why should businesses and email marketers care?
JW: If they’re communicating shifting data points, the emails could reflect live, current information, which is valuable to customers.
RG: This is a huge evolution for email if it sticks around and sees adoption across a broader base of clients. In the short term, it allows AMP developers to easily implement otherwise fairly intensive and hacky modules, like carousels (although purely as progressive enhancement). The real excitement are the long term implications that are much more difficult to envision. Being able to connect with APIs and load full applications can lead to a whole host of possibilities.
Example of Doodle using Google’s Amp for Email for real-time scheduling
How will this affect email marketers’ work?
RG: I think there is the desire to bring cool and interesting experiences to the inbox and this could be enticing if the tech is adopted and email developers become familiar with the language. It would allow marketers to mimic offerings like Movable Ink’s “real-time” content.
Where is AMP for Email supported?
RG: Support is extremely limited to Gmail webmail (not even their mobile apps). Even if Gmail is a majority market share for your list, I don’t believe the amount of development time necessary to make an AMP module is worth it. Google is hopeful that more clients will support AMP, but in my experience with Google technology for email (anyone remember Grid View, pulled less than a year after its release?) and other clients supporting modern web tech, that’s probably not going to happen.
What does this mean for email and web developers? How will this change how you work?
RG: In the short term, I don’t foresee clients investing the time to have developers code specific AMP modules. If we see Apple devices pick up this tech, it could become worth it. Otherwise we’ll likely continue doing kinetic development instead, as well as partnering with Movable Ink–type services that can show “real-time” content.
That being said, if we do see that adoption, our role will evolve a bit as we’ll need to learn AMP development – it’s basically its own language, although it’s fairly semantic and shorthand – and become quite good at it since the modules function independently from the markup that shows in unsupported clients.
Do you see any benefits to this new technology?
RG: The main benefit is evolving the inbox. Going back to the question about use cases, the best thing we can do with this service is real-time content (flight info, shipment tracking, etc.). Maybe if nothing else, it could push the inbox to adopt more web standards.
Example of Booking.com using Google’s Amp for Email showing real-time offers and pricing
Any drawbacks?
RG: The big one is support. Only working in Gmail is not sufficient for the amount of time invested into coding the module separately from the rest of the markup (meaning the fallbacks are entirely discrete). Knowing the pace at which email clients move, it seems unlikely that other clients will adopt it anytime soon. Even if they did, Apple is a must considering their device range makes up nearly 50% of the market share. For OMC Creative Services standards, we expect at least that, in addition to the big webmail providers, to pick it up before considering it standard support. Otherwise it exists more in the realm of kinetic.
JW: Google hopes devices and platforms will support this feature, but enforcing such would be difficult and messy. Also, they have a history of big pushes for new tech, and then dropping products after a few years. Imagine all the training and strategy that could go into a fully realized campaign, just for Google to unceremoniously kill the library.
Any other drawbacks developers and email marketers should consider?
RG: Frankly, there are some major problems I have as a web developer when it comes to development, security and weight.
In terms of development, although it seems simple enough in the examples provided like carousels, the code is proprietary Google AMP – essentially shorthand Javascript with some markup. I’d recommend spending a lot of time becoming very familiar with the possibilities before making it an official offering, which requires a big up-front investment for a technology that is likely not going to be around for very long or adopted, based off Google’s history with these things (speaking about AMP for Email, not AMP as a whole).
As far as security goes, AMP for Email allows applications to load inside the inbox. This is dangerous and alarming for obvious reasons, but in the same respect if anybody is going to have complete control over it, Google is a good company to put a handle on how it works and what can be done. I’d like to see more emphasis placed on security before I’m willing to assume more clients adopt the tech because Javascript has no business being in the inbox.
And lastly, load time and weight. This is the least important here, but worth noting that in Google’s presentation, they call out that modules do load independently from the rest of the markup. I didn’t enjoy that there was a noticeable “loading wheel” that held for a second on open, even on Wi-Fi. I can’t imagine it’s much better of an experience on dicey mobile connections. I’m not sure on the weight over a user’s connection and how that impacts data, but I’d be curious to play around and see how it feels in my hands and how much I can push it before it’s noticeably slow to load. The irony is that AMP for web is meant to make the experience faster than typical pages, but compared to simple HTML/CSS for email it’s probably still heftier.
So, do you think this will be worth it?
RG: In its current state – no. It needs to at least see adoption by Apple before it’s worth investing time into beyond cute enhancements. Having to code the module independently rather than as a progressive enhancement means directly investing time into whatever client supports it at the time, which I currently do not see a serious benefit to doing.
We can continue to do kinetic development and work with our partners to provide a more well-supported but similar experience in the inbox without investing a ton of development time into learning a proprietary new tech that may or may not exist in a few years.
When can marketers or developers start using this technology in their own email communications?
JW: There’s no date provided for wide release. It seems it’s still in beta mode.
RG: And right now developing for it is under NDA and a limited acceptance. They’re looking to release it this year publicly and broaden to their mobile apps. If your dev team can get access to the developer preview then you can start right away – public release is slated for “later this year.”
So what do you think? Are you biting at the bit to get creative with Google’s new AMP for Email? Or will you just wait and see? Let us know below!