我认识的两个团队运营着同一款应用，在同一个月报告的退款率分别为 3.1% 和 5.8%。两边都没有说谎，只是他们对这个指标的定义不同，而且没有人把定义写下来。
这就是移动应用退款分析中那些不会写在功能介绍页上的事。这个数字的可靠程度，取决于背后使用的归因规则，而大多数 dashboard 并不会说明它们用的是哪种规则。
因此本文将介绍这些工具的具体功能，以及在信任任何一款工具之前都应该问的那个方法论问题。仅就追踪机制而言， 如何追踪 App Store 退款 这篇文章在 Apple 这一端讲得更深入。
核心要点
队列归因胜过周期归因。应将退款计入购买发生的那个月，而不是退款到账的那个月。
退款延迟可达数周，有时甚至整整一个计费周期。任何显示“本月退款率”的 dashboard 展示的都是不完整的数据。
拒付不是退款。RevenueCat 明确说明它不会将拒付算作退款，因此你需要一个单独的数据来源。
应用商店后台是免费的，但在趋势分析上表现较弱。Apple 提供报告，Google 提供一个有每日调用上限的 API。
追踪移动应用退款率的最佳工具，是那些公开自己分母计算方式的工具。
首先，定义问题
应用退款率追踪有两种做法，而这两种方法得出的结果并不一致。
周期法：将 3 月到账的退款除以 3 月计费的交易数。搭建起来很容易，但不准确，因为 3 月的退款往往对应的是 1 月的购买。
队列法：在 1 月计费的所有交易中，此后被退款的比例是多少。搭建起来更难，因为这个数字一直在变化，永不停止。
Apphud 对此说得很坦诚。他们的分母是该周期内计费的交易数，分子是此后被退款的数量，即使是在该周期结束之后退款的也算在内。这正是队列法，也更符合退款的实际发生方式。
所以你需要一个截止期。月度订阅大约在 30 到 45 天 后趋于稳定，年度套餐则会持续波动数月。把一个 10 天前的数字和一个 90 天前的数字放在一起比较，比的其实只是噪声。
免费层级：应用商店后台
从这里开始。这不花一分钱，也是大多数团队止步的地方。
App Store Connect。 “销售与趋势”加上“财务报告”能为你提供退款数据，而且财务报告与你的收款金额是一致的。它基于周期、需要手动操作，也没有按产品或渠道的细分。用于每月的粗略核对还可以，但找不出究竟是哪个付费墙在流血。
更好的免费数据源根本不在后台里。Apple 的 Get Refund History 接口会返回每个客户所有退款交易的分页列表，你可以把它拉取到自己的数据仓库中。它有速率限制，而且 Apple 建议使用通知而非轮询，所以最好把它当作对账手段来用。
Google Play Console。同样有财务报告，此外还有 Voided Purchases API，可列出某个时间范围内被退款、拒付或撤销的购买。调用上限为 每天 6,000 次、每 30 秒 30 次，所以它是为定期扫描设计的，不适合任何实时场景。
这两个后台在趋势分析上有一个共同的缺陷：它们报告的是已结算的结果，而不是已提出的请求，所以你永远看不到那些被你成功抵御的请求。
RevenueCat
如果你的订阅已经通过它处理，这就是默认选择。
退款率是他们的一项基准指标：付费订阅在首个计费周期内被退款的比例，并会与你所在应用商店和分类中的其他应用进行对比。这种基准对比才是有用的部分，因为一个脱离同行背景的原始数字很难据此采取行动。他们的 State of Subscription Apps 报告覆盖了 7.5 万多款应用，中位数约为 3% 到 5%。
此外还有一张 App Store 退款请求图表，按照已批准、已拒绝、已撤销和待处理结果进行划分。这是请求级别的数据，大多数工具都没有提供。
有两个需要注意的地方。由 Google 而非你批准的 Play 退款，最多需要 24 小时才会显示；而在未勾选撤销选项的情况下发出的退款，则完全不会被检测到。另外，RevenueCat 不会将拒付算作退款——购买状态会更新，但退款率不会变动。
Adapty
在细分方面比大多数工具更出色。退款追踪可以按 天、套餐、产品和获客渠道 进行拆解，而这正是真正能发现问题的切分方式。如果整体退款率看起来正常，但在某一个渠道上却很糟糕，那问题出在营销文案上，而不是产品本身。
他们的基准数据来自 超过 1.1 万款应用、累计 19 亿美元的追踪收入，不同分类之间的差异大到足以产生影响：教育和健康类接近 4.7% 到 5.1%，旅行和实用工具类则接近 1.5% 到 2.1%。年度套餐的退款率高于每周套餐。强制付费墙约为 5.8%，而免费增值模式约为 3.4%。
这里的限制和他们产品中其他地方一样：这些优质分析功能的前提是你使用了 Adapty SDK。
Apphud
规模更小、价格更便宜，而且在方法论上异常清晰——光凭这一点我就会把它列入候选名单。他们的文档明确写出了队列逻辑，而不是把它藏起来。提供实时 dashboard，大约 18 种订阅事件，营销话术也比其他替代品少。
如果你想要一个能在董事会会议上站得住脚的数字，清晰度胜过一份更长的功能清单。
专门的退款与拒付追踪
这就是空白所在。订阅平台统计的是已结算的退款。它们都不处于响应窗口期内，所以都无法告诉你成功抵御了多少请求，也无法告诉你按退款原因划分的胜率。
这是一组不同的数据，而它只有在真正有人回应这些请求时才会存在。 Refund Sensor 会把 Apple 退款请求和 Google Play 拒付审核都作为案例进行追踪，记录时间线、处理结果以及成功保住的收入，两大应用商店的数据都集中在一个 dashboard 中。它能展示那些从未变成退款的请求。
值得搭配使用，而不是互相替代。订阅平台用于队列分析，移动应用收入保护软件用于请求级别的趋势分析。这是两个不同的问题，彼此都无法覆盖对方。
单独追踪拒付
拒付趋势并不是退款趋势的一个子集，而把它们当成一回事，是我在移动应用退款追踪中见过的最常见的错误。
在 Google Play 上，信号有所不同。实时开发者通知会在某笔购买被作废时推送 voidedPurchaseNotification，在某笔拒付需要你处理时推送 pendingRefundReviewNotification。Voided Purchases API 带有一个 voidedReason 字段，共有九种取值，包括 fraud、friendly_fraud 和 chargeback。这是最接近免费拒付趋势线的方案。
在 Apple 这一端，则是带有撤销原因的 REFUND 通知，以及针对未成立案例的 REFUND_DECLINED 和 REFUND_REVERSED。
要得到一条真实可靠的拒付趋势线，可以按产品拆分，绘制 voidedReason 等于 chargeback 随时间变化的曲线。然后再把 fraud 和 friendly_fraud 单独绘制出来，因为这些账户会反复出现，需要采取不同的应对方式。关于哪种数据源各自适用于什么场景，我们在 Voided Purchases API 与实时开发者通知对比中有详细介绍。
如何在移动应用中追踪退款率和拒付
我实际会按以下顺序搭建的技术栈：
选定一套归因规则并写下来：采用队列法，并为每种套餐周期明确设定截止期。
接入应用商店的数据源：App Store Server Notifications V2，以及 Play 上的 RTDN。没有它们，你就只能每月翻阅 CSV 文件。
将每一个退款事件都关联到原始交易上，而不是关联到当天的日期。
加入请求级别的事件，否则你永远看不到自己成功避免了什么。
把拒付单独拆分出来，并附上各自的原因代码。
以你所在的分类作为基准进行对比，而不是对比全球平均水平。
第 3 步是自建系统悄悄出问题的地方，第 6 步则是 dashboard 悄悄产生误导的地方。这两步都不难，但都常常被跳过。
如果想了解成本一面而不只是退款率， 退款实际上会如何消耗你应用的收入 这篇文章算清了这笔账。单独一个退款率数字，并不能告诉你接下来该怎么做。
参考来源
常见问题
如果你想要分类基准数据和请求级别的 Apple 图表，选择 RevenueCat。如果你需要按渠道和套餐进行细分，选择 Adapty。如果你想要最清晰公开的统计方法，选择 Apphud。如果你还想看到那些未变成退款的请求，再加上一个防御工具。
用已退款交易数除以付费交易数，并归属到购买发生的那个周期。然后决定让一个队列成熟多长时间后才算最终结果。月度套餐为 30 到 45 天，年度套餐则更长。
对于订阅类应用，付费交易中的 2% 到 5% 属于正常范围。教育、健康与健身类应用通常更高，旅行和实用工具类则更低。一旦超过 10%，就别再看营销了，去检查你的付费墙吧。
不能完全做到。Apple 的财务报告只显示已结算的退款。Google 的 Voided Purchases API 会显示带有原因代码的作废购买，这是最接近的方案，但每天调用次数上限为 6,000 次，需要定期扫描。
几乎总是归因延迟造成的。收入报告是基于周期的，而退款率应该基于队列，两者只有在每一笔退款都到账后才会趋于一致。另外要检查是否包含了拒付，因为有些工具会将其排除在外。
Apple 没有公布任何具体阈值，如果有人很自信地说出一个数字，我会持怀疑态度。有文档记载的是，持续偏高的退款和争议率可能会影响 Google Play 上的账户状态。这比单纯关注某个数值更有理由去追踪趋势。
