追踪移动应用退款率和拒付趋势的顶级工具

大多数人阅读这类文章的原因都差不多：某次结算金额比表格里写的低，于是有人开始查找原因，一小时后屏幕上出现了一个谁都不愿看到的数字。

移动应用的退款数据并非真的被隐藏，只是分散在各处。Apple 把它放在一份报告里，Google 则放在另一份报告加一个 API 中，而且两者都不会告诉你客户为什么要退款。我们在关于 选择 Apple 退款管理工具的文章中介绍过能对退款采取行动的工具。这篇文章则聚焦于那些只负责告诉你发生了什么、以及各自在哪些地方会对你保持沉默的工具。

核心要点

• 两大应用商店的控制台都在销售报告中将退款显示为负数单位，只有数量，没有原因或比率。

• 付费交易中 2% 到 5% 左右的退款率属于正常范围。一旦超过 9%，问题就不再是追踪本身了。

• RevenueCat、Adapty 和 Qonversion 都会绘制退款率图表，但各自对退款的计日方式不同，因此同一个月可能会出现两个不同的数字。

• 对于 2026 年 8 月 3 日之后的订单，Google 现已就拒付向开发者收费，而目前很少有工具能将拒付单独列为一条数据线。

• 我们最先关注的数字根本不是退款率，而是有多少退款请求未得到回应。

为什么应用商店控制台还不够

Apple 的 Sales and Trends 报告中确实包含退款数据。在 Trends 标签页添加筛选条件，将 Transaction Type 设为 Refunds，退款就会以负数单位的形式出现。 Apple 官方帮助页面指出，控制面板显示的是"近乎实时的估算值"，而可下载的报告则是"最终确定"的数据，两者可能存在差异——而它们确实会有差异，通常偏偏发生在你最需要两者一致的那天。

Google 在数据方面更慷慨，但在呈现方式上就没那么用心了。 Voided Purchases API会提供每一笔被退款、取消或拒付的订单，每笔订单都带有九种 voidedReason 代码之一，包括 remorse（反悔）、friendly_fraud（善意欺诈）和 chargeback（拒付）。但这终究只是一个 API，没有图表，每天只有 6,000 次调用配额，剩下的都得你自己搭建。有一个不易察觉的陷阱：在 Play Console 中发起退款时如果没有勾选"Remove entitlement"，这笔退款就永远不会出现在该 API 中。我们在 退款后如何撤销访问权限一文中详细写过这一点。而且两大商店都不会直接给出比率，只提供数量。计算比率的工作要你自己完成，而根据我的经验，每个月的算法多少都会有些出入。

一个理想的数字应该是多少

RevenueCat 的 《State of Subscription Apps 2026》报告覆盖了超过 115,000 款应用，其中大多数类别的退款率中位数落在 3% 到 4% 之间。生产力类最高，为 4.7%，旅行类最低，为 2.5%。价格也会推高退款率，从低价区间的约 2.7% 一路升到高价区间的 4.5%。异常值区间为 9% 到 18%，这些情况几乎都是由于漏洞、过度承诺的付费墙或被盗信用卡造成的。

Adapty 基于约 11,000 款应用的 2 月报告结论大致相符，教育类接近顶部，约为 5%，旅行类垫底，约为 1.5%。两份报告在生产力类别上的数据存在分歧，因此我不会过分依赖任何单一类别的数字。

如果你的退款率是 3.5%，那没什么问题。如果是 8%，说明某个具体环节出了问题，而且是可以找出来的。如果你根本不知道自己的数字，那就先把这个搞清楚。

逐一盘点退款率追踪软件

RevenueCat

Refund Rate（退款率）图表以某一时期内的付费交易（不含试用）为基础，显示其中被退款的占比。需要注意的是，退款会归属到原始购买日期，因此一笔今天发生、但对应 3 月购买的退款会被计入 3 月。这种方式对同期群分析来说是对的，但会导致上个月的数字在一段时间内持续变动，让人感到意外。

Adapty

