如何诚实地计算数据产品的利润率

一款数据产品在展示时可以拥有诱人的毛利率——直到某个大客户要求实时更新的数据、定制化的工作流、审计追踪，以及来自真正理解系统的人的答复。这时，电子表格才会揭示出演示环节掩盖的真相：这家公司并非以软件的经济模式在销售软件，而是在销售一种基础设施成本异常高昂、部分自动化的服务。

要正确计算数据产品的利润率，首先要把交付可用客户结果所需的每一项经常性成本都当作真实成本对待。不仅是云端支出，不仅是 API 调用费用。人力投入、可靠性负担、数据权利，以及针对特定客户的例外处理，同样需要计入。如果收入增长的同时这些成本也几乎同步增长，那么把这个产品称为“可扩展”并不会让它真的具备可扩展性。

利润率的公式很简单，输入项却不简单

在账户层面，毛利率的计算公式是：

毛利率 =（经常性收入 - 服务成本）/ 经常性收入

算术本身不是团队失败的地方。他们失败的原因，是把“服务成本”定义得过于狭窄，使这个答案变成了融资时的道具，而非真正的管理工具。

对于传统软件产品而言，直接成本通常包括托管费用、第三方基础设施、支付处理费和客户支持。数据产品的构成则更复杂。它可能需要摄取第三方数据、支付按使用量计费的模型或数据增强费用、运行昂贵的数据转换、维护数据质量控制机制，并在客户获得价值之前吸纳大量的实施工作。

正确的问题不是“维持应用程序在线运行需要多少成本？”而是“我们要可靠地产生客户续约所依赖的那个结果，需要付出多少成本？”这两个数字常常大相径庭。

举例来说，一家销售实时供应链情报服务的公司，其仪表盘的托管成本可能并不高，但源数据接入、规范化处理、异常处理、模型推理，以及置信度下降时的分析师复核，都会带来不小的开支。如果只计算仪表盘账单而排除其他一切，得出的利润率会非常漂亮，但这个运营模型毫无用处。

按成本行为来计算数据产品利润率

不要把所有支出都笼统地归入一个不透明的类别。应该根据引发成本上升的原因来对成本进行分类。这种区分能告诉你，规模扩张究竟会改善这家企业，还是会暴露它的问题。

直接可变成本

这类成本随客户使用量、数据量或所需产出而增加。它们包括按记录计费的数据授权费用、推理与 API 费用、与处理量相关的计算资源、存储与出站流量费用、身份验证费用，以及交易层面的服务费用。

可变成本本身并非坏事。只要定价能够充分捕获价值，且单位经济模型会随着规模扩大而改善，一个拥有使用量成本的产品同样可以拥有健康的利润率。但如果按使用量计费的成本结构搭配的是固定定价，这就是一处悄悄流失利润的漏洞。在试点阶段，由于使用量受限，团队也还满足于终于有人愿意用这个产品，这个问题往往不易察觉。

应按照与客户价值相对应的单位来衡量单位可变成本：每个受监控资产、每次决策、每条经过验证的记录、每个工作流，或每个活跃席位。“按客户计算”通常过于粗略，无法诊断出真正的问题。

直接固定成本与半固定成本

有些交付成本不会随使用量清晰地波动，但运行产品仍离不开它们：基础云资源承诺、数据平台工具、安全监控、数据质量基础设施，以及支持生产系统运转的值班职能。

分摊这些成本时要格外谨慎。一家年轻的公司不应因为某个财务类别把它们称为“管理费用”，就假装这些成本不存在。但同时，也不应把它们分摊得过于激进，以致早期阶段的毛利率变得毫无意义。可以采用两种视角：一是共享交付基础设施前的贡献毛利率，二是计入共享基础设施后的完全摊销毛利率。投资人和运营者都需要这两个视角。

贡献毛利率回答的问题是：新增一个客户在经济上是否具有吸引力。完全摊销毛利率回答的问题是：这家企业是否能够支撑起它宣称已经建成的那个平台。

人力交付成本

这正是许多人工智能和数据公司在不经意间开始自我欺骗的地方。实施工程师、分析师、数据运营人员、客户成功专员和技术支持人员，往往因为归属于不同的部门，而被记入毛利率计算之外。这样的会计惯例本身可以是合理的，但在商业层面上对此视而不见则不合理。

如果客户需要经常性的分析师复核才能信任产出结果，那么这项复核工作就是交付的一部分。如果每一次企业级部署都需要两个月的定制化数据映射工作，那么这项实施投入就应纳入账户经济模型——无论是按合同期限摊销，还是作为入职成本单独追踪。

这里确实存在需要判断的空间。早期的客户工作可能属于产品探索，而非永久性的服务义务。检验的标准是：随着产品成熟，这项工作是否会消失。如果同样的定制工作在不同账户之间反复出现，那就不是“学习”，而是产品披着服务的外衣。

建立账户层面的服务成本模型

