• Exciting news! Mapp is acquiring Webtrekk, the German leader in Customer Intelligence. LEARN MORE

A Real-World Perspective on AMP for Email

Andrew Bradley

The world of email marketing doesn’t get too many new and shiny ideas to play with, as it’s a well-established and well-understood way of interacting with customers. But occasionally something new comes along. Right now there is a justifiable buzz around Google’s AMP for Email. This is a technology that extends email to be interactive and have dynamic content, and expands on the success of AMP – a way of building faster loading web pages for mobile devices, currently in use on a staggering 31 million domains.

 

Justis Saayman, Mapp’s Product Marketing Manager and marketing thought leader, says:

“Being in the email industry and a big fan of Gmail and its tech for years, I am happy to see AMP come to email. Its evolution onto the mobile web was a game changer, offering faster loading speeds and a generally better experience for consumers and now it’s available in email; Bliss! 

AMP offers as much a revolution as an evolution in email which will only serve to benefit the marketer who has a Gmail-heavy database and a reduction in dwell times in this time-poor world. Users in the modern world open emails fleetly, moving from one to the other in fast succession, but with the right mix of design and interactivity I think they would seriously take that extra second to engage.”

Why does this all sound familiar?

Google themselves tried it with ‘Enhanced Email’ back in 2010, with some success. Microsoft also tried a similar approach with Hotmail in the same year. Apple tried with a new email standard for the Apple Watch, and despite the ubiquity and usefulness of the platform, it has so far not resulted in much interest partly due to the requirements it places on ESPs to support it (adding a new MIME type).

So how is AMP different, and might it succeed?

Google’s vision includes the creation of a user-specific microsite that sits in their inbox. They have done an excellent job of marketing this idea and has genuinely stirred up interest with marketers. The well-established and comprehensive amp.dev site and the wider open-source community support means that it has some technical traction too.

Ajit Bola, Account Manager at Mapp, comments:

“I see AMP as a key enabler for clients to improve email conversions. The additional interactive layer that AMP offers, such as a deeper interactive onsite style experience is giving marketers high expectations that email engagement metrics like OR, CTR, and dwell time will see an increase. 

Why do I think this? Well when we look at traditional email in a retail scenario the customer will always get to a point where they will need to leave the email to complete the conversion process. The capabilities of AMP now give the functionality to complete these transactions without ever leaving the email. With less steps to undertake, you would expect to see the rate of conversion abandonment go down.

 I do believe that as we start to scratch the surface and further understand the potential of AMP we will start to see a shift in how email communications are conducted by marketing teams.”

However, the limitations of the approach are not well understood yet, and some may be disappointed to discover that it is not widely supported yet. Currently, an AMP email can only be displayed in the web-based Gmail client (but users can still choose to turn off support). Even the Android and iOS apps for native Gmail are not there yet, but ‘coming soon’. Gsuite can support AMP but requires admins to turn it on. Better put in a ticket now… At time of writing, Outlook.com and mail.ru are lining up support ‘soon’. Take a look at https://emailclientmarketshare.com/ to see how much of a footprint AMP might have in terms of email clients vs. % of use out there in the real world. Remember that not everyone with a Gmail address uses email clients provided by Google.

The reason for the lack of support is simple. First, it requires ESPs to support a new MIME type as an extension to the existing RFPs. Second, clients need to implement code to display it, since this is essentially a new language that developers must learn and has to be interpreted at the receiving end. You will find that the developer community is split on this, some don’t like that Google is breaking established standards in email, and some don’t like that this is done using a new language. They are missing out on a lot though…

Some have also said that users might be confused with email that has active buttons and forms etc., even though anyone using web-based emails will have seen this coming in. Google calendar invites in the Gmail app, for example. Dynamic emails that change every time you view them are pretty new, and despite some current technology that allows prices to be fetched at the time of email rendering, most users won’t have really noticed it yet.

While there are some challenges, any technology that promotes a better way of rendering than the current minefield of compromises in HTML-based design is to be applauded. AMP simplifies mobile web pages already and is a great tool. The limitations are not a problem with careful consultancy and selection of use cases.

Best practices when implementing AMP for Email:
  1. Segment your audience towards the clients that at least have some possibility of displaying the email. Right now this would be Gmail.com users only, and not all of those will see it.
  2. Track opens on the AMP-specific part of the email using a tracking pixel.
  3. Ensure that there is an HTML fallback in the event that the email can’t be displayed (the old MIME types are still there).
  4. If the email needs to be forwarded, use a link that creates a new email. AMP emails can’t be forwarded, only the fallback HTML or text.
  5. Get email deliverability support. When AMP starts flying around, there will be challenges with some parts of the infrastructure not liking active content and not liking the new MIME content. Be aware that Google maintains a secondary level of trust of senders that is not transparent and would need some help to navigate.
  6. Select the right use case.

Number 6 is the big one.

What are the right use cases?

These use cases are examples and by no means exhaustive.

Mapp can help you navigate this. We have already published a guide on use of categories and logos in Gmail and other clients that you can read here. But even more so, we can get you set up to send AMP emails and can code them for you. We recommend a ‘start small, execute, measure, and refine’ based approach.

The truth is that nobody knows how well this technology is going to perform and the key to success is to consider the marketing use cases first. We can hold your hand to help you get more comfortable with AMP. Mapp will also be refining our best practice recommendations as we become more familiar with it. On a final note, remember that other technologies exist. Don’t chase AMP if there are higher impact ways of getting similar content to users. We can help with this, too.

CONTACT US