Amazon Pinpoint 正在退场。AWS 将于 2026 年 10 月 30 日停止支持这项服务，控制台连同里面的终端节点、分群、活动、旅程和数据分析一起消失。如果你在看这篇文章，大概率已经接受了”消息运营需要换个新家”这个前提，现在要解决的是更难的问题：换到哪一个。
AWS 在其官方停服公告里说明了停服细节和它推荐的替代方案，这篇文章讲的是从这里往后该怎么走。如果你更需要的是”什么时候关、怎么迁”这类问题（截止日期、停用清单、导出步骤），可以看我们的Amazon Pinpoint 停服迁移指南。这篇文章接着往下讲：迁移的目的地该怎么选。
对于选择 AWS 作为出海基础设施的中国团队来说，这个决策还多一层考量：国内的推送服务商大多围绕国内安卓生态设计，原生对 FCM 和 APNs 的支持不是它们的重点，海外合规认证也不是它们的强项——所以候选名单基本会限定在真正为海外用户触达设计的平台里。
该评估什么
看过第 3 家厂商演示之后，功能清单就开始变得千篇一律。以下 5 条标准，是替换 Pinpoint 时真正会改变决策的关键点：
- 开箱即用的通道。 推送（移动端和 Web）、应用内消息、邮件、短信/WhatsApp：哪些是原生支持，哪些是附加功能或第三方集成？应用内消息是最该重点核实的一项。这是 Pinpoint 用户最容易默认”每个平台都有”的通道，但这个假设并不成立：AWS 自己推荐的路径 Amazon Connect，根本不支持应用内消息。
- 定价模型。 按 MAU、按用户档案数、按坐席数，还是纯用量计费：模型比数字本身更重要。按档案数计费的模型会因为大量沉默用户而多付钱；按 MAU 计费的模型则会因为用户增长而支出上升。要按自己用户结构的形态去匹配定价模型，而不是只看当前团队规模。
- 迁移成本。 能否通过 API 或界面直接导入终端节点，还是要自己搭一套 ETL 管道去重塑和加载数据？这是实打实的工程工时成本，不同厂商之间差异很大。
- 能否对等替换已有能力。 Pinpoint 的活动和旅程做的是具体的事：多步骤自动化、行为分群。你迁移到的平台需要能复现这套逻辑，否则就不是”迁移”，而是”重做”。
- 到底适合谁用。 独立开发者、产品团队和企业级市场部门要的不是同一款工具。这个品类里一多半的”选错”，要么是小团队买了企业级软件，要么是企业用了 6 个月就把入门级工具用爆了。
下面按”离 AWS 最近”到”离 AWS 最远”依次介绍各个选项。
留在 AWS 生态内：Amazon Connect + AWS End User Messaging
这是 AWS 自己推荐的路径。你的运营层工作负载会迁移到 Amazon Connect 外呼活动加 Customer Profiles，原始通道（短信、推送、语音、OTP）迁移到 AWS End User Messaging——它就是 Pinpoint 原来的通道 API，2024 年被 AWS 改了名字。
如果你深度依赖 AWS 生态，且大部分是由自己后端驱动的交易类消息，这条路可以是对的选择，因为你能留在同一个厂商、同一张账单里。但具体到移动端运营，有两个有据可查的缺口：Connect 没有原生的应用内消息，推送也不是活动的原生通道（要通过绑定 Lambda 动作的旅程来发）。这两点都直接来自 AWS 迁移文档，具体影响在迁移指南里讲得更细，这里不重复。
适合谁： 已经深度投入 AWS 做呼叫中心场景、并且有工程能力自己补齐应用内消息和推送缺口的团队。
Pushwoosh
先说明：这是我们自己的平台，所以请拿上面那 5 条标准来对我们较真。
Pushwoosh 是一个移动优先的出海推送平台：移动推送、应用内消息、Web 推送是原生的一等公民通道，原生支持 FCM 和 APNs，而不是挂在某个更大营销套件上的附加功能。对于专门替换 Pinpoint 推送和应用内消息能力这件事，这一点就是重点，因为应用内消息正是 AWS 路径上会缺失的那个通道。在这份名单里，只有它把 Pinpoint 用户最在意的这两样东西，都做成原生能力，并且都包含在入门价格里。
用前面 5 条标准来检验，表现扎实。通道：3 个推送通道加邮件和短信全部原生支持，应用内消息是真正原生实现，不是承诺。迁移成本：通过 API 或界面直接导入，不用自己写脚本重塑终端节点（AWS 那条路要你跑一个 Python 任务把终端节点映射进 Customer Profiles），迁移团队还能获得优先支持和 24 个月价格锁定。对等能力：分群、用户旅程编排器、A/B 测试、数据分析，全套工具标配提供，没有功能阉割，也没有”仅企业版”的隐藏门槛。定价：按 MAU 计费，并按 User ID 去重——同一个人在移动端和 Web 端都收到推送，只算一次，不会重复计费。
具体到价格，Push Only 方案是每 1,000 MAU 7 美元，这个价格拿到的是完整平台能力，不是阉割版。完整定价在需要邮件和短信时，提供每 1,000 MAU 13 美元的全渠道档位，并且每个方案都从 1,000 免费 MAU 起步，足够导入一个真实分群、跑一次试点。
适合谁： 核心场景是推送加应用内消息的产品和移动团队，想要免脚本导入、这份名单里最低的入门价，同时不想牺牲应用内消息或功能完整性。
Braze
提到”客户互动平台”时大多数人第一反应会想到的名字。在多数厂商对比文章里，它是这个品类的代名词，这也确实反映了它的市场地位。Braze 是一个成熟的全渠道 CEP，旅程编排能力（Canvas）很强，被 Etsy、Grubhub、HBO Max 等拥有数千万 MAU 的大型消费品牌使用。
代价是入门门槛高。Braze 采用基于月活跃用户和消息量的用量计费模型，但不公开定价，第三方估算入门级合同一年在数万美元级别。也没有免费试用，想用得先走销售流程签年度合同。这是一个强大的平台，只是定价和打包方式面向企业级客户，对于主要需求就是推送加应用内消息的团队来说，这个承诺分量偏重。
适合谁： 有全渠道需求、预算充足的企业级市场团队。
OneSignal
历史上以推送起家，在纯推送这条线上大概率是最直接的对等替代。OneSignal 后来扩展到邮件、短信和应用内消息，并在停服截止日期前发布了自己的 Amazon Pinpoint 迁移指南。这里不重复它的论点，重点是：它认真到愿意为这次停服专门写文章，说明这是一个活跃的、以移动端为中心的选项，而不是一个停止迭代的老产品。
适合谁： 重心在推送通知、想要一个成熟推送引擎并在其外围叠加全渠道能力的团队。
Customer.io 与 Iterable
两个以邮件为核心的互动平台，AWS 咨询公司 Caylent 在其 Pinpoint 停服解读文章里，专门把它们列为面向市场团队、迁移出 Pinpoint 的替代方案。两者都擅长生命周期和行为触发类邮件，自动化能力也叠加得不错，并且都已经拓展到推送、短信和应用内消息。
这里要仔细看定价模型，因为它和 Pinpoint 用户习惯的 MAU 模型不一样。Customer.io 按你存储的用户档案数计费，而不是按发送消息数，起步价约每月 100 美元对应 5,000 个档案，随规模上涨。如果你的发送量集中在一个精简名单上，这种模式很划算;但如果你带着大量低互动或免费层用户，就等于交了一份”沉默用户税”。Iterable 定位类似，处于企业级区间，走销售报价。两者都更偏邮件原生而非移动原生，要按你业务重心真正落在哪个渠道来权衡。
适合谁： 主渠道是邮件、移动端是次要层的市场和生命周期团队。
MoEngage
一个移动优先的互动平台厂商，在”移动端客户互动平台”这个提法下经常被当作参考对象，移动 App 深度和亚太市场渗透率都强于名单里的大部分选项。如果你的用户以移动端为主，且业务重心偏向亚太市场，它可以和 Pushwoosh、OneSignal 一起进入候选名单，作为移动导向而非邮件导向的选项。
适合谁： 移动端为主的消费类 App,尤其是亚太市场占比高的团队。
关于国内推送服务商的一点说明
极光推送（JPush）、个推（Getui）这类国内推送服务商经常出现在中国团队的候选名单里，但它们的产品设计以国内安卓生态和厂商通道为核心，对 FCM 和 APNs 的原生支持不是重点投入方向，面向海外合规审查的认证体系也不是它们的主打能力。对于触达海外用户的出海 App，这类工具解决的是另一个市场的问题，不建议作为海外用户触达的主力方案。
横向对比
下表价格为入门级参考，不是报价。企业级厂商不公开固定价格，对应单元格请理解为”需要走销售流程”。
| 厂商 | 推送 | 应用内消息 | 邮件/短信 | 入门价格 | 迁移成本 | 适合谁 |
|---|---|---|---|---|---|---|
| AWS Connect + EUM | 仅旅程内 Lambda 支持 | 不支持 | 邮件(SES) + 短信(EUM) | AWS 按量计费 | 高，需自建脚本/ETL | 已有 AWS 呼叫中心团队 |
| Pushwoosh | 原生 | 原生 | 均支持（全渠道档位） | $7 / 1,000 MAU | 低，API/界面导入 | 推送+应用内消息产品团队 |
| Braze | 原生 | 原生 | 均支持 | 约 $6万/年（估算，无公开定价） | 中，需 SDK 和数据模型改造 | 企业级全渠道 |
| OneSignal | 原生 | 原生 | 均支持 | 免费层起，付费按规模 | 低到中 | 推送为主的团队 |
| Customer.io | 原生 | 原生 | 邮件主导 + 短信 | $100/月（5,000 档案） | 中 | 邮件/生命周期团队 |
| Iterable | 原生 | 原生 | 邮件主导 + 短信 | 销售报价 | 中 | 企业级邮件/生命周期 |
| MoEngage | 原生 | 原生 | 均支持 | 销售报价 | 中 | 移动为主/亚太市场 |
| 极光推送 / 个推 | 国内厂商通道为主 | 有限 | 部分支持 | 国内计费模式 | 高，需重新适配海外通道 | 国内推送场景，非海外触达 |
应用内消息这一列值得多看两眼。这是唯一一个 AWS 路径上明确写着”不支持”的地方，其他厂商则从成熟到勉强够用不等。如果应用内引导、功能提示或付费墙是你 App 体验的一部分，这一列可能比价格更能决定选择。
缩小候选名单
选到剩 2、3 家之后，以下 4 个问题能戳穿大部分演示的水分：
- “能不能在你们的编辑器里现场搭一条应用内消息，而不是放一页幻灯片？” 如果是真正的原生通道，5 分钟就能演示出来。如果是路线图上的计划或第三方集成，你会听到各种含糊其辞。
- “我怎么导入 Pinpoint 的终端节点：API、界面，还是要自己写转换逻辑？” 这一个问题就能问出你的迁移成本量级。
- “你们的定价到底按什么计算：活跃用户、存储档案、坐席，还是消息量？” 然后拿这个模型去对照你真实的用户结构，尤其是任何大规模的沉默用户群体。
- “能不能用真实数据先跑一次试点？” 一个能导入真实数据试跑的免费层或试用期，比任何功能清单都更有说服力。
从哪里开始
如果你的 Pinpoint 用法主要是推送加应用内消息——这对当初选择 Pinpoint 的大多数移动团队都成立——那么既不用签企业级合同、又能匹配这个使用形态的候选名单并不长，而 Pushwoosh 正是为这个场景设计的。你可以从 1,000 免费 MAU 开始,导入一个真实分群，重建一条旅程，亲眼验证效果对等之后再决定要不要切全量。
不管最终选哪个方向，都别让评估过程把日历吃掉。2026 年 10 月 30 日是硬性截止日期。迁移指南讲清楚了具体步骤和真正吃时间的环节，让你能对着截止日期做规划，而不是等发现问题的时候才想起它。
