我之前写过一篇关于 Google、Yahoo、Microsoft 和 Apple 正在如何改造 email 的文章。当时我提到，这几家公司已经不再只是简单的“邮件传输层”，而是逐渐变成了品牌与用户之间真正的中介者：它们会解析、排序、总结，甚至越来越多地开始替用户“回答”邮件。

而如今，同样的事情也正在 push notification 上发生。

只不过，这一次控制整个渠道的公司从四家变成了两家。Apple 和 Google 掌握着全球唯二真正重要的 push 管道，而你曾经发送过的每一条通知，都必须经过它们。在过去几年里，那个位于“消息送达”和“锁屏展示”之间的 on-device model，已经开始主动对通知进行总结、重排，甚至在某些场景下直接重写内容。

很多人至今仍然把 push notification 理解成一种“发送即送达”的渠道，但现实其实已经越来越像 email：平台不再只是负责运输，而是开始主动决定，哪些内容值得被用户看到、应该以什么形式被看到，以及它究竟值不值得打断用户。

而对于所有依赖 push 做增长、留存和营销的人来说，这件事的重要性可能远超想象。

Push 最初其实是一个电池问题

Push notification 的诞生，本质上其实是为了解决电池问题。

2009 年 6 月，Scott Forstall 在 WWDC 上解释说，iPhone 根本无法承受所有应用都各自维持一个后台轮询连接，不断向远程服务器查询新消息。那样做的结果，只会让设备续航迅速崩溃。

Apple 最初原本计划在 2008 年 9 月推出 push 服务，但后来因为决定重构底层基础设施以支持更大规模，而推迟了发布。最终诞生的方案，就是 Apple Push Notification Service（APNs）：每台设备只与 Apple 建立一个持久 TLS 连接，而所有第三方应用都通过这条连接发送通知。

APNs 于 2009 年 6 月 17 日随 iPhone OS 3 正式上线，而 Google 随后也迅速跟进：

2010 年：Cloud to Device Messaging
2012 年：Google Cloud Messaging
2016 年：Firebase Cloud Messaging（FCM）

从一开始，这个渠道其实就是“被中介化”的。

每一条发往 iPhone 的通知都会经过 Apple；每一条发往 Android 的通知都会经过 Google。平台从诞生第一天起，就拥有 throttle、drop、log、deprioritise，甚至 outright refuse 某条通知的能力。

只不过，在 push notification 的大部分历史里，它们并没有明显地使用这些能力。换句话说，这种架构一直都允许平台进行干预，只是平台过去长期保持克制，而现在，这种克制结束了。

平台干预的十五年

2009 到 2017 年之间，push notification 的世界相对平静。APNs 与 Google 的各种服务基本只是负责把通知送到用户安装的 app，平台层面的过滤非常有限，用户也只有最简单的 per-app 开关。

真正第一次重要的 on-device 干预，发生在 2017 年 Android 8 Oreo 推出的 Notification Channels。

在 Android 8 之前，每条通知都携带一个由发送方决定的 priority level；但 Android 8 之后，控制权被拆成了两层：developer 定义 channel，user 决定 channel 的行为。

开发者需要为 app 定义若干 channel，例如：

downloads
messages
promotions

等等。每个 channel 会对应一个 importance level，而用户则可以单独对每个 channel 进行 mute、demote、disable badge，甚至 fully block，而不会影响其他通知。

更关键的是，一旦开发者设定了 channel importance，之后便无法再提高；与此同时，任何 targeting Android 8 的 app，如果不声明 channel，通知甚至根本不会显示。

Apple 则在 2021 年 iOS 15 中，以另一套语言体系做了类似事情。Focus、Scheduled Summary，以及新的 interruption taxonomy——passive、active、time-sensitive、critical——共同重新定义了 iOS 如何处理 push notification。

其中唯一真正可以被营销人员“利用”的级别是 time-sensitive，但 Apple 从一开始就明确表示：不要把它用于 marketing。