提供两个图表：退款金额和退款事件，均按退款处理日期计日，与 RevenueCat 的做法正好相反。两种方式都没有错，但我见过有团队在两者之间迁移时，花了整整一周才确信自己的退款率并没有真的变动。

Qonversion

在 Revenue 板块下提供 Refunds 和 Refund Rate 图表，可按产品、国家和币种筛选，能满足基本需求。

电子表格

在体量较小时确实管用，这点我不否认。但一旦你新增第二款应用，或者退款率发生变动、你想弄清原因时，它就不够用了。

这大致就是通用平台上移动应用退款分析的现状。它们能很好地回答"有多少"，但没有一个能真正回答"为什么"。

移动应用拒付追踪工具：选择有限的领域

长久以来，拒付在 Android 上是 Google 自己承担的问题，在 iOS 上则根本不算问题。后来 Google 更改了条款。对于 2026 年 8 月 3 日之后的订单，开发者需要自行承担争议金额（扣除 Google 的费用），外加通常为 15 至 25 美元的卡组织手续费。一笔 4.99 美元的购买如果发生拒付，可能会让你损失约 23 美元。

这一变化让拒付分析软件从"锦上添花"变成了相当紧迫的需求，而工具端的发展还没跟上。Voided Purchases API 会为拒付标注专属的原因代码，因此你至少可以自行统计。RevenueCat 在 7 月的社区论坛上表示，他们"不会将拒付计为退款"，因此拒付不会出现在退款率图表中。Chargeflow 及同类争议处理工具都是为 Web 支付而设计的，据我所知并不涉及 Play billing。

Refund Sensor 会在一个仪表盘中同时追踪两大商店，将 Google 单方面裁定的退款与进入审核流程的拒付分开记录，并显示我们针对每一笔所提交的回应内容。只有后一类才是你可以申诉的对象。详情请见 Google Play 退款申诉页面。

如果你正在比较各类移动应用拒付管理软件，要问清楚拒付是单独成行显示，还是被并入了退款数据。一旦被并入，趋势就会消失，而趋势恰恰能告诉你，你面对的究竟是欺诈问题还是产品问题。

如何在不自欺欺人的情况下追踪移动应用退款率

以下是我们盯着这些仪表盘看久了之后总结出的几点经验。

选定一种计日方式，不要中途更换。按购买日期计算能反映产品质量随时间的变化，按退款日期计算则反映本月的现金流状况，把两者混在同一份报表里，会让每张图表都悄悄说谎。

要统计请求数量，而不只是结果。当客户就应用内购买向 Apple 申请退款时，Apple 会向你的服务器发送 CONSUMPTION_REQUEST 通知，并等待 12 小时。Google 现在也会在裁定拒付前发送审核通知，给你 24 小时的响应时间。如果你的工具只显示已批准的退款，你根本无法知道有多少通知未得到回应。这个缺口才是我会在退款率之前优先追踪的数字，也正因为如此，我们才能确认自己 77% 的申诉成功率是真实的。

哪款退款追踪软件最好？

这取决于你缺少的是什么。如果你已经在使用 RevenueCat、Adapty 或 Qonversion，内置图表在计算退款率方面完全够用，只需清楚它采用的是哪种计日方式。如果你需要把拒付单独列为一条数据线——在 Google Play 上现在很可能确实需要——那么通用平台大多还做不到这一点，这正是专注于退款的工具所能填补的空白。而如果你想知道自己有多少请求从未得到回应，只有监听商店通知的工具才能告诉你，因为分析平台只看得到结果，从来看不到问题本身。

结语

追踪移动应用退款率本身并不难。应用商店会提供数量，每个订阅平台也都会画出这条曲线。真正的问题在于，这条曲线本身几乎说明不了什么，因为两款退款率同为 4% 的应用，背后出问题的原因可能完全不同。

真正让追踪变得有价值的是上下文：商店愿意提供的那些原因、被单独保留为独立趋势的拒付数据，以及你从未申诉过的请求记录。先拿到退款率固然没错，但真正的价值藏在这些上下文之中。