为什么不选择 AMP for Email?
AMP for Email 是 Google 用于在邮件内部原生运行真正互动组件——轮播图、表单、实时价格——的技术,完全无需跳转到网页。这是一项正当的技术,也自然会引出一个问题:为什么 MailInApp 不基于它构建(或与动态 HTML/CSS 并用)?本页明确说明这其中的权衡,因为这是一次刻意的取舍,而不是一个疏漏。
AMP for Email 到底是什么,以及它的两项代价
AMP 邮件会在常规 HTML 之外附带一个额外的 MIME 部分,使用一组受限的 amp-* 组件构建(Google 的 AMP 框架,被挪用于邮件场景)。在它能够渲染的地方,体验是真正原生的——那个收件箱不需要任何静态回退。
它带来两项不会出现在功能对比表里的代价:
- 逐个发件人审批。 每个发送域名都必须先向 Google 注册并通过审核,才能让任何收件人看到来自它的 AMP 邮件——这是一道你无法控制的关卡,有自己的时间线和被拒风险,挡在每一次营销活动前面。
- 渲染支持范围狭窄。 只有 Gmail、Yahoo Mail 和 Mail.ru 会渲染 AMP。其余每一个客户端——Apple Mail、Outlook(经典版与新版)、Fastmail、Proton、三星邮件——都会完全忽略 AMP 部分,回退到随附的纯 HTML 部分。
实际触达范围
根据 Litmus 的邮件客户端市场份额数据(约 10 亿次追踪打开量,2026 年 5 月):
| | 打开量占比 | | --- | --- | | Apple Mail | 64.7% | | Gmail | 24.1% | | Outlook(所有版本) | 6.9% | | Yahoo Mail | 2.6% | | 其他所有客户端 | 1.7% |
Gmail 与 Yahoo 加在一起,是唯一真实存在的 AMP 受众,约占打开量的 27%。剩下的 约 73%——仅 Apple Mail 一家就占了近三分之二的打开量——无论 AMP 组件做得多好,都永远看不到它。即便在 Gmail 内部,AMP for Email 也只在收件人用 Gmail 自己的客户端读取 Gmail 账户时才生效;用 Gmail 移动应用读取非 Gmail(IMAP)收件箱同样不满足条件。
任何真实的收件人列表,主体都会是 Apple Mail 用户。把互动体验押在 AMP 上,意味着这份列表里的大多数人永远看不到它。
为什么动态 HTML 对典型受众列表是更好的选择
MailInApp 的动态层——依靠 :checked 驱动的 CSS 状态机实现轮播图、手风琴、投票、转盘抽奖,并在受支持的地方叠加真正的邮件内 <form> 提交——可以触达 Gmail(网页版与移动版)、Apple Mail、Yahoo Mail 和三星邮件:消费者收件箱的绝大多数,Apple Mail 也在其中。完整的支持矩阵见邮件客户端支持,三个层级如何从同一份设计编译而来见降级机制如何工作。
这就是这次权衡的核心:同一份降级引擎投入,能在几乎整份列表上兑现回报,而不只是 AMP 至多能触达的那 ~27%——而且它上线时不需要挡在每次营销活动前面的逐发件人审批关卡。在 AMP 能渲染的那一处地方,它的上限确实更高(真正原生的组件,完全无需跳转),但对于绝大多数并非 Gmail 用户的受众来说,它没法成为主要的互动层。
这是否意味着彻底排除 AMP?
从架构上讲不是。动态 HTML/CSS 和层级二的纯链接回退,已经是每个客户端都会退回到的安全基线——本页描述的这套三层模型,未来完全可以在此之上再承载第四个专供 Gmail/Yahoo 收件人的 AMP 专用部分,而不必改动其他层级的工作方式。只是这不是降级引擎当前优先投入的方向:用一种可靠的技术触达每一个收件箱,胜过用原生方式触达四分之一的收件箱、而让剩下的完全落空。