组合层面的平均数据对董事会报告很有用，但对诊断问题却很危险。一个高使用量的客户、一次困难的系统集成，或一份定价过于优厚的历史合同，都可能扭曲整体画面。应先在账户层面建立模型，再进行汇总。

对于每个账户，需要记录合同约定的经常性收入、使用量、直接基础设施成本、第三方数据与模型成本、分摊的支持费用、持续运营成本，以及摊销后的实施成本。如果客户要求专属环境、特殊的合规控制，或独有的数据源，应将这些成本直接归入该账户，而不是隐藏在共享成本池中。

然后计算三项指标：

账户贡献毛利率展示的是收入减去直接可变交付成本。

账户毛利率在前者基础上加入该账户分摊的经常性支持、运营及交付基础设施成本。

客户终身贡献考虑的是预期留存期内的毛利润，再减去获客与入职成本。

这些指标能够避免一个常见的错误：为拿下某个大型企业客户而欢欣鼓舞，却没意识到这份合同只有在没人计算维系其运转所需人力成本的情况下才是盈利的。当服务成本状况在签约后反而变糟，收入本身并不能证明什么。

为昂贵的真相定价，而不是为廉价的演示定价

一旦成本变得清晰可见，定价就会成为一个战略问题，而不再是一厢情愿的行为。市场可能无法容忍那种要覆盖无限量高成本产出的定价方式。这并非定价页面上的问题，它可能表明底层的产品架构或目标客户本身就选错了。

应使用能够紧密追踪价值与成本的定价指标，从而保住利润率。如果每新增一个受监控实体都会产生实质性的数据与推理开支，就应按实体、按用量档次或按工作流来定价。如果价值创造来自高风险决策而非原始使用量，那么“平台费加与结果挂钩的容量费”的组合可能更为合理。

当成本驱动因素是交易量、数据刷新次数或模型调用次数时，应避免只按席位收费。按席位定价之所以被频繁使用，正是因为人们对它太熟悉，而这种熟悉常常被用来掩盖经济模式上的错配。熟悉并不能替你支付云端账单。

有些情况下，你可能会有意接受较低的利润率。如果补贴入职成本能够带来可复用的产品能力、有说服力的可参考案例，或可复制的垂直行业打法，那么设计合作伙伴关系就足以证明这种补贴是合理的。但要把这种补贴明确化、设定时限，并作为一项投资获得批准。不要把它标记为正常的毛利率，然后指望后来的客户表现得更好。

在市场检验之前，先对模型进行压力测试

一个可信的利润率模型，不能依赖平均使用量、完美的数据质量，或客户完全按照采购部门承诺的方式行事。要运行下行情景测试。

如果客户使用量翻倍却不升级套餐，会发生什么？如果数据源提供商上调价格，模型提供商调整定价，或监管要求延长数据留存期限，又会发生什么？如果系统的置信度下降，需要增加人工复核，情况会如何？如果仅仅几个合理的运营变化就能抹去毛利润，那么这家公司还没有找到产品与市场的契合点，它找到的只是一种暂时的会计安排。

同时也要按客户细分来检验利润率。较小的客户可能要求不那么高，却往往带来不成比例的支持负担。大型企业客户可以带来出色的合同价值，但也会附带安全、系统集成和治理方面的要求，消耗大量的工程资源。这两类客户都不必然更优，答案取决于交付模型是否能够被标准化。

对投资人而言，利润率的尽职调查应当与留存率直接关联。一个毛利率很高但续约率疲弱的数据产品仍然是脆弱的。而一个毛利率较低但留存率强劲的产品，如果这家公司能够找出哪些成本会随着自动化、更优的数据协议或更收窄的定位而下降，那么它就值得投入改善。真正的问题在于，这条改善路径在运营上是否可信，而不是某份演示文稿里是否画出了一张“未来状态”的利润率图表。

把利润率当作一项产品决策

数据产品的利润率并非只由财务部门决定。它由产品范围、架构、数据采购方式、自动化门槛、实施设计，以及是否愿意拒绝那些会把平台变成代理服务机构的客户请求所共同塑造。

最强大的公司，会在合同签署之前，就让产品团队和商务团队清楚地看到利润率的构成。他们知道哪些功能会带来经常性的交付负担，哪些系统集成可以被复制，哪些客户应该支付更高的价格，哪些客户应该被拒绝。这种自律远不如一场令人惊艳的演示那样光彩夺目，但正是靠着这种自律，深厚的技术能力才能转化为值得信赖、能够持续创造收入的基础设施。

如果一个模型只有在排除成本、使用量维持在异常低位、客户从不寻求帮助的前提下才能运转，那就不要把它称为高利润率的数据产品。应如实称之为：一个尚未经受部署检验、正等着被推翻的假设。

您的领导方式在哪里有效，又在哪里正在消耗公司？

这个博客讨论的多数问题，最终都回到创始人如何经营公司这一点上。藤架领导力诊断把它拆成六个维度共24道行为锚定题：约12分钟，即时出结果，自助版免费。

开始藤架领导力诊断 →

想了解兼职高管或顾问合作？预约探索性通话 →