Yes!
What email does not have to solve for is the bootstrap problem – AMP in email is supported by Gmail and Yahoo, who together have over 2 billion mailboxes. Of all the criteria for a super app we have discussed, there are five which I think are the most important: single sign-on, access to multiple services, support for payments, open architecture for extensions, and security. So, let’s evaluate Email 2.0 against each of these.
Single sign-on: All marketing emails come into the email inbox. There is thus an in-built single sign-on just to the email app. No separate access is needed to incoming emails.
Services: Inside the inbox and within their emails, brands can offer their own mini-apps. There are very few limits to what can be created. These apps can engage with the brand’s services to facilitate two-way interactions. While there are some limitations on what AMP can do, there is a lot of heavy lifting that can be done on the server to create myriad use cases. Here are examples of customer journeys across the customer lifecycle for eCommerce, BFSI, and travel and hospitality.
Payments: AMP can support in-channel payments – subject to the regulations in the country. The one difference with existing super apps is that each brand will have its own payment handling rather than a single solution across the email inbox. In that sense, think of the inbox more like a mall with separate checkouts in each store rather than a megastore with a single checkout.
Architecture: Email’s open architecture lets any brand construct AMP emails. In fact, a super app can be limited by the choices that the app controller makes. In the case of email, any brand can create AMP emails to engage with its customer base.
Security: AMP, originally conceived at Google, has very strong security. Content sent over the internet is encrypted. An AMP email loses its interactivity when it is forwarded with the fallback content showing up. Netcore has a detailed explainer. Even ChatGPT agrees.
[ChatGPT]
AMP (Accelerated Mobile Pages) for email is designed to provide dynamic and interactive content within emails. While it aims to enhance the user experience, AMP for email also takes into account security concerns. Some of the security features associated with AMP in email include:
- Content restrictions: AMP for email has strict limitations on the components and scripts allowed within the email. This reduces the risk of potentially malicious code being executed in the user’s email client.
- Sandboxing: AMP for email content is usually sandboxed or isolated from the rest of the email client, preventing potential security risks from affecting the client or the user’s device.
- Validation: The AMP framework requires that AMP emails pass validation checks before they can be rendered by email clients. This validation process ensures that the AMP email adheres to the rules and specifications defined by the AMP project, reducing the likelihood of security vulnerabilities.
- HTTPS requirement: AMP for email mandates the use of HTTPS (secure HTTP) for all network requests, ensuring that data transmitted between the user’s device and the server is encrypted and secure.
- Limited access to user data: AMP for email does not have direct access to the user’s cookies, local storage, or other sensitive information stored in the email client. This limits the potential for misuse of personal data.
- Email provider’s security features: AMP emails are subject to the same security features implemented by the email provider, such as spam and phishing filters, which help protect users from potentially harmful content.
[Rajesh] So, are we ready for Email 2.0 as the next super app?
