第一次为某款应用审计收入损失时，我差点就要报告一切正常。退款率只有 2.4%，无论按什么标准衡量都算得上是个不错的数字。团队也在 Apple 规定的时限内回复了消费数据请求。从表面上看，没有什么需要挽回的。
然后，出于一种近乎固执的习惯，我又多跑了一次查询：当前有多少用户持有的付费权益，对应的交易其实已经被 Apple 退款了？答案是 41 个。而这款应用的付费订阅用户总共只有大约 900 人。我跑了两遍，因为我不相信这个结果。
这意味着近 5% 的用户每个月都在免费使用产品，而仪表盘却一直显示绿色。退款率也从未发生变化。关于这个权益修复问题，我在 如何在退款后收回访问权限中单独做了说明。
如果你正想弄清楚该如何挽回因 App Store 退款而损失的订阅收入，不妨从这里开始，因为退款本身只是你的钱实际流向的四个环节中最小的一个。下面是完整的全貌。
四大环节，按价值排序
我把这些归纳为四个环节，而按投入产出比排序的结果，和大多数人猜的并不一样。
漏洞：已退款却从未失去访问权限的用户。修复成本最低，却最常被忽视。
防御：用证据回应 Apple 的消费数据请求。这是每家供应商都在谈论的环节，因为它是软件能够自动化的部分。
召回：重新获取那些已退款或已流失的用户。见效最慢，但 Apple 今年悄悄让这件事变得更容易了。
重试：只要你不去干预，扣款失败往往会自行恢复。
大多数团队只在第二个环节上下功夫，而真正的惊喜却藏在第一和第三个环节里。
环节一：找出漏洞，只需一小时
大致的查询逻辑是这样的：找出过去 12 个月内所有带有撤销日期的交易，将其与你的权益表进行关联，统计有多少用户仍显示为有效访问权限。
如果结果确实为零，那可以跳过这一节。但如果不是，你就找到了一个每月都在流失订阅收入的漏洞，直到有人把它关掉为止。Apple 撤销了付款，但 Apple 不会动你的数据库。这两者始终是脱节的，除非你主动把它们连接起来。消耗型项目的情况更糟，因为一旦物品被消耗掉，StoreKit 就无从追回了。
（我自己在这件事上就错了好几个月。通知处理程序把 REFUND 事件记录到了一张没人看的表里。记录不等于处理。）
解决办法是：监听 REFUND 事件，在撤销日期当天收回权限，并处理 REFUND_REVERSED 事件，重新授予访问权限。在客户发起争议后，Apple 有时确实会撤回自己的退款决定，你不应该因此惩罚客户。
既然已经在查询了，不妨再做一次统计：计算有多少退款你根本没有收到服务器通知。如果这个数字不是零，说明你的接口出了故障，而且第二个环节也同样存在问题。
环节二：捍卫那些你仍能影响的请求
从收到 CONSUMPTION_REQUEST 开始，Apple 给你大约 12 小时的时间来发送消费数据。其中三个字段为必填，两个为选填，还有一个偏好设置，而且现在它覆盖所有产品类型，不再局限于消耗型项目。
关于这个环节，我的建议很简短，因为别处已经把它讲得够透彻了：回应每一个请求；对那些产品明显已交付且被大量使用的情况予以拒绝；对真正的意外情况予以批准。一次善意的让步成本很低，但对每一笔退款都据理力争则不然，因为 Apple 会根据你的历史记录来加权判断。
没人提到的一个关键依赖是证据。你只能为能够证明的事情辩护。如果没人能回答七周前那笔购买"用户到底使用了多少"，再多的自动化也救不了你。无论用哪家供应商，这都是一个值得补上的数据建模缺口。
关于成本方面， 退款究竟会让你的应用损失多少收入一文做了详细测算，其中包括每个退款用户背后的获客支出。
环节三：把订阅用户赢回来
到了这一步，订阅收入保护就不再只是防御性的了。这也是 Apple 在过去一年里重新设计、让你更受益的领域。
召回优惠（Win-back offers）。这是 WWDC24 推出的新功能，适用于 iOS 18 及更高版本。你需要在 App Store Connect 中按订阅产品逐一配置，并设定资格条件：最短付费时长、距上次订阅的时间间隔，以及两次优惠之间 2 到 24 个月的等待期。之后分发工作由 Apple 完成，优惠会出现在客户的"管理订阅"页面、你的产品页面、个性化推荐中，偶尔还会出现在 Today 标签页的编辑推荐位。
这段值得读两遍：Apple 会把你的折扣展示给已流失的订阅用户，出现在你用邮件永远触及不到的地方。限制条件是：每个订阅最多 350 个优惠，每个应用商店（storefront）最多同时上线 5 个。在应用内，一旦用户符合资格，StoreKit 会触发 winBackOffer 消息，续订信息中的 eligibleWinBackOfferIDs 会显示用户可兑换的内容。Apple 的 召回优惠设置指南详细说明了资格字段。
促销优惠（Promotional offers）。每个订阅最多 10 个，自 iOS 12.2 起就已存在，需要你的服务器提供 JWS 签名。比召回优惠的工作量更大，但定向完全由你掌控，这在退款原因指向某个具体问题时（比如某个国家的定价问题）就很重要。
优惠代码（Offer codes）。可在应用内外兑换。这使它成为触达那些已退款并卸载应用的用户的唯一现实手段。其他人你都能在应用内触达，唯独这类用户不行。
延长订阅续订日期。在我看来，这是最被低估的一个方法。Apple 的服务端 API 可以让你 延后订阅用户的续订日期，可以是单笔交易，也可以批量操作。在发布版本出问题后，我们会把它用作一种善意补偿：有人就计费 bug 发邮件给客服，你给他延长一个月，几乎不花什么成本，效果却胜过任何优惠券。防止一笔退款，胜过挽回一笔退款。
有一个例外：如果有人是因为计费方面的意外而非产品本身而退款，不要用折扣去追着他。先把付费墙的文案修好，然后让他自己重新发现产品。 App Store 退款管理一文涵盖了这方面的运营要点。
环节四：会自行解决的流失
Apple 会对失败的扣款进行最长 60 天的重试，或者直到客户更新了银行卡信息或取消订阅为止。如果订阅在这段时间内成功续订，付费服务会从恢复当天起继续生效。
所以，看似已经损失的一部分订阅收入，其实从未真正损失，只是处于待定状态。有两件事会破坏这个过程：一是你从未开启的宽限期，二是一封实际上在暗示用户去取消订阅的催缴邮件。在花钱购买留存工具之前，先检查这两点。
不自欺欺人地衡量结果
没有按群组（cohort）归因的退款管理，只会产生看似可信实则荒谬的结论。
应将每一笔退款归因到原始购买发生的周期，而不是退款到账的周期，然后让这个群组数据充分成熟。月度套餐需要 30 到 45 天，年度套餐则需要更长时间，因为退款请求可能在数月之后才提出。
这也是订阅退款跟踪变得棘手的地方，也是大多数仪表盘悄悄"作弊"的地方。11 月被接受的一次召回优惠，实际上属于 8 月流失的那个群组。如果你的报表没有把这两者关联起来，那你的收入回收数字就是虚构的。
要追踪四个数字，而不是一个。
按群组划分的退款率。
在时限内得到回应的请求数量。
按退款原因拆分的已捍卫收入。
尚未解决的权益漏洞数量，这个数字应该趋近于零并保持在零。
如果仪表盘上只能放一个数字，那一定是漏洞数量。这是唯一一个只要不为零就明确说明出了问题的数字。
软件究竟能帮上什么忙
第二和第四个环节可以彻底实现自动化。第一个环节只需自动化一次，之后只需持续监控。第三个环节则依赖配置和判断，而判断这件事，没有任何工具能替你完成。
Refund Sensor 负责处理两个应用商店上的防御工作，在时限内用交易证据回应每一个符合条件的请求，并记录你保住了哪些收入。但它无法替你召回任何用户，也无法修复一个令人困惑的付费墙。这些事，只有你自己能做到。
参考来源
常见问题
按照我会尝试的顺序，共有四条途径：首先找出仍持有已退款交易访问权限的用户，并关闭其权限；其次在 12 小时内回应每一个消费数据请求；然后用召回优惠或促销优惠把流失的用户赢回来；最后检查计费重试和宽限期设置，因为有些流失其实从未真正发生。
不能直接撤销。Apple 有时会在客户发起争议后自行撤回退款，并发送 REFUND_REVERSED 通知。一旦收到该通知，就恢复用户的访问权限。这是一种你无需主动争取的收入回收方式。
召回优惠针对的是关闭了自动续订的已流失订阅用户，其资格判定基于付费时长以及距上次订阅的时间间隔。已退款的订阅会被视为已流失，所以通常是有效的。不过，还是需要配置好规则并加以核实。
权益查询。只需一小时的工作量，不需要任何供应商，也不需要发布新版本。在我跑过这个查询的每一款应用上，结果都不是零。
损失远不止退款金额本身。典型的退款率约为付费交易的 2% 到 5%。真正的成本还包括该用户背后的获客支出、如果你错过通知而产生的权益漏洞，以及因此被夸大的 LTV（这会导致你在获取下一个用户时支付过高的成本）。
不应该。修复漏洞本身是免费的，而且这其实是一个 bug。软件解决的是你没有回应的请求，这确实是个真实存在的问题，但不是你应该优先解决的问题。
