智能、聚焦、邮件。
超高效兼跨平台:专为静忧收件设计,专心聚焦重要事项。
💡 AMP for Email:一种可让你将交互式、类似应用的组件直接嵌入电子邮件消息中的格式。 比如可直接填写的表单、可滑动浏览的图片轮播,或会实时更新的产品列表,而且这一切都无需离开收件箱。
还记得电子邮件只是静态文本和图片的时代吗? AMP 颠覆了这种模式。
有了 AMP for Email,邮件本身就能做事。 真正能做事。 比如,一封餐厅预订确认邮件,可以让你直接在邮件里点击按钮更改预订时间。 又比如,一封电商邮件中的产品库存和价格会自动更新,即使是在邮件送达几天后也是如此。 再比如,活动邀请函中你只需轻点一下即可回复是否出席,而不必打开浏览器。
这项技术来自 Google(基于他们的 AMP web framework),旨在缩小网站能做到的事与在电子邮件客户端中能做到的事之间的差距。 基本上,它让电子邮件不再像静态文档,而更像迷你网页应用。
不过,问题在于:支持范围有限。 Gmail 对它的支持很好,Yahoo 和 Outlook 的支持程度各不相同,而有些客户端则完全不支持。 根据 Litmus Email Analytics 的数据,只有大约 23% 的邮件打开行为发生在完全支持 AMP 的客户端中。 也就是说,你是在为不到四分之一的受众构建交互式体验。 其余用户看到的是回退版的 HTML 邮件。
AMP 邮件实际上包含同一条消息的三个版本:AMP 版本、HTML 版本和纯文本版本。 电子邮件客户端会选择其支持的版本并显示出来。
AMP 版本使用特定组件(称为 AMP 组件)来实现交互功能。 例如,用于图片轮播的 <amp-carousel>、用于提交数据的 <amp-form>,以及用于从服务器刷新动态内容的 <amp-list>。 这些组件都运行在沙箱环境中,并经过验证,因此无法运行任意 JavaScript,也不能执行恶意操作。 安全性是设计中的一个重要考量。
HTML 回退版本是其他所有人看到的内容。 你需要把它设计得与 AMP 版本看起来相似,只是去掉交互部分。 轮播会变成静态图片。 表单会变成一个打开你网站的按钮。
纯文本是为老旧客户端或偏好纯文本邮件的用户准备的终极回退方案。
当用户与 AMP 组件交互时(比如点击按钮、提交表单),相关操作会通过安全的 HTTPS 端点将数据发送到你的服务器。 你的服务器会处理这些数据,并可返回更新后的数据来刷新邮件的部分内容。 这就是为什么产品价格或库存数量在发送几天后仍能保持最新。
不过,技术要求相当严格。 你需要向 Google 验证发件域名,正确实施 DKIM 和 SPF 身份验证,并通过发件人审核流程。 对小团队来说,这可不是什么周末就能搞定的项目。
电子商务尤其适合 AMP。 可根据当前库存更新的产品推荐、用户无需离开 Gmail 就能将商品加入购物车的浏览购买体验,以及带有实时价格的弃购提醒。 由于减少了操作阻力,因此转化率会提升。
活动管理也会变得更顺畅。 邀请函中内置 RSVP 表单、一键集成日历、以及随着更多人确认出席而更新的参会者名单。 这比把人们引导到外部注册页面要方便得多。
问卷调查和反馈也没那么折腾了。 不再是“点击这里参与我们的调查”,而是调查问卷就直接在邮件里。 当人们不必切换到浏览器时,回复率会更高。
内容源 如新闻摘要或博客汇编,可以在打开时而不是发送时拉取最新内容。 这样一来,邮件实际上就成了你最新内容的实时视图。
旅游与酒店服务会将其用于预订确认,让你可直接在确认邮件中选座、预订餐食或办理航班值机。 减少应用切换,体验更好。
一定要先构建回退版本。 在开始做 AMP 之前,先设计好 HTML 版本。 你的大多数受众看到的都会是这个版本;如果回退版本很糟,那整个营销活动都会很糟。
别玩得太花。 能加 47 个交互元素,不代表你就应该这么做。 专注于一两个真正有意义、确实能改善用户体验的交互。 比如真正能发挥作用的轮播和表单。
充分测试。 不同客户端和版本之间对 AMP 的支持差异极大。 在 Gmail 网页版能正常运行的内容,到了 Gmail 移动应用里可能就会出问题。 在发送给完整名单之前,先在真实收件箱中测试所有内容。
注意加载时间。 打开时刷新的动态内容需要调用服务器。 如果你的端点响应缓慢,邮件看起来就会像坏掉了一样。 保持快速。
考虑隐私问题。 AMP 邮件可以追踪用户何时打开邮件,以及他们如何与组件交互,这是普通邮件做不到的。 要透明说明数据收集情况。
权衡开发成本。 构建 AMP 邮件所花的时间明显多于普通 HTML 邮件。 在投入大量资源之前,先确认这些交互功能确实能推动你的关键指标。