现代收入平台的参考架构

大多数收入技术栈从来都不是被设计出来的，它们是逐渐堆积形成的。CRM 最先出现，然后是营销自动化，接着是一个销售互动工具、一套 CPQ 系统、一个数据仓库、三家数据增强供应商，以及一层叠加在最上面的 BI 层。每一个都携带着自己那份客户数据的副本，自己对"客户"这个概念的理解，以及自己对一笔交易何时才算真实存在的看法。这套技术栈在技术上是能运转的，但从架构上看却是一团糟，因为每一次新的集成，都增加了一个真相可能出现偏差的地方。

一个现代的收入平台，会把重心翻转过来。CRM 不再是枢纽，数据才是枢纽，而各个应用则变成可以插入其中、也可以被替换掉的参与者。接下来要讲的，就是这种模式的参考架构：各个层级、它们之间的契约，以及那少数几个决定这套东西是会不断复利增值、还是会被集成债务压垮的关键决策。文中链接的文章会对每一层做更深入的探讨。

五个层级

一套持久耐用的收入架构，会把关注点拆分为五个层级，每一层都有一个明确的职责，以及与相邻层之间干净的接口。

摄取与连接。 从系统记录中拉取数据、并向其推送数据的连接器：CRM、营销自动化、产品分析、账单、支持、合作伙伴系统。设计目标是幂等性和可重放性。每一个数据源都应该能够被重新摄取而不产生重复数据，每一次同步失败都应该能够被恢复，而不需要有人在某个周六手动清理。

统一数据层。 客户、联系人、商机、活动和收入事件的一份带版本管理的统一表示。实体解析发生在这里，规范化的定义存在于这里。当这一层缺失时，各个团队会在每一个下游工具中各自重建它，而且往往做得很糟糕，每一次重建都与其他的相互矛盾。

建模与智能。 归因、打分、健康度指标、预测、下一步最佳行动逻辑，全部基于统一数据计算得出。这是事件转化为决策的地方。

回写与激活。 把洞察路由回人和自动化真正工作的地方：CRM 里的任务、广告平台里的受众、Slack 里的提醒。

治理与可观测性。 访问控制、血缘追溯、数据质量监控、审计。这一层横切其他四层，而不是与它们并列。

关键的纪律在于边界。当建模逻辑渗透进摄取环节，或者治理是在激活功能上线之后才被补建的，各层就不再是可以独立替换的了。架构就会像混凝土一样凝固，你又回到了逐渐堆积的老路上。

数据层是重中之重

最重要的一个决策，是你拥有的到底是一个真正共享的数据层，还是一张点对点同步的网络。点对点在早期感觉更快：把工具 A 连接到工具 B，然后上线。但连接数量会呈平方级增长：n 个系统最多可能需要 n(n-1)/2 个集成，每一个都有自己的字段映射、同步节奏和故障模式。在十个系统的规模下，这可能意味着多达四十五条脆弱的链路，以及一个了解它们全部如何运作的运维人员。

一个共享数据层能把这个数字压缩到 n 个连接。每个系统只需与这个枢纽集成一次，实体解析和规范化定义只存在于唯一一个地方。我们在为什么共享数据层胜过点对点集成一文中详细梳理了这种权衡，但架构上的启示很简单：数据层是承重墙，其他一切都是装修。

而这堵墙的牢固程度，完全取决于流入它的数据质量。一旦源数据不一致，实体解析就会崩溃，这正是为什么RevOps 数据治理应该被纳入架构讨论，而不是被归入打扫卫生一类的杂务。

层与层之间的契约

各层之间通过明确的契约进行沟通：不会悄悄改变的模式和语义。一个能够经受住组织重组或供应商更换考验的平台，会把这些契约当作头等大事来对待。

模式契约定义了客户或商机的形状。当一个上游字段消失时，下游模型应该大声地报错。而另一种情况，是一个悄悄出错的数字混进了董事会的幻灯片里。

语义契约定义了含义。"创建的销售管道"无论来自 CRM 还是从产品信号推断而来，都必须意味着同一件事。归因主干本质上就是一项在各个触点之间强制执行语义契约的工作。

新鲜度契约定义了时效性。并非每一项指标都需要实时更新，强行做到实时既昂贵，往往还会适得其反。我们在实时 vs. 批处理：收入数据的新鲜度何时真正重要一文中讲解了如何做出这个判断。

契约，正是让你能够在不重写整个平台的情况下更换供应商的关键。一个应用变成了一个满足某项契约的东西，当有更好的选择出现时，你可以随时离开它。

两个拓扑决策

数据仓库原生还是应用原生。 智能计算是运行在你现有的数据仓库之上，还是在某个供应商的黑箱内部？这决定了谁拥有计算资源、原始数据和可扩展性，而且很难逆转。我们在数据仓库原生 vs. 应用原生的收入工具一文中梳理了这种权衡。

边界的开放程度。 一个API 优先的平台会以编程方式暴露每一项能力，这意味着回写层和任何自定义的激活路径都由你自己来扩展。干净地读取数据只是一半，安全地把数据写回去是另一半，而回写层值得拥有自己的一套纪律：把洞察路由到行动系统之中，同时不产生循环，也不覆盖代表一小时前刚做的编辑。

在这一切之下，治理与访问控制决定了一个统一系统究竟是资产还是负债。统一收入数据会提高每一个权限决策的风险，因为一次失误的影响半径，如今就是整个技术栈。

端到端地读懂它

数据源流入一个统一的层。智能计算只需进行一次。洞察被回写到人们工作的系统中。治理监视着整条路径。每一层都是可替换的，每一份契约都是明确的，因此这套技术栈会随着你添加新系统而变得更有价值，因为每一个新的数据源都在丰富同一个规范化模型，而不是催生又一个孤岛。

这正是编排与"集成剧场"之间的区别。编排意味着平台能够在整个买家旅程中做出协同一致的决策。集成剧场则意味着数据在工具之间移动，而人类依然要在电子表格里手工拼凑出意义。像 Revnewo 这样的平台正是围绕这种分层的、以数据为中心的模式来构建的，因为根据我们的经验，这是唯一能够不断复利增值、而不是逐渐衰败的模式。

关键要点

• 数据居于中心。CRM 变成了围绕统一层的众多参与者之一，其中任何一个都可以被替换。
• 五个各司其职的层级：摄取、统一数据、建模、回写、治理。保持边界清晰，否则各层就不再是可替换的。
• 一个共享数据层能把平方级的集成债务转化为线性的连接，并把规范化定义集中在一处。
• 明确的模式、语义和新鲜度契约，正是让供应商可被替换的关键。
• 数据仓库原生还是应用原生，以及 API 的开放程度，将在未来数年内塑造所有权和可扩展性。要有意识地做出决定。

如果你的技术栈是逐渐堆积形成的，而不是被设计出来的，那么把它对照这五个层级进行梳理，是一个成本很低的第一步。这也是一个有用的视角，用来判断像 Revnewo 这样的收入编排方案是否契合你真正想要的架构。