试想一下：您发起了一场针对 Android 用户的推送活动。仪表盘显示“已发送”，但打开率却只有预期的一半——您无法判断问题是出在创意不佳还是送达中断。
在 Android 上，答案往往两者都不是。通知渠道、优先级设置和激进的 OEM 电池策略，都可能在用户看到您的消息之前就悄悄地“杀死”它们。仪表盘不会标记这个问题，您的分析数据也无法解释，消息就这样消失了。
这是一本诊断手册：揭示 Android 送达漏斗的真正断点，以及您该如何应对——无需花费数周的开发调研时间。
您的推送通知到底在哪里丢失了？
大多数移动应用团队会跟踪两个数字：已发送和已打开。但在 Android 上，有四个阶段——最大的损失发生在中间环节，而这正是无人关注的地方。
每个转化环节都有其独特的失败模式：
已发送 → 已送达。 消息已离开您的服务器，但从未到达设备。常见原因：FCM 令牌过期、设备长时间离线、应用已卸载但数据库中仍存有旧令牌。
已送达 → 已显示。 消息已到达设备，但从未向用户展示。这就是 Android 特有问题所在：OEM 电池优化杀死了通知、通知渠道被静音或禁用、优先级设置导致静默送达。
已显示 → 已打开。 用户看到了通知，但没有点击。这才是创意、时机和相关性真正发挥作用的地方——但前提是您已确认前两个阶段正常工作。
关键在于：如果您的“已送达”到“已显示”的比率很低，那么再多的文案 A/B 测试也无济于事。您正在优化一条没人看到的消息。以下是通过三个步骤找到并解决真正问题的方法。
Android 推送送达的三大“隐形杀手”
通知渠道：1 个默认渠道 ≠ 策略
自 Android 8.0 起，每条通知都必须分配到一个渠道。用户可以独立控制每个渠道——静音、更改其行为或完全禁用。
问题在于：当所有消息——促销、交易提醒、待办事项——都通过同一个默认渠道发送时，一个被惹恼的用户就会将所有内容静音。他们本想少收些促销信息，结果却连订单确认、付款收据和安全警报也一并错过了。
应对方法： 按用例构建渠道。至少，要将交易型消息（订单状态、付款确认）与促销型消息（优惠、再互动）分开。每个渠道都应有其自己的重要性级别。
诊断信号： 如果所有消息类型——无论是促销型还是交易型——的流失率都相同，那么问题很可能出在您的渠道结构上。用户正在静音那个承载了所有消息的唯一渠道。
优先级与重要性：为什么您的消息会静默送达
有两个层级控制着通知的行为方式，混淆它们是最常见的错误之一。
FCM 优先级 决定了系统将消息传递到设备的紧急程度。高 (HIGH) 优先级会立即唤醒设备；普通 (NORMAL) 优先级可能会被批量处理和延迟。
渠道重要性 决定了通知到达设备后如何向用户显示。高 (HIGH) 重要性会触发浮动横幅和声音。默认 (DEFAULT) 重要性则会静默地显示在通知栏中。
陷阱： 高 FCM 优先级 + 默认渠道重要性 = 消息立即到达设备，然后无声无息地躺在通知托盘里。分析数据显示“已送达”，但用户从未注意到。
OEM 电池策略
原生 Android 只是故事的一部分。三星、小米、华为、Oppo 和 Vivo 都在 Android 默认设置的基础上，各自应用了更激进的电池优化策略。这些策略可以完全阻止您的应用接收推送通知——即使 FCM 令牌有效且送达“成功”。
以下是按制造商划分的具体情况：
- 小米 (MIUI)： 默认禁用自启动。设备重启后，您的应用无法接收推送通知，直到用户手动打开它——除非他们授予了自启动权限。
- 华为 (EMUI/HarmonyOS)： 激进的应用查杀会终止后台进程。即使应用最近被使用过，在一段时间不活动后，推送也会停止送达。
- 三星 (One UI)： “休眠应用”和“深度休眠应用”列表会延迟或阻止用户最近未打开的应用的通知。
- Oppo/Vivo (ColorOS/Funtouch)： 后台活动限制会静默地抑制通知。应用在打开时看起来正常，但后台送达会失败。
共同点是：在所有这些 OEM 设备上，用户必须明确允许您的应用在后台运行。没有该权限，送达在纸面上“成功”，但通知永远不会显示。
诊断信号： 如果在同一场活动中，不同设备制造商的送达率或打开率差异巨大，那么 OEM 限制几乎可以肯定是原因所在。
找到问题所在并修复它
您已经了解了可能出错的地方。以下是如何找到您的具体问题并解决它。
1. 设置您的诊断工具
按设备细分。 按操作系统版本和设备制造商创建 Android 专属的用户分群。这是您最重要的单一诊断工具。它能让您判断送达问题是普遍性的，还是仅限于特定的 OEM。
跟踪完整漏斗。 确保您的 SDK 设置能够报告“已发送”、“已送达”和“已打开”这几个不同的事件。否则，您对漏斗的中间环节将一无所知。
按用例构建通知渠道。 至少，将交易型（订单状态、安全警报）和促销型（优惠、再互动）分开。每个渠道都应有其自己的重要性级别。
开发需求（一次性设置）：
2. 运行一次诊断旅程
将同一场活动发送给您的 Android 用户分群（按制造商划分）和您的 iOS 受众。逐步比较旅程的流失率和打开率。
为此，我们建议使用对营销人员友好的 Pushwoosh Customer Journey Builder（您可以免费注册并进行测试）：
- ⚠️ Android 用户分群在送达步骤流失，而 iOS 保持稳定 → 问题出在基础设施：OEM 限制、令牌问题或渠道配置错误。
- ⚠️ 两个平台在打开步骤的流失率相当 → 问题出在您的消息本身：创意、时机或相关性。
- ⚠️ 某个制造商的流失率不成比例地高 → 您发现了特定于 OEM 的问题。
- ⚠️ 送达正常，但所有设备的打开率都很低 → 检查您的优先级/重要性设置。您可能正在一个默认重要性的渠道上发送高优先级的消息，这意味着它们送达很快，但显示时却是静默的。
3. 防止未来的损失
将优先级与重要性匹配。 对时间敏感的消息（限时抢购、安全警报）→ 高优先级、高重要性。非紧急内容（摘要、提示）→ 普通/默认。
不要将所有内容都设置为高优先级——这只会让用户更快地将您的渠道静音。
应用频率上限和静默时段。 过度发送消息是导致渠道被静音的最快途径。设置每个渠道的频率限制并通过静默时段尊重当地时区。这不能修复送达问题，但能保护它。
明智地使用静默推送。 静默推送通知让您可以在后台更新应用内容和同步数据，而不会向用户显示可见的警报。这是保持应用新鲜感的强大工具——但在经过电池优化的 OEM 设备上，它也有其自身的送达限制。
构建备用旅程。 这是您的安全网。如果一条推送通知在 N 小时内未被打开，则通过不同渠道触发后续跟进——应用内消息、电子邮件或短信。这可以应对 OEM 送达失败、渠道被静音以及低互动率的用户分群。
使用 Pushwoosh 修复您的 Android 推送送达问题
目标是建立一个可重复的循环：分群 → 衡量 → 识别失败点 → 修复正确的层级。当问题出在送达时，不要去修改创意。当问题出在创意时，不要去修改送达。
准备好开始了吗？在 Pushwoosh 中创建您的第一个用户分群，测试您的漏斗究竟在何处中断。
