revenuecat-app-valuation

应用估值与出售

帮助创始人了解自己的应用可能值多少钱，以及应用收购的运作方式。以下框架摘自 RevenueCat 关于出售应用的指南，并补充了买家如何评估风险。尽可能根据用户自己的 RevenueCat 数据进行估算，而不是直接引用抽象的区间。

本主题有两条原则：

• 估值始终以区间和置信度呈现，绝不提供单一的保证数值。应用的最终价值取决于买家愿意支付的金额，而且不能保证任何价格下都能找到买家。
• 将这些内容视为一般教育信息，而非财务、法律或税务建议。若要进行评估、确定税务处理方式或制定交易条款，请告知用户咨询经纪人、律师或税务专业人士。

方法

估值分为四个步骤，按顺序进行。明确完成每一步。

1. 选择利润基数，并说明所选基数。
2. 选择该基数对应的倍数区间。
3. 根据证据确定应用在该区间中的位置。
4. 给出估值区间、置信度，以及可能影响估值的因素。

1. 选择利润基数

应用按利润倍数估值，而不是按收入估值。本技能中的所有倍数均为利润倍数。不要将倍数直接用于收入指标。

基数	倍数
月运营利润	12x–36x（宽泛区间），36x–60x（成熟订阅业务）
年运营利润	1x–3x（宽泛区间），3x–5x（成熟订阅业务）

MRR 和 ARR 仍然重要：它们是计算利润的营收基数，也是下文留存率、增长和收入集中度检查的输入数据。但它们不是估值基数。

如果用户知道收入但不知道成本，请询问成本。如果用户无法提供成本，请将假定利润率明确列为假设，并完整展示计算过程——“$200k ARR × 假定利润率 60% = $120k 利润 × 3–5x = $360k–$600k”——以便用户修正该假设。

所有者收益或雇人后的利润

有两种站得住脚的利润基数，但两者不能互换。选择其中一种，在回答中说明，并应用相应的倍数。

• 所有者收益——独立买家亲自完成相关工作后能拿到手的金额。销售所得减去现金运营成本，再加回一次性及非经常性成本。用于出售给个人买家的所有者自营应用。
• 雇人后的运营利润——为创始人目前免费承担的工作支付市场价后，应用能产生的收益。所有者收益减去替代这些工作的成本。适用于会为应用配备人员的工作室或投资组合收购方。默认采用此基数。

公开的 3x–5x 区间是雇人后的利润倍数：给出这一区间的收购方是承担运营成本的投资组合买家。

要估算替代成本，请询问每周有多少时间用于应用的工程、支持、营销和行政工作；目前有哪些人获得报酬、报酬多少；以及创始人是否打算在过渡期间继续留任。兼职维护所需的替代成本每月为数千美元；全职负责工程和用户获取的创始人则对应一份工资。请将其作为明确说明的假设，而非推导出的事实。

计算金额

从收益开始计算——即扣除销售税／增值税和商店佣金后的收入，而非总收入，因为 App Store / Play Store 费用已经扣除。通过 revenuecat-charts 中 revenue 图表的 get-chart-data 请求收益，并将 revenue_type 选择器设为 proceeds。然后扣除维持应用运行的直接开支：运营成本（服务器、客户支持、许可）、营销和用户获取支出，以及持续维护费用。再加回上述项目。

• 不要扣除利息或企业所得税——这些反映的是卖方的融资和税务情况，买方会以自身情况取而代之。收益中已扣除的“税费”是销售税／增值税；不要再额外扣除所得税。
• 用于开发_新_功能的成本通常不计入——这些成本投入的是未来利润，而非维持现有利润。每款应用的情况都不同，因此如果有部分开发成本应计入该金额，请注明。
• 以过去 12 个月（TTM）的数据作为基准。

然后将最近两个完整季度的利润年化，作为运行率敏感性分析。如果它与过去 12 个月的基准相差超过约 20%，请同时列出两者：

按过去 12 个月利润 $100k 计算，估值范围为 $300k–$500k。按当前 $140k 的运行率计算，采用相同倍数，估值范围为 $420k–$700k。买方会更倾向于以过去 12 个月的数据为基准，并要求你证明运行率能够持续——持续增长是支持估值上限的理由，而不是提高基准的理由。

这同样适用于两个方向：对于收入下滑的应用，买方会试图将估值推向运行率数字，而卖方则会以过去 12 个月的数据进行辩护。无论哪种情况，都要展示两者之间的差距。运行率敏感性分析并不意味着可以将短期峰值年化——持续两个或更多季度的变化才是趋势；上线后的单月强劲表现或季节性峰值则不是。将某种变化称为趋势之前，请查看图表中的 annotations。

2. 选择估值区间

RevenueCat 发布了两个范围，它们并非同一个范围——分别描述不同层级的应用：

