一笔跨境外卖订单，从”已确认”到”已送达”之间往往会触发 5–7 条推送通知。每周几单累计下来，App 在用户的锁屏上就开始像垃圾消息。海外智能手机用户平均每天已经收到 46 条推送通知；当一个 App 每周只发 2–5 条时，就已经有 43% 的用户选择关闭通知。
对于出海 App 来说，问题更棘手：海外用户对”打扰感”容忍度更低，一旦关闭通知，再唤起的成本极高。用户想随时知道”现在怎么样了”，但不想在这个过程中被打断五次。
留存与流失的分界线，就是你能不能判断：哪些时刻需要一次 Push,哪些时刻只需要保持可见。
本文将拆解：Alert 与 Live State 的根本区别、适用于任何实时场景的”3 条推送原则”、一个完整的出海外卖案例对比，以及如何在不重构现有技术栈的前提下接入 Live Activities。文中你也会看到，Pushwoosh 如何通过一套 API 帮助出海 App 在 FCM/APNs 之上统一编排 Push 与 Live Activities。
Alert 与 Live State：唯一需要掌握的区分
大多数团队把 Push 当作所有实时场景的默认通道。订单已确认,Push。骑手已接单,Push。骑手出发,Push。骑手临近,Push。已送达,Push。一件用户自己下单、本就预期会发生的事,却被打断五次。
每一条信息都重要,但不是每一条都需要是一次 Push。在任何实时场景中,通信的任务本质上只有 2 种:
Alert(警示) 的含义是:“发生了需要你关注的事,现在就看。“它是一次主动打断,要求用户立即注意。它应当只用于真正需要用户做出决策或改变行为的时刻——航班登机口变更、支付失败、司机已到达。
Live State(实时状态) 的含义是:“以下是此刻正在发生的事,你想看时再看。“它持续更新,常驻可见。Live State 覆盖的是用户想要追踪、但不需要对其做出反应的内容:骑手位置、制作时间、送达预计时间、比赛比分、运动距离。
Push 通知天然是为 Alert 而设计,Live Activities 天然是为 Live State 而设计。用 Push 来承载状态追踪,等于反复打断用户,去告诉他一件他并没有要求被打断去知道的事。
3 条推送原则
在任何一个实时场景中,你最多只需要 3 条 Push。
Start(开始)。 确认流程已启动。“你的订单已确认。""付款已发起。""你的网约车正在前往。“这一步设定用户预期、建立信心,同时激活后续承载全部状态的 Live Activity。
Exception(异常)。 发生了问题或需要用户介入的情况。“商品缺货。""骑手找不到入口。""支付被拒,请更新银行卡。""航班延误 2 小时。“这些才是合理的打断——因为它们要求用户采取行动。
Finish(结束)。 流程已完成。“订单已送达。""收款成功。""行程已结束。“这一步关闭闭环,同时结束 Live Activity。
Start 与 Finish 之间的一切,都由锁屏上的 Live Activity 承载:倒计时的制作时间、地图上移动的骑手、实时更新的比分、动态调整的 ETA。全部自动更新,零打断。
一个完整案例:跨境外卖订单的对比
以一个面向海外用户的外卖流程为例,对比接入前后。
接入前(仅靠 Push),约 45 分钟内 5 条通知:
- 🔔 “你的订单已确认”
- 🔔 “你的订单正在制作”
- 🔔 “骑手已取餐”
- 🔔 “骑手临近”
- 🔔 “你的订单已送达”
一顿午餐就被打断五次。一周两三单之后,单个 App 就累计了 10–15 条通知。这正是海外用户开始成批关闭通知权限的临界点——在海外市场,一旦失去通知授权,获客漏斗后半段几乎全部作废。
接入后(3 条推送原则 + Live Activity):
- 🔔 Push:“你的订单已确认” → Live Activity 启动
- 📱 Live Activity 静默更新:制作中 → 已取餐 → 骑手位置 → ETA 倒计时
- 🔔 Push(仅当必要时):“骑手无法进入小区,请查看手机”
- 📱 Live Activity:ETA 倒计时继续
- 🔔 Push:“你的订单已送达” → Live Activity 结束
用户从 5 次打断变成 2 次,如果出现异常则是 3 次。锁屏保持清爽,而实时可见性反而更好——不再是五条互相割裂的提醒,而是一条连续刷新的实时轨迹,包含骑手位置与 ETA,每几秒就更新一次。
实际业务效果: 通知关闭率下降、“我的订单到哪了”类客服工单数量下降、App 在锁屏上的可见时长从”闪现五次后消失”变成”连续可见 30–45 分钟”。对于出海 App,这直接意味着更低的用户流失和更高的留存。
把原则迁移到你的行业
同样的原则,适用于任何让用户追踪实时状态的出海场景。
| 出海行业 | Push:Start | Live Activity | Push:Exception | Push:Finish |
|---|---|---|---|---|
| 出海网约车 / 共享出行 | 司机已接单 | 司机位置、ETA、车辆信息 | 司机取消 / 路线调整 | 行程结束 + 费用 |
| 跨境电商 | 订单已发货 | 打包中 → 运输中 → 派送中 → 临近 | 配送延误或派送失败 | 已签收 |
| 金融科技出海 | 交易已发起 | 处理状态(跨境结算、KYC 校验) | 支付失败 / 异常交易 | 交易完成 |
| 出海游戏 | 赛事开启 / 体力已满 | 排行榜位置、Boss 计时、任务进度 | 匹配对手 / 连胜风险 | 对战结果 |
| 出海资讯 / 体育直播 | 突发新闻 / 直播开始 | 实时滚动:比分、票数、新闻头条 | 重大进展 | 事件结束 |
在每一种场景中,Push 负责标记真正关键的转折点,Live Activity 承载转折点之间的状态。
如何在不重构技术栈的前提下开始
最常见的反馈是:“接入 Live Activities 要做一次大重构。“实际上,用一个迭代就能跑完的三步法就够了:
-
梳理当前的推送流程
选一条实时旅程(订单追踪、一次网约车、一场比赛),列出它目前触发的每一条 Push。给每一条打标签:它是要求用户去做点什么或知道点新的事,还是一条用户自己查也能知道的状态更新?通常 5–7 条 Push 里,只有 2–3 条能通过这个过滤。
-
替换与合并
把状态更新类的 Push 全部关掉。在 Start 这一条 Push 上启动 Live Activity,在 Finish 这一条 Push 上结束它。在原本触发 Push 的每一个状态变化节点上,通过 Pushwoosh API 刷新 Live Activity 即可。
-
用数据验证效果
在 2–4 周内持续观察三个指标。通知关闭率应明显下降。客服侧'我的订单到哪了'类工单数量下降——因为 Live Activity 让用户自助可见。会话频次通常不降反升:拥有活跃 Live Activity 的用户倾向于更频繁打开 App,因为锁屏成为新的再入口。对于出海 App,这三项指标直接对应留存与 LTV 的提升。
用 Pushwoosh 构建出海 App 的实时消息流
让海外用户持续使用你的 App,靠的不是发更多通知,而是只在关键时刻打断他们。
Pushwoosh 通过 FCM 和 APNs 触达全球用户,在同一平台上编排 Push 通知、iOS Live Activities、应用内消息与邮件——已通过 SOC 2 Type I 与 ISO 27001:2022 认证,符合 GDPR 要求,数据中心位于欧盟与美国,帮助出海企业在全球市场安心运营。