Google 后来甚至进一步把“通知权限”本身变成了核心控制杠杆。2022 年 Android 13 将 POST_NOTIFICATIONS 改成 runtime permission，也就是说，用户必须显式授权，而不再像过去那样默认 opt-in。

结果当然非常明显。Pushwoosh 对 1600 万设备的研究发现：

gaming app 的 opt-in base 下降接近三分之一
news app 下降 19%

而 Batch 在 2025 年对超过 8000 亿条消息、10000 个 app 的 benchmark 显示，Android opt-in rate 在一年内从 85% 掉到 67%，跨平台平均值最终稳定在 61%。

整个过程的本质，其实是发送方正在持续失去控制权。

其中一部分控制权转移给了用户，这其实是合理的，因为用户本来就应该决定什么值得打断自己；但另一部分，则转移给了平台，而这才是真正值得发送方警惕的部分。

因为平台的判断是 opaque、unappealable，而且 increasingly model-driven。

十五年来，整个 push channel 一直在围绕一个核心假设被重新设计：

用户的注意力是一种稀缺资源，而平台有义务保护它。

而平台之所以保护这种资源，并不仅仅是为了用户体验。低疲劳、干净的 notification surface 可以提高 retention、减少 uninstall，同时还能展示平台自己的 AI 能力。因此，这种“编辑行为”并不是纯粹的用户保护，而是平台在保护它自己的资产。

而作为 sender，你天然站在这个假设的对立面。

Email 其实已经先经历过这一切

Email 比 push 更早进入这种“被平台中介化”的阶段，因此它其实是 push 的预演版本。

但 push 比 email 更糟，因为 email 至少还有一定程度的 instrumentation，例如：

Postmaster Tools
deliverability dashboard

等等，而 push 几乎什么都没有。

Email 至少还存在 inbox——用户可以回看、搜索、重新进入；而 push notification 只存在于 notification center 里，它会被清除、折叠、总结、静默丢弃，并且不会被可靠保存。

Email 的 ML filtering 可以追溯到 1990 年代后期。当时 Bayesian spam filtering 让邮件系统从 rule-based filter 转向 classifier：模型会综合 content、sender reputation 与 recipient engagement 进行判断。后来 SPF、DKIM、DMARC 等认证机制出现，但它们并不是替代 ML，而只是成为 ML 的 signal。

于是，营销人员逐渐意识到：email 已经不再是一种“发布行为”，而更像是向隐藏 classifier 提交的一次“请求”，而 classifier 会决定，你是否值得进入 inbox。

2013 年 Gmail 推出 tabbed inbox：

Primary
Promotions
Social
Updates

本质上也是 classifier。Promotions tab 并不是 spam folder，它代表的是：系统认为这些邮件虽然合法，但本质上是 promotional。

Apple Mail 也在 2024 年加入了类似分类，而每一次这样的变化，都进一步拉大了 sender intent 与 user experience 之间的距离。

真正毁灭性的变化，则发生在 2021 年 iOS 15 推出的 Mail Privacy Protection。

Apple Mail 开始通过 Apple proxy 预加载远程内容，即便用户根本没有打开邮件。结果，营销人员长期依赖的 open-pixel tracking 基本失效。Omeda 的数据甚至显示，仅仅因为 Apple 的 prefetch，Apple Mail 的 open rate 六个月内就从 22.6% 飙升到 40.5%，而不是真实阅读增长。

从那之后，open rate 彻底失去意义，click-through 与 downstream conversion 才开始变成真正重要的 signal。

后来，Yahoo 与 Google 更进一步，它们开始把 deliverability 本身变成 gatekeeping。从 2024 年开始，任何向个人邮箱发送大量邮件的 sender，都必须：

SPF
DKIM
aligned DMARC
one-click unsubscribe
低 spam complaint

否则根本无法进入 inbox。2025 年后，Google 甚至从“延迟投递”升级为“直接拒收”。

而如今，push notification 已经走到了 email 十年前到达的位置。

只是，push 的结构天生比 email 更不利于 sender。