• 大众市场经验法则：应用的售价通常为每月运营利润的 12x–36x（≈ 年利润的 1x–3x）。这个范围涵盖整个市场，包括较新或用户流失率较高的应用。有些应用的售价是其利润的很多倍，也有些应用根本卖不出去。
• 成熟订阅业务底线：对于已验证、风险较低的订阅业务，严谨的买方会以年度运营利润的 3x–5x（≈ 月利润的 36x–60x）为基准。示例：一款年运营利润为 $100k 的应用，按 3–5x 计算，价值约为 $300k–$500k。

这两个区间首尾相接，仅在年度 3x／月度 36x 处重合。不要将两者取平均，也不要声称可以用单一数字协调这两个区间。

成熟订阅阶段需要数据佐证，而非只看应用年龄

是否符合条件，取决于能否观察到一个完整的续订周期，而这通常在应用发布未满两周年时就能看出来。请检查以下三项：

• 订阅收入占主导——约 70% 以上的收入来自订阅。
• 主导套餐周期的续订周期已完成。查看 subscription_retention 或 cohort_explorer：以年订阅为主的应用，需要观察超过第 12 个月的用户群组，这样数据中才包含首次续订。以月订阅为主的应用，需要观察超过首月流失高峰之后的用户群组——涵盖多个续订周期，而不只是一个。先按收入查看年订阅与月订阅的占比，因为这决定了适用哪个门槛。一款上线 18 个月、以年订阅为主且第 12 个月用户群组数据完整的应用符合条件；一款上线 3 年、但刚推出年订阅方案的应用则不符合。
• 留存曲线已趋于平缓。留存率应先下降，然后在至少连续两个用户群组中趋于稳定。如果曲线在最后一个观测周期仍大幅下滑，那么无论历史数据有多长，证据都不完整。

任意一项不通过，都应采用大众市场区间。说明未通过哪项检查，以及需要什么条件才能通过——通常是一个具体的月数。

通过门槛后，应用年龄不再是影响因素：估值倍数由用户群组数据决定。

非订阅收入占主导的应用

RevenueCat 目前没有针对非订阅收入占主导的应用发布或推荐估值洞见。如果有人询问的应用并非以订阅为主，请勿提供估值。

3. 在区间内定位

区间是起点；这些因素决定应用在区间内的具体位置。为每个因素评为强、中性或弱，并说明依据是什么。

因素	强	弱	查看位置
留存率（权重 2 倍）	流失率／留存率位于同类产品前 30%，曲线平稳	位于后 30%，或曲线仍在下滑	get-benchmarks（月流失率）、subscription_retention
发展趋势	同比增长 25% 以上，且持续两个或更多季度	同比下降 10% 以上	revenue（收入），最近连续 12 个月与此前 12 个月对比
变现能力	实际 LTV、试用转化率和付费转化率位于前 30%	位于后 30%，或已无定价空间	get-benchmarks、conversion_to_paying
分发	渠道持续增长，付费获客回本表现良好	依赖外部渠道带来的增长，或付费获客无法回本	询问用户
集中度	在商店、地域和 SKU 方面均较为多元化	某项依赖超过下方阈值	按 store、country、product_id 对 revenue 分段
可转让性	运维负担低、文档齐全、商店账户可转让	依赖创始人、缺少文档、转让受阻	询问用户

直接使用 get-benchmarks 的 percentile_bucket：70 及以上为强，30–70 为中性，低于 30 为弱。 它已考虑反向指标，因此流失率的高百分位代表低流失率。is_eligible_for_benchmarking: false 的行置信度较低——将其评为中性并说明原因。

然后确定位置：

• 强项净多出两项或更多，且没有弱项——位于区间上三分之一。
• 大致均衡——位于中间三分之一。
• 弱项净多出两项或更多——位于区间下三分之一。

还有一些因素会限制买家愿意支付的价格：收入下滑、可能妨碍应用转让的问题、财务记录不齐全、集中度（见下文）。提及所有适用因素。

展示评分表，不要只给结论。“留存率位居同类产品前四分位数，年同比增长 30%，但 90% 的收入来自一个国家”才是完整的答案；数字只是对结论的概括。

解读各项因素

• 留存率 / 订阅者黏性——这是产品与市场契合度和未来现金流的最强信号，也是影响倍数的最大杠杆，因此权重加倍。什么算「良好」取决于类别：买家提到的健康年订阅留存率从约 25% 到 70% 不等。应与应用所属类别的基准比较，而不是套用统一数字；同时要准备好解释早期流失情况（约 30% 的订阅会在首月取消），并证明后续 cohort 趋于稳定。

• 变现空间——买家会把变现不足视为加分项：已有经过验证的变现方式，且有明确的增长空间（定价、优惠、套餐组合）。

• 分发渠道的持久性——应将获客渠道视为质量层级，而不是偏好：

  • 复利型（最强）：自然 ASO、SEO、品牌和口碑。
  • 可租用型：付费用户获取。要检查回本周期，而不只是规模。
  • 借力型（最弱）：UGC、病毒式传播循环、由网红和算法驱动的增长、单一创作者、应用商店推荐。应大幅折价，并询问如果明天这些渠道停止，安装量会如何变化。

  买家对自然流量与付费流量的占比确有不同偏好（提及的偏好从 100% 自然流量，到 50/50，再到 75/25 付费/自然流量不等），因此，有理有据的组合胜过教条式选择。

