RevenueCat 很擅长回答"这个 App 卖了多少"，但回答不了"这个 App 赚没赚钱"，因为它看不到这个 App 运行要花多少钱。
本文说明怎样从 RevenueCat 给出的数字算到每个 App 的利润，以及两个会让结果偏高或偏低的常见错误。
RevenueCat 后台已经告诉你什么
收入图表可以显示三个层级。按 RevenueCat 的收入图表文档：
| 指标 | 已经扣掉了什么 |
|---|---|
| Revenue（收入） | 退款和向下调整的付款 |
| Revenue (net of taxes)（税后收入） | 再扣掉商店估算的税费，例如增值税 |
| Proceeds（到手收入） | 再扣掉商店估算的抽成或手续费 |
Proceeds 最接近你实际能从商店收到的钱。RevenueCat 说明税费和抽成都是估算值，依据购买日期、你是否加入小型企业计划以及销售所在国家来计算（税费与抽成）。
所以算利润的起点是 Proceeds，不是收入。
RevenueCat 看不到什么
你在商店之外付的钱，RevenueCat 都看不到：
- 服务器、数据库、存储和流量
- AI 模型 API，往往是新 App 增长最快的成本
- 邮件、数据分析、崩溃报告和错误监控
- 设计、开发和推广工具
- Apple 开发者计划年费、域名以及其他按年付的费用
有些成本只属于一个 App，很多则是共用的：一台服务器、一个设计工具、一个开发者账号，供你所有 App 使用。
一步步算
每次只算一个月、一个 App。
- 取这个 App 当月的 Proceeds。 如果你一个 App 对应一个 RevenueCat 项目，就是这个项目当月的 Proceeds。
- 减去这个 App 的直接成本。 只因为这个 App 才存在的成本：它的 API 用量、它自己的服务器、它自己的订阅。
- 减去它承担的共同成本。 每笔共用账单按一个说得清的规则分摊，例如平均分、按收入占比分，或者自己定比例。共同成本分摊指南比较了这几种方法。
- 剩下的就是这个 App 当月的贡献利润。 再除以收入，就能比较大小不同的 App。
以 10 月为例，假设没有销售税：
| 项目 | 金额 |
|---|---|
| 收入 | $1,900.00 |
| 商店抽成 15% | −$285.00 |
| Proceeds（RevenueCat 显示的数字） | $1,615.00 |
| AI API 用量 | −$60.00 |
| 它自己的数据库套餐 | −$25.00 |
| 分摊的共用服务器和工具 | −$48.00 |
| 贡献利润 | $1,482.00 |
在收入图表上它是一个 $1,900 的 App。扣掉运行所需的一切之后，它贡献 $1,482，占收入的 78%。
两个会让结果失真的错误
商店抽成扣了两次。 Proceeds 已经扣过抽成。如果你再把"Apple 15%"记成一笔成本，这个 App 看起来就会比实际少赚约 15%。要么从 Proceeds 开始、不再扣抽成，要么从收入开始、只扣一次。边际贡献计算器专门有一个手续费比例字段：输入 Proceeds 时把它设为 0%。
月份边界不一致。 月末最后一天晚上的续订，按不同时区可能算在这个月，也可能算在下个月。收入和成本用同一个时区；MarginDeck 按 UTC 记录同步的月份。按年付的费用也要统一处理，真实成本指南介绍了两种常见做法。
每个月都算，不用表格
MarginDeck 在你的 Mac 上做这件事。它通过只读 OAuth 连接 RevenueCat，申请的是项目和概览指标的读取权限，然后导入每个项目当月的 Proceeds。保存之前，你先决定每个项目对应哪个产品。之后它会减去你记录的成本和共同成本分摊，按月显示每个产品的贡献利润。
月度历史从你第一次同步成功开始；MarginDeck 不会从 RevenueCat 补拉更早的月份。你的记录保存在 Mac 的本地数据库里。