因为 email 基于开放协议，而 push 完全不是；email 的 mailbox 可以在任何 client 打开，而 push permission 只存在于某个设备上的某个 app install 中；email 至少允许 sender 持有 subscriber list，而 push token 则完全由 Apple 与 Google 控制。

Email 是用户主动进入的空间，而 push 本质上是 interruption。

因此，平台对 push 的控制力，天然比 email 更强。

手机上的“编辑器”

Email 的编辑主要发生在“传输途中”，而 push notification 的编辑，则发生在 display layer。

真正决定通知是否会被：

show
summarise
deprioritise
group

的，并不是网络，而是设备本地运行的模型。

Apple Intelligence 使用的是一个 30 亿参数 on-device foundation model，外加更大的 server-side model。其中 summarisation adapter 的训练数据，明确包括：

email
message
notification payload

而 Apple 的做法，并不是每个 feature 单独训练一个完整模型，而是在 base model 上动态加载 LoRA-style adapter。因此 summarisation、entity extraction、prioritisation 等等，其实都只是不同 adapter。

这也是为什么 Apple 后来能够迅速关闭 News summary，而不需要替换整个模型。例如 BBC 抱怨 Apple summary 生成了错误标题后，Apple 很快：

禁用了 News summary
把 AI summary 改成 italic
增加 per-app off switch
加入 warning

Google 的 Gemini Nano 则运行在 Android 的 AICore 中，它同样支持 summarisation、proofreading、rewriting 与 notification organisation。

真正重要的是：

你的 notification 到底会如何展示，已经不再由你决定。

整个流程现在其实是：

app 构造 payload
提交 APNs / FCM
平台送达设备
OS 应用 user rule
model 进行 summarisation / ranking / prioritisation

例如在 iOS 上，如果 Notification Summary 开启，那么系统会把来自同一 app 的通知组合后送入 foundation model summariser，随后原本的 title 与 body 会被 AI 重写成一句新的 summary。

而且，你几乎无法影响这些过程。

你可以修改 payload、fetch image、自定义 expanded view，但你无法：

禁止 summarisation
禁止 prioritisation
检测自己是否被 summary
检测是否进入 Promotions
检测是否被 Focus 静默

平台根本不会告诉你。

用户到底如何处理通知

绝大多数 notification，其实并不会立即触发 action。

用户通常只是“看到一下”，然后继续原本的事情，而真正导致 app open 的，只占很小一部分。

学术界其实已经研究这个问题很多年了。2014 年的大规模 Android 研究发现，用户最重视的是 messaging notification，而最讨厌的是 promotional notification。

事实上，今天 Android Notification Organiser 的“Promotions”分类，本质上就是把十多年前学术研究中的结论产品化了。

研究还发现，人均每天大约会收到 63.5 条 notification，而即便 valuable notification，也依然会造成 disruption。与此同时，用户的心理特征，会显著影响他们对 interruption 的感受。

另一项非常有意思的研究，是让用户 24 小时完全关闭 push notification。结果显示：

productivity 提高了
anxiety 也提高了
social connection 降低了

而超过一半用户在实验后，开始更认真管理 notification。

整个领域几十年的研究，最终其实都在反复得出同一个结论：

volume kills permission
relevance is everything
promotional notification 最容易被讨厌
transactional / conversational notification 的容忍度远高得多

因此，未来 push notification 的世界，很可能会越来越像 Gmail Promotions tab。

营销人员究竟还能看到什么

答案是：越来越少，而且这是平台故意设计的。

今天你能看到的 metrics，大致只有：

sends
accepted-by-platform
delivered-to-device
displayed-on-device
opened
attributed conversion

其中 APNs 与 FCM 最可靠的，其实只是 accepted-by-platform。也就是说，Apple 或 Google 接受了 payload，但至于用户是否真正看到，平台根本不告诉你。

甚至：

是否被 Notification Summary 合并
是否进入 Promotions
是否被 Focus 静默
是否被 Priority Notifications 降权
是否因为 storage limit 被丢弃