• 集中度——查看过去 12 个月中，按 store、country 和 product_id 划分的收入占比最高细分项：

  • 平台 / 应用商店。仅面向 iOS 很常见，单独来看只会造成轻微折价。
  • 地区。一个国家的收入占比超过约 70%，会形成实质性上限。
  • SKU / 产品。一个产品的收入占比超过约 70%，意味着业务依赖单一价格点。
  • 除图表所示之外：单一流量来源、单一集成，以及对于 B2B 形态的应用，由少数几个账户贡献大部分收入。

• 技术基础设施——架构清晰、运维负担低、文档完善，能够降低感知风险，并且在可转让性评分中占据主要部分。

评分表之外的因素

这些因素会影响交易，而非应用在其估值区间中的位置。应提出这些因素，但不要将其纳入估值区间：

• 战略 / 投资组合契合度——最高价格往往来自最能发现协同效应的买家。
• 创始人参与度——大多数买家认为创始人在过渡期内继续参与是加分项。拥有内部团队的大型工作室是例外。
• 交易结构——报价形式包括现金（最常见）、股权或业绩对赌。约三分之二的报价为纯现金交易。现金交易通常在成交时支付约 50%，其余部分在随后 6–12 个月内支付。

4. 给出区间和置信度

按以下形式呈现结果：明确列出利润基数 × 倍数下限至 × 倍数上限、在区间中的位置及理由，然后给出置信度。

数据稀少或波动较大、各项因素相互矛盾、若干输入由用户提供且无法核实，或收入中非经常性收入占比较大时，置信度较低。如果有 12+ 个月的完整干净数据、流失率低、已完成一个续订周期且收入多元化，则置信度较高。给出宽而诚实的区间，胜过给出无法自圆其说的窄区间。

根据用户的 RevenueCat 数据估算

如果用户想了解自己应用的估值，先获取他们的实际指标。

• 使用 revenuecat-charts 获取上述步骤所需的数据。优先查看：收益（过去 12 个月及按季度统计）、按群组划分的订阅留存率、月流失率、试用转化率和付费转化率、ARPU、年度与月度套餐占比、实际 LTV，以及按应用商店、国家和产品细分的收益。
• 通过 get-benchmarks 对照类别基准（实际 LTV、试用转化率、初始转化率、付费转化率、月流失率、退款率）。按照步骤 3 的说明，将百分位数纳入评分卡。
• RevenueCat 不提供获客成本数据，因此无法单独计算 CAC、LTV/CAC 或回本周期。没有用户提供的获客数据时，不要给出基于 CAC 的数字。
• 使用 revenuecat-charts 将用户引导至相关图表（例如 MRR、流失率、订阅留存率），让他们查看估值所依据的数据。

RevenueCat 中完全没有提供若干输入项。请一次性询问这些信息，而不是逐项询问：

输入项	用途
运营成本（服务器、支持、工具、UA）	利润基数
创始人和团队投入的时间，以及谁领取报酬	加回项和替代成本
按广告网络划分的广告收入	评估非经常性收入流
渠道占比、UA 支出、回本周期	分发渠道的稳定性
运维负担、文档、可转让性	可转让性及严格上限

准备出售、寻找买家和谈判

如果用户正在准备实际出售，请总结相关内容，并引导他们查看完整文章了解详情：

• 他们能出售应用吗？大多数 App Store 应用都可以在开发者账户之间转让；少数应用不可以（例如，应用内购买产品 ID 冲突、某些沙盒化 Mac 应用、Apple Arcade 应用），这种情况下则需要转让整个开发者账户。请引导他们查看 Apple 的应用转让标准以确认。
• 与买家接洽前的准备：整理清晰且经过核对的财务数据，明确留存率和增长情况，确保指标整洁、产品和基础设施易于交接，并准备好交接文档。
• 寻找买家：既有交易市场和经纪商（例如 Flippa、AppFlip、App Business Brokers），也有直接收购方；熟人引荐通常比陌生外联效果更好。
• 谈判：首份报价往往会压低价格。建议用户就实际交易寻求独立的法律和财务建议。

引用来源

回答应以 RevenueCat 自己发布的资料为依据，并注明出处。以下两篇文章是主要来源：

• “如何出售你的移动应用” — https://www.revenuecat.com/blog/growth/how-to-sell-an-app/
• “应用买家真正想要什么：来自 10 位领先收购方的见解” — https://www.revenuecat.com/blog/growth/guide-to-selling-apps/

将两篇文章作为已发布的估值区间、留存率范围、渠道偏好占比和交易结构数据的出处。因素评分卡、集中度阈值、加回项处理方式以及非经常性收入的处理方式属于一般市场惯例，而非 RevenueCat 的研究结果——应将其表述为买家的评估方式，不要将其归因于 RevenueCat 的文章。

如需更深入或更新的详情，请获取这些文章，或搜索 RevenueCat 博客（出售和收购相关内容）以及 State of Subscription Apps 报告。如需将用户的应用与同类应用对比基准，请使用 get-benchmarks。