上个月跟一个做了6年数据产品的朋友吃饭，他说了句话让我当场放下筷子。
他说：我们公司数据团队30个人，BI报表做了上千张，但业务方做决策的时候，还是靠拍脑袋。
我问他为什么。
他想了想说：每个系统单独看都没问题，埋点在采，数仓在建，BI在出报表，标签也打了，A/B也跑了。但这些东西之间是断的。埋点采的数据进不了标签体系，标签体系的结果喂不到A/B平台，A/B平台的结论又没人会写到BI看板里。
30个人，5套系统，0个闭环。
这不是个例。我接触过的产品团队里，至少70%存在同样的问题：每个数据模块都有人在做，但没有人在串。
今天这篇文章，我不打算给你讲每个系统的功能清单。那种内容百度一搜一堆。
我要讲的是：这5个模块各自的核心职责到底是什么，它们之间的数据怎么流转，以及，为什么你把它们单独建好了，闭环还是跑不通。
一、先搞清楚一件事：这5个模块不是平行关系
大多数人第一次接触数据体系，会觉得埋点、数仓、BI、标签、A/B是5个独立的工具，各干各的。
这是最常见的认知误区。
它们之间是有严格的上下游依赖关系的，像一条流水线：
-
埋点，负责原始数据采集，是整条链路的入口 -
数仓，负责数据清洗、加工、建模，是中枢 -
BI，负责把加工后的数据变成可视化报表，是分析界面 -
标签体系，负责把数据提炼成用户画像，是策略引擎的燃料 -
A/B平台，负责用实验验证策略是否有效，是决策闭环的终点
每一层的输出，是下一层的输入。任何一层断掉，后面的全部失效。
这就是为什么很多团队每个模块都建了，闭环还是跑不通的原因：他们是按功能建的，不是按数据流建的。
二、埋点系统
大部分产品经理对埋点的理解停留在：在页面上加个代码，记录用户点了什么。
这个理解不能说错，但它完全没有触及埋点的核心价值。
埋点的本质不是记录行为，而是定义分析维度。
你在设计埋点方案的时候，其实是在回答一个问题：未来我要用什么视角去理解用户行为。
举个例子。同样是记录用户点击了商品详情页，你可以只埋一个事件叫 click_detail。也可以同时带上：来源渠道、用户等级、商品类目、会话时长、上一步页面。
前者只能告诉你：有人点了。
后者能告诉你：什么渠道来的什么等级的用户，在浏览了多久之后，从哪个入口点击了哪个类目的商品详情。
同一个动作，因为埋点设计不同，后续能回答的问题完全不同。
这就是为什么我一直说，埋点不是技术活，是产品设计。
埋点的三种粒度
实际操作中，埋点分三种粒度：
- 页面级埋点
记录页面PV/UV，最粗，能回答流量分布问题 - 事件级埋点
记录具体交互行为（点击、滑动、提交），能回答用户行为路径问题 - 属性级埋点
在事件基础上附带业务属性（商品ID、优惠券金额、AB实验分组），能回答业务归因问题
越往下，数据价值越高，实施成本也越高。
很多团队的埋点只做到了事件级，缺少属性级埋点。结果就是：数仓里有行为数据，但没有业务上下文。分析的时候只能看到用户做了什么，看不到为什么做。
三、数仓
不对。数据库解决的是存储和查询问题，数仓解决的是数据的一致性和可分析性问题。
一句话概括数仓的核心职责：把来自不同业务系统、不同格式、不同口径的原始数据，清洗、整合、建模成统一的、可被下游消费的分析资产。
数仓的分层架构
工业界通用的数仓分层是这样的：
- ODS层
- DWD层
明细数据层，做了清洗、去重、标准化，但保留明细粒度 - DWS层
汇总数据层，按主题域做轻度聚合，比如用户粒度的日活跃汇总 - ADS层
应用数据层，面向具体报表、标签、接口的输出结果表
每一层的职责是明确的：ODS保真，DWD治理，DWS聚合，ADS服务。
为什么要分层？
因为如果不分层，每个下游消费方都直接查原始数据，会出现三个问题：
第一，口径不一致。A团队算的日活是1000万，B团队算出来是800万。不是谁算错了，是两个团队用了不同的日活定义。
第二，重复计算。10个报表都需要用户日活数据，每个报表各算一遍，浪费算力。
第三，原始数据质量不可控。业务系统的数据有空值、有异常、有延迟，不做治理直接用，下游分析结果不可靠。
分层的本质是把数据治理的成本前置化、标准化。在DWD层统一口径，在DWS层统一聚合逻辑，下游直接消费标准化的结果。
四、BI
但我发现，绝大多数团队对BI的使用方式是错的。
他们把BI当成了出报表的工具。业务方提一个需求，数据分析师写一个SQL，生成一张图表，贴到看板上。需求越来越多，报表越来越多，看板越来越多。
最后的结果是：公司有300张报表，但没有人知道该看哪张。
这是BI最大的反直觉：报表数量和数据驱动能力之间，没有正相关关系。甚至很多时候是负相关。
因为报表太多，意味着没有体系。没有体系，意味着业务方不知道在什么场景下该看什么指标。
BI的真正职责是什么？
不是出报表，是构建一套分析语言。
这套语言包括三个层次：
- 指标体系
定义业务的核心度量和口径，比如什么叫活跃用户、什么叫转化率、怎么算留存 - 分析框架
定义在不同业务场景下应该看哪些指标的组合，比如增长场景看获客漏斗，留存场景看同期群分析 - 归因模型
定义指标变化时如何追溯原因，比如转化率下降了3%，是哪个渠道、哪个人群、哪个步骤导致的
有了这三层，业务方才能自己诊断业务，而不是每次都找数据团队写SQL。
举个案例：为什么300张报表不如3张看板
去年我参与过一个B端SaaS产品的数据治理项目的咨询。
这家公司的BI系统里有接近400张报表，3个专职数据分析师，每天光维护报表就占了60%的时间。
但业务负责人跟我说：我每周看的报表其实就3张，其他的我都不知道谁在看。
我们做了一次报表使用率审计。结果是：400张报表里，过去30天有人打开过的只有47张。使用率不到12%。
后来我们做了一件事：砍掉了80%的报表，把剩下的重组成5个场景化看板，每个看板对应一个业务决策场景：
-
获客效率看板：回答每天花了多少钱、获了多少客、成本趋势如何 -
转化漏斗看板：回答用户在哪一步流失最多 -
用户健康度看板：回答活跃率、留存率、流失预警 -
营收归因看板：回答收入变化的驱动因素 -
实验效果看板：回答当前在跑的A/B实验结果如何
砍报表的时候阻力非常大，因为每张报表当初都是有人提需求才做的。但使用率数据摆在那里，争论就少了很多。
上线之后，数据分析师的报表维护时间从每天60%降到了15%，腾出来的时间用在了专题分析上。业务负责人反馈：以前每周一的经营会要准备2小时数据，现在打开看板直接讨论。
这个案例说明一个问题：BI的价值不在于多，在于准。准的意思是：每张报表都精确对应一个决策场景。
五、标签体系
标签体系这个词听起来很好理解：给用户打标签嘛。
但如果你只把标签理解成贴标签，你就会犯一个很多团队都犯过的错误：标签打了一堆，但没人用。
标签体系的本质不是分类，是构建策略引擎的输入变量。
什么意思？
一个标签如果只是告诉你这个用户是高价值用户，这个信息本身没有任何用处。
它必须能触发一个动作：高价值用户进来的时候，推荐策略要从通用推荐切换为个性化推荐；高价值用户流失预警触发的时候，运营策略要自动发送召回券。
标签的价值 = 标签的准确度 × 标签被策略消费的次数。
如果标签打得很准但没有下游策略消费，那就是浪费算力。
标签的三种类型
从计算方式来分，标签有三种：
- 事实标签
直接从数据中提取，不需要计算。比如性别、注册日期、最近一次登录时间 - 统计标签
通过聚合计算得到。比如近30天下单次数、累计消费金额、平均会话时长 - 预测标签
通过模型预测得到。比如流失概率、购买意向分、生命周期阶段
越往下，计算复杂度越高，但策略价值也越高。
大多数团队的标签体系停留在事实标签和统计标签层面。预测标签需要机器学习能力，很多团队不具备。
但我想说的是：即使只有统计标签，只要和策略引擎打通了，也能产生巨大价值。
关键不在于标签有多高级，而在于标签能不能被下游系统实时读取和消费。
标签和数仓的关系
标签体系的数据来源是数仓。
具体来说，标签体系从DWS层或ADS层读取汇总数据，经过标签计算逻辑，产出标签结果，写入标签存储（通常是Redis或HBase这类KV存储，因为要支持线上实时查询）。
这里有一个很多团队忽视的问题：标签的更新频率。
事实标签基本是实时或准实时更新的。但统计标签和预测标签通常是T+1更新，也就是每天凌晨跑批计算一次。
这意味着，如果你的策略引擎依赖的是一个T+1更新的流失概率标签，那么用户今天的行为变化，要到明天才会反映在标签里，策略的响应延迟至少是24小时。
对于高频决策场景（比如实时推荐、实时定价），T+1标签是不够的。你需要一套实时标签计算能力，通常基于Flink或Kafka Streams实现。
六、A/B平台
A/B平台是数据闭环里最后一个模块，也是最容易被误用的一个。
大部分产品经理对A/B测试的理解是：做了一个新功能，上线之前先A/B测一下，看看数据好不好。
这个理解不是完全错的，但它遗漏了A/B测试最重要的价值。
A/B测试的本质不是测功能，是测假设。
什么叫测假设？
你做一个新功能之前，一定有一个假设：我认为把购买按钮从灰色改成橙色会提升转化率。这是一个假设。
A/B测试做的事情是：用随机分流的方式，让一部分用户看到灰色按钮，另一部分用户看到橙色按钮，跑够样本量之后，用统计检验判断两组之间的差异是否显著。
你测的不是橙色按钮好不好看，你测的是你那个假设推理一假设把按钮颜色和转化率关联起来一一是否成立。
这个区别很重要。
因为如果你认为A/B测试是在测功能，你会在实验结束后关注结论：新版好还是旧版好。
但如果你认为A/B测试是在测假设，你会在实验结束后关注学习：我对用户行为的哪个假设被验证了，哪个被推翻了。
前者只能告诉你这一次该选什么，后者能帮你建立对用户行为的系统性理解。
A/B平台的核心能力
一个成熟的A/B平台需要具备四个核心能力：
- 分流引擎
把用户随机分到实验组和对照组，要保证分流的随机性和互斥性 - 指标计算
自动统计实验组和对照组的核心指标（转化率、留存率、人均GMV等） - 统计检验
判断两组差异是否具有统计显著性，不能只看绝对值差异 - 实验管理
支持实验的创建、启停、流量调整、灰度放量
这四个能力缺任何一个，A/B测试的结论都不可靠。
最常见的问题出在统计检验这一步。很多团队跑A/B实验，只看平均值：实验组转化率3.2%，对照组3.0%，所以实验组赢了。
这个结论可能是错的。
因为0.2个百分点的差异，在样本量不够的情况下，完全可能是随机波动。你需要算p值，在95%的置信度下判断这个差异是否显著。如果p值大于0.05，这个差异就不能作为决策依据。
不做统计检验就下结论，和拍脑袋没有本质区别。只不过拍脑袋的时候没有数字，现在有个数字让你拍得更有信心了。信心增加了，准确度没有增加。
七、怎么串成一套闭环
讲完了5个模块各自的职责，现在回到核心问题：怎么串成一套数据闭环。
很多团队的数据体系之所以是断裂的，是因为他们在建设的时候，把这5个模块当成5个独立项目来立项、来推进。埋点归前端，数仓归数据工程，BI归数据分析，标签归算法，A/B归产品。
5个团队，5个立项，5套OKR，各自交付各自的KPI。
每个模块单独验收的时候都合格了，但合在一起就是不通。
闭环的关键不在于每个模块做得多好，而在于模块之间的数据接口是否对齐。
闭环的数据流转路径
一条完整的数据闭环是这样跑的：
- 埋点 → 数仓
客户端/服务端埋点数据，通过数据管道（Kafka + Spark/Flink），落入数仓ODS层 - 数仓 → BI
数仓的ADS层输出标准化指标表，BI工具直连ADS层出报表和看板 - 数仓 → 标签体系
数仓的DWS/ADS层输出用户维度汇总数据，标签引擎消费数据生成标签，写入标签存储 - 标签体系 → 策略引擎
线上系统（推荐、营销、风控）实时查询标签存储，获取用户标签，执行个性化策略 - 策略引擎 → A/B平台
策略的不同版本通过A/B平台分流，对比实验效果 - A/B平台 → 埋点
实验分组信息作为埋点属性回传，和用户行为数据绑定 - A/B平台 → BI
实验结果数据回流到BI看板，供决策者查看和决策
注意第6步和第7步。
这是大多数团队缺失的环节。
A/B实验跑完了，结论出来了，然后呢？结论变成了一封邮件，一个飞书文档，或者一次周会上的口头汇报。
没有回流到数仓，没有沉淀到指标体系，没有影响下一轮标签计算。
这就是闭环断裂的典型表现：终点和起点之间没有连接。
最后
说到底，数据闭环这件事，技术上不难。5个模块的技术方案都很成熟，开源方案一搜一堆。
难的是两件事：一是数据模型的统一，二是组织架构的适配。
技术问题花钱能解决，协作问题花钱解决不了。
这也是为什么我在开头说的那个案例，30个人5套系统0个闭环，问题不在工具，在组织。