你统统无法知道。

整个 funnel 中间层，完全是黑箱。

因此，今天衡量 push 的方式，其实已经和 Mail Privacy Protection 之后的 email marketing 非常类似。你只能看到：经过平台“编辑层”筛选之后，最终产生 action 的那部分用户。

而且，如果 engagement 变高，你根本无法判断：

到底是你的文案变好了，
还是平台开始更信任你了。

你现在其实是在为“模型”写通知

Broadcast copy 已经无法完整穿过整个管道，因为 summariser 会把 notification 压缩成 gist。

因此，真正能穿过去的，是事实，而不是品牌语气。

你应该把：

amount
name
time
action

放在最前面。

例如：

Your delivery is 15 minutes away

这种 notification 就非常 summary-stable；而：

We’ve got great news!

这种则完全不稳定，因为它没有事实。

Notification title 现在应该被视作一种“用自然语言写成的 structured data field”，而不是 marketing copy。

把重心转向你真正拥有的渠道

未来，push 不应该再承担整个 lifecycle programme。

真正更重要的，是 app 内部那些你真正拥有的 surface：

in-product card
in-app inbox
in-app message
embedded workflow messaging

这些都：

不经过 APNs / FCM
不会被 Apple Intelligence 编辑
不会被 Gemini Nano 总结
不会被 Focus 静默

而且你可以完整测量它们。

问题在于，owned surface 只能触达 active user。因此 push notification 将越来越退化成：

dormant user re-engagement
truly time-sensitive transactional alert

而其他一切：

cross-sell
upsell
discovery
education

都会逐渐转向 app 内部。

这一切最终会演变成什么

一旦 on-device language model 已经存在，那么 summarisation 其实只是开始。

Apple 的 Foundation Models framework 已经允许 app 直接调用 summarisation、entity extraction、refinement 与 short dialog；Google 也在 Android 上开放了类似能力。

换句话说，model 已经不再只是 feature，而开始变成基础设施。

接下来的下一步，其实已经非常明显：

agent 会开始直接替用户处理 notification。

例如：

打开 app
完成 booking
dismiss alert
自动回复

事实上，Apple 已经申请了相关专利。

因此，未来真正重要的，不再只是：

“如何写一条 summary 不会出错的 notification”。

而是：

你是否把 notification 背后的 action，暴露成了 agent 可以直接调用的接口。

到那时，notification 不再是 destination，它只是 agent 的 trigger。

现在应该怎么做

你现在面对的，其实是一个：

看不见、
无法申诉、
只对用户负责、
而不对你负责的编辑器。

你无法压过它，因此很多事情都必须改变。

Push 应该只承担那些“其他渠道做不了”的任务。真正适合 push 的，是 dormant user wake-up、transactional alert 与 genuinely time-sensitive event，而不是 generic campaign。

Notification 也应该围绕用户自己的 activity，而不是你的 marketing calendar。真正最容易穿过平台过滤的 notification，往往只有两类：

第一类，是用户主动订阅的东西，例如：

price drop
back-in-stock
watchlist
threshold alert

第二类，则是用户自己的状态变化，例如：

document shared
comment reply
task completed
delivery update

这些 notification 天然具备 relevance，因此平台也没有理由 suppress 它们。

与此同时，你也不应该再迷信 push dashboard。今天的 push analytics，本质上已经建立在一个你完全看不见的 editing layer 之后，而真正重要的 signal，只剩下 downstream conversion。

Push 从来都不是真正“属于 sender”的渠道，它只是比 social 稍微没那么“租来的”而已。而如今，平台正在重新定价这份租约。

未来十年真正能活下来的 sender，不会是发最多通知的人，也不会是文案最 clever 的人，而会是那些发送的内容，本来就是用户真正想收到的东西的人；以及那些早已把最重要 interaction 转移到“没有编辑器存在”的 surface 上的人。

你必须开始为那个你永远看不见的模型写作。

Subscribe 订阅