大多数出海团队都想知道，哪些推送营销活动真正带来了收入。真正卡住他们的是归因问题：支付数据分散在不同系统里，格式各不相同，把它和触发购买的那条消息对应起来，本身就是一个不小的工程。所以团队最终还是回到打开率和点击率——因为这些数字已经在仪表盘上了。
解决方式很直接：把收入数据接入营销平台能直接使用的格式。以下是 Pushwoosh 的具体做法。
收入数据为什么很难进入你的营销平台 💰
根本原因在于格式：收入数据从来不会以统一的形态出现。
比如，你的 SDK 在用户购买游戏币时触发一个应用内购买事件；你的后端发送一个自定义的 OrderPlaced；Stripe 和 Shopify 各自为订阅和商店订单推送自己的 webhook 事件。每一种事件的字段名、结构、对”金额”的定义都不一样。
要跨所有这些来源统计收入，就需要有人为每个来源单独写逻辑，还要持续维护同步。大多数出海团队顾不上做这件事，因为这不是优先级，直到季度复盘时才发现数据根本不完整。于是收入追踪被一再推迟，团队继续汇报打开率，因为这些标准指标早就接好了。
而这个问题其实可以很快解决：核心就是把收入统一成 1 种格式，再对接到你的海外用户增长基础设施上。
用 1 个事件承载所有收入
Pushwoosh 用 1 个内置事件解决格式问题：PW_Conversion。无论原始数据来自哪里，收入最终都会落地为 1 条格式统一的记录，字段固定：
- value — 交易金额
- currency — 例如 USD 或 EUR
- transaction_id 和 product_id — 可选标识符
就这么简单。订阅续费、应用内购买、Shopify 订单——全部变成同一种事件。收入一旦变成 PW_Conversion，下游的一切都读取同一份数据：RFM 细分、Customer Journey、仪表盘，以及 ManyMoney AI。
2 种接入方式
你需要为每个应用单独设置转化事件，有 2 条路径可选，选和你现有支付数据流最匹配的那一条。
- 映射已有事件——无需写代码。 如果支付数据已经通过其他事件流入 Pushwoosh，直接把 Pushwoosh 指向它即可。选择来源事件，并映射其字段：哪个属性是价格，哪个是货币。之后每次该事件触发，Pushwoosh 都会自动生成一条 PW_Conversion 记录，不需要改动 App 的一行代码。你可以同时映射多个来源——比如自定义的 purchase_completed 事件和一个 Stripe 或 Shopify webhook 并存。
- 从代码中直接发送 PW_Conversion。 如果你更倾向于显式发送收入数据，可以在 App 或后端完成购买的位置加一次 postEvent 调用。这条路径需要开发团队配合，但只是一次性的小工作量集成。
哪些事件能变成收入（哪些不能）
映射方式适用于任何带有金额的事件：
- 自定义事件 — 你自己的 purchase_completed、subscription_renewed、order_placed。
- 默认事件 — 只要它代表一次付费行为。
- 入站 Webhook 事件 — Stripe、Shopify，以及你接入的其他支付来源。
无法映射的是没有金额可读的事件。App_open、screen_view 或 push_opened 只记录用户做了什么。没有金额，就没有可转化的内容。
收入接入后你能看到什么
这才是真正的价值所在。收入数据标准化之后，3 件过去需要额外开发的事情变成了内置功能：
- 按消费能力分群。 RFM 细分直接读取 PW_Conversion，你的高价值海外用户会自动进入 Champions 分群，随时可以推送专属的复购或会员权益。
- 验证哪些 Journey 真正驱动了购买。 在任意 Customer Journey 中将 PW_Conversion 设为 转化目标。运行结束后，目标统计会显示实际购买的用户数，而不只是打开数。“这条流程到底值不值”这个问题，终于能在画布上直接看到答案。
- 在仪表盘中直接呈现收入，与其他 重要的 App 表现指标 放在一起，而不用为每个购买事件单独开发统计逻辑。
找到匹配你 App 的场景
同一套设置可以适配不同的收入模式。找到和你的 App 最接近的那一行：
| App 类型 | 需要映射或发送的事件 | 最终能看到什么 |
|---|---|---|
| 跨境电商 | 映射 order_placed + Shopify 或 Stripe webhook | 哪些购物车挽回流程真正带来订单；按消费额做 RFM 分群找出复购用户 |
| 出海游戏 | 从代码发送 iap_completed、battle_pass_bought | 关卡后的付费引导是否真正转化，而不只是被打开；为高价值玩家建立消费分群 |
| 订阅制（媒体、流媒体） | 映射 subscription_renewed、plan_upgraded（Stripe、App Store） | 召回流程是否带来真实续订；按续订时效做 RFM 分群 |
| 出海金融科技 | 映射 premium_subscribed、first_trade 或支付 webhook | 哪些引导流程带来了实际入金账户；按交易量分群 |
| 跨境零售履约 / 物流类 App | 从后端映射 order_placed | 哪些召回推送带来了复购；按最近下单时间做 RFM 分群 |
| 出行 / 预订类 App | 映射 booking_confirmed + seat_upgraded 等附加消费 | 哪些降价提醒真正转化为预订；按订单价值分群 |
order_placed + Shopify 或 Stripe webhookiap_completed、battle_pass_boughtsubscription_renewed、plan_upgraded（Stripe、App Store）premium_subscribed、first_trade 或支付 webhookorder_placedbooking_confirmed + seat_upgraded 等附加消费让收入数据出现在营销人员日常工作的地方
转化事件只是 Pushwoosh 更大方向中的 1 部分：让收入在营销人员本来就在使用的界面里可见，而不是藏在一份需要专门去取的报表里。
你已经在决定发什么、发给谁、发多频繁。现在这些决策依据的是打开率和点击率，因为我们能给你的就只有这些。发送 PW_Conversion 之后，同样的决策就能基于真实收入来做：保留哪些活动、砍掉哪些活动、哪些分群值得多触达——以及哪些分群只是在消耗你的退订额度，却没换来任何收入。
收入数据接通之后，还会带来叠加的收益：
在 Pushwoosh 中落地收入追踪
从工作量更小的路径开始：映射一个已有事件，或者把 postEvent 示例交给开发团队。把 PW_Conversion 设为下一个 Journey 的转化目标，看着收入和打开率、点击率一起出现在报表里。
