用量计量与定价：工程与财务的视角

简介

基于使用量的定价和混合定价模式很少是静态的。当定价逻辑被硬编码后，对任何等级或信用额度的一点微调都会变成一个工程工单。这对财务部门来说效率低下，对开发人员来说也令人沮丧。那么，谁应该负责使用量计量以及基于此构建的定价机制呢？让我们理清这个问题。

为何定价调整如今如此频繁

定价已不再是“设定后就无需再管”的决策。咨询公司 hy 与 OMR Reviews 联合发布的《SaaS 与 AI 定价报告》援引 Growth Unhinged 的数据指出，过去一年中，四分之三的美国软件公司调整了定价。这变化相当大。

定价模式也在发生转变。在hy对180家软件公司的调查中，37%的企业已采用基于使用量的定价模式，59%的企业则结合了多种定价指标，例如按用户计费与API调用量计费并行。加上积分机制、开展定价实验、调整套餐组合等因素，变化已成为常态而非例外。

定价逻辑为何最终由工程团队主导

这通常是无意中发生的。早期，开发人员会将某个指标硬编码进去：统计API调用次数，应用费率，将总金额发送至发票。既然能正常运行，就没人质疑。

随后定价机制开始演变。新增一个价格档位、免费配额或不同的超额费率，就意味着有人需要提交工单，等待冲刺周期中的空档，并祈祷此次发布不会影响账单生成。前置周期不断延长，每次发布都伴随着一定风险。财务部门最终只能在自己无法掌控的队列中等待。

混合定价模型会加剧这一问题。价格包含的组成部分越多，变更就越可能隐藏在代码的各个角落。

工程团队主导定价的代价

这些成本是真实存在的，即使没有电子表格来证明。

• 缓慢上线：定价方案可能因产品开发工作而搁置数周。
• 错误：深埋在代码中的逻辑让财务团队难以理解，因此错误往往会在发票上显现。
• 财务盲区：如果财务部门无法了解某个数字的计算过程，纠纷的解决时间就会延长。
• 机会成本：工程师将时间用于维护计费代码，而非开发产品。

我的观点是：如果价格变更需要代码部署，那么定价的调整速度将取决于发布日程，而非市场需求

财务部门应负责什么，工程部门应负责什么

职责划分并非非此即彼。应根据决策类型进行划分。

工程团队负责事件监控、数据管道以及源头使用数据的准确性。

财务和产品团队负责指标定义、定价点、套餐组合以及信用额度。

这里有一个简单的检验方法：如果变更涉及“记录什么”，则归工程团队负责；如果涉及“如何将记录的使用数据转化为收入”，则归财务和产品团队负责。例如，决定某套餐包含1,500次API调用而非1,000次属于定价决策；确保每次调用仅被准确记录一次则属于工程决策。

定价变更的治理

若在缺乏防护措施的情况下移交控制权，将导致混乱。以下是一些通用的最佳实践，不与任何特定工具绑定：

• 审批流程：任何变更上线前，必须获得财务和产品团队指定人员的签字确认。
• 测试：上线前需预览对实际使用数据的影响。
• 版本管理：对每项定价配置进行版本管理，以便进行版本对比或回滚。
• 生效日期：明确变更的生效时间，以及周期中途已记录的使用量应如何处理。
• 审计日志：记录谁在何时对哪些内容进行了修改。

不妨将其视为定价领域的代码审查。没有人会在没有第二双眼睛审核的情况下发布代码，定价也理应得到同样的重视。

财务主导定价的先决条件

财务部门无法掌控其无法信赖的事物。首先需要奠定三个基础。

干净的使用数据。重复或缺失的事件会破坏基于这些数据设定的任何价格。

统一的指标定义。如果产品团队和财务团队对“活跃用户”的定义不一致，最终将由账单来裁决争议，而结果绝不会令人愉快。

可靠的来源。使用数据通常存储在数据仓库中、API 背后或文件中。为每个指标选择一个记录系统并坚持使用。

转移定价所有权前需考虑的问题

召集首席财务官、产品负责人和工程负责人，共同探讨以下问题：

1. 去年我们进行了哪些定价变更，每项变更的上线耗时多久？
2. 每个计费指标是否都有一个公认的定义？
3. 财务部门能否追溯使用量数据如何转化为发票明细项？
4. 谁负责批准变更，以及在变更上线前如何进行测试？
5. 使用数据存储在何处，谁负责确保其准确性？

如果其中有两三个问题无法回答，那就是你们的起点。

无需重建计量系统即可调整定价

此时工具就能派上用场。根据 Zenskar的“使用量计量”页面介绍，团队可以用通俗语言定义可计费指标，让 AI 编写聚合逻辑，或者针对复杂逻辑编写自定义 SQL 语句。使用量数据可从 Postgres、Athena 和 MySQL 等数据源提取，通过 API 推送，或以 CSV 格式上传。同一指标可在不同产品、合同和明细项目中重复使用。

对于所有权而言，关键在于基于使用量的计费软件应允许分级、超额收费和计费周期独立于使用量进行调整。计费逻辑还可以在计费周期中途进行修改，而不会中断数据管道。单一指标即可支持不同合同中的多种定价模型，在定价不断演变的同时保持计量稳定。

结论

最健康的模式是共享模式。工程团队负责确保使用数据的准确性和数据流的畅通；财务和产品团队则在明确的治理框架下，共同决定这些数据的价值。目前，您的工程待办事项队列中正等待着哪项定价变更？

关键要点：

• 硬编码的定价机制会导致每次调整价格档位或积分时，都必须提交一个工程工单。
• 按决策类型划分职责：工程团队负责使用数据的采集和准确性，而财务和产品团队负责指标定义、定价点、套餐组合及信用额度。
• 首先建立防护机制：审批流程、测试、版本控制、生效日期以及审计追踪。
• 由财务主导的定价需要干净的使用数据、经协商一致的指标定义，以及每个指标仅有一个记录系统。
• 利用“五项移交前问题”来确定您的起点。
• 选择能够支持在不重建计量系统的情况下调整定价的工具。