如果您的用户互动平台（CEP）不支持原生钱包卡券，摆在面前的有两条路线：接入一个卡券工具，让两套系统保持同步；或者迁移到一个在同一份用户画像上发放 Apple Wallet 和 Google Wallet 卡券的平台。第一条起步更快，第二条在钱包成为用户旅程的一部分之后更容易运营。
本文写给正在使用 Braze、OneSignal 或 CleverTap 等平台、想加上钱包卡券又不想推倒重来的团队，也写给正在寻找 OneSignal 替代方案的出海团队。如果想看服务商层面的对比，请参阅 Wallet passes 对比页面。
您现在的起点
各家用户互动平台对钱包的支持差别很大。Braze 通过 PassKit 等合作伙伴接入钱包。OneSignal 没有原生钱包卡券。这些情况会变化，所以在做规划前，请先查看您所用平台的最新文档。
没有原生支持时，卡券存放在一套系统里，用户数据存放在另一套系统里。您发放、更新或定向的每一张卡券，都需要同时用到两边的数据。
对出海团队来说，这个问题往往还会再叠一层：国内业务使用一套国内推送平台，海外业务另用一套推送平台。在海外这一侧再接一个独立卡券工具，同一家公司要维护的用户数据就从两套变成三套。
路线 A：保留现有 CEP，再加一个卡券工具
您继续用现有平台做推送、邮件和用户分群，再为 Apple Wallet 和 Google Wallet 接入一个独立的卡券工具。
通常的做法是：您的 CEP 或后端调用卡券工具的 API 发放卡券，往往通过 webhook。如果卡券工具提供事件，这些事件会回流到您的 CEP，供您对持卡人做分群。
好处是实实在在的。什么都不用迁移。团队继续用熟悉的工具和用户旅程，而且可以从一个使用场景起步，比如会员卡。
坏处会随时间累积。两个数据库要同步，两份订阅，两次安全和 GDPR 审核。每个把卡券更新和消息结合在一起的场景，比如“您的积分即将过期”，都要跨两个工具来搭建。
路线 B：迁移到原生支持钱包的平台
您把消息业务迁移到一个原生发放钱包卡券的平台，卡券与推送、应用内消息、邮件和短信共用同一份用户画像。
卡券在平台内按 User ID 发放。用户分群、用户旅程和各个渠道都把持卡人视为同一位用户。用户旅程里的一个步骤发放卡券，下一个步骤发送链接。
您得到的是一份用户画像、一个用户旅程和一份合同。卡券更新和消息来自同一个触发条件，没有需要时时照看的同步层。
代价是迁移本身：修改 SDK、导入数据、重建用户旅程和模板。当钱包是一个长期渠道，而不是一次性活动时，这笔投入才划算。
| 路线 A：CEP + 卡券工具 | 路线 B：原生钱包 | |
|---|---|---|
| 发出第一张卡券的速度 | 快 | 取决于迁移进度 |
| 需要维护的系统 | 2 套，外加同步层 | 1 套 |
| 包含卡券更新的用户旅程 | 跨 2 个工具搭建 | 1 个用户旅程 |
| 对持卡人做分群 | 依赖同步过来的数据 | 同一份用户画像 |
| 合同与供应商审核 | 2 | 1 |
| 最适合 | 单一的钱包使用场景 | 把钱包当作留存渠道 |
决策框架
用 4 个问题给自己打分。
-
范围
钱包是一次性活动，还是要运营多年的渠道？如果只是一次性活动，倾向路线 A。
-
渠道
有多少场景要把卡券与推送、邮件或短信结合？场景多，倾向路线 B。
-
团队
您有开发人员来搭建和维护同步层吗？如果没有，路线 A 的成本会随时间上升。
-
数据驻留
您是否需要欧盟托管，并为 GDPR 减少数据处理方？每多一家供应商，就多一个需要审核的处理方。
如果您的回答中有两个或以上是“长期”“很多”“没有开发人员”或“更少处理方”，就认真考虑路线 B。如果一个都没有，路线 A 完全是个好选择，1 年后再回头评估也不迟。
数据驻留这一问，对同时服务欧洲和美国用户的出海企业分量更重。要安全触达欧洲用户，GDPR 合规是绕不开的一环，而每多一家处理用户数据的供应商，就多一轮评估。
计算两个工具的成本
路线 A 在第一天看起来更便宜，因为什么都不用动。但放到 1 年来看，要加上那些永远不会出现在卡券服务商账单上的部分：搭建集成、维护同步、重复的用户旅程工作，以及第二次供应商审核。
路线 B 把成本前置：先是迁移工作，然后是一份平台费用。请把两者放在 12 到 24 个月的周期里比较，而不是只看 1 个月。
迁移时机也值得规划。跨境电商团队可以避开双十一与黑五、Cyber Monday 联动的大促季，选在大促结束后的淡季切换，让新平台在下一轮 618 或年末大促之前完成并行验证。
迁移清单
如果您选择路线 B，请围绕用户而不是工具来规划迁移。
- 盘点您发送的内容。 列出需要迁移的推送、邮件、短信和应用内消息活动、用户旅程和用户分群。
- 梳理数据映射。 User ID、标签、事件和授权同意记录。User ID 是把卡券和用户绑定在一起的关键。
- 一次性完成钱包配置。 一个 Apple Pass Type ID 证书（需要 Apple Developer 账号，每年 $99），以及一个 Google Issuer ID，并把 Pushwoosh 的服务账号邀请到您的 issuer。
- 集成 SDK。 在 App 中替换旧 SDK，在迁移流量之前先测试推送。
- 先重建关键用户旅程。 欢迎流程、购物车挽回、流失召回，然后是新的钱包场景。
- 规划卡券上线。 从用户旅程步骤发放卡券，并通过邮件、短信或推送发送链接。
- 短期并行运行。 让旧平台保留一小段重叠期，然后关闭。
迁移期间，可以用 API 从您自己的后端发放卡券。
用 Pushwoosh 精简您的技术栈
Pushwoosh 发放原生 Apple Wallet 和 Google Wallet 卡券，与推送、应用内消息、邮件、短信和 WhatsApp 共用同一套 User ID、用户分群和用户旅程。这是同一个平台，托管在自有的德国和美国基础设施上，符合 GDPR 要求，并通过 SOC 2 Type 2 认证。请看 Pushwoosh 在各类钱包方案中的定位。
加上钱包，不应该意味着再拼接一个工具，而应该意味着一份每个渠道都能据此行动的用户画像。
