为什么埋点会失控：从采集到消费的责任断裂

问题

埋点这件事，我在两个时代见过两种失控。

早年在物流与证券行业做 BI 时，失控的是指标。同一个「日活」在三张报表里有三种口径，没人说得清哪个是对的，也没人敢删掉另外两个。那时我以为这是数仓建模的问题，后来花了很多年做指标体系，把口径收敛到一处，问题看起来解决了。

到了一家全球化广告平台做数据合规与架构治理，我又看见了同样的东西，只是换了一层：这次失控的是信号本身。上报的事件越来越多，字段越来越宽，很多信号已经查不到是谁加的、给谁用的，但每天照样采、照样传、照样存。要删一个，先得证明「没人用」，而证明「没人用」比加一个信号难十倍。

表面症状大家都熟：重复采集、无人消费、口径漂移、隐私风险。但这些都不是根因。根因是责任链的断裂：采集是产品与前端加的，消费是分析与算法用的，成本是数据平台扛的，合规是另一拨人管的。四方各自尽职，却没有任何一方对「这个信号从生到死」负责。采集的人不用，用的人不管，删的人不敢。这不是技术债，是组织债，只是它最后会以存储账单和合规审计的形式表现出来。

约束

治理最难的不是「怎么做」，而是在哪些边界里做。

第一，不能停业务。埋点上报是线上链路的一部分，「先停掉再梳理」不现实。治理必须是在线的、增量的。

第二，隐性依赖难发现。一个信号的消费者不只是报表，还有离线特征、实时策略、实验分流的判断条件，以及跑在个人账号下的临时查询。前几种能从调度和血缘里找到，最后一种几乎不可见。

第三，合规是硬约束。数据最小化要求只采必要的字段，保留期要求到期后真的删掉。对一个「不知道谁在用」的系统，这两条几乎无法满足：既说不清「必要」，也不敢执行「删除」。

第四，所有人都很忙。任何要求前端为每个事件填表、要求分析师为每次查询登记的方案，都会在第一个季度死掉。责任必须被记录，但记录的成本要足够低。

方案

方案的核心是一句话：先把「责任」做成数据，再谈裁剪。

之前的治理大多从裁剪开始：找出没人用的信号，删掉。这条路走不远，因为「没人用」本身没有依据。顺序要反过来：先让每个信号拥有四样东西，owner（谁负责到底）、用途（为什么采）、保留期（该活多久）、消费血缘（此刻谁在用）。有了这四样，才有资格讨论去留。

先用一张图看责任链在哪里断。

flowchart LR
A["采集：前端 / 客户端上报"] --> B["传输：日志管道"]
B --> C["存储：数仓 / 特征库"]
C --> D["消费：报表 / 算法 / 实验"]
A -. "断点一：谁加的、为什么加" .-> X1["无 owner、无用途"]
C -. "断点二：该留多久" .-> X2["无保留期"]
D -. "断点三：谁在用" .-> X3["无消费血缘"]

对应三个断点，方案分三步。

注册：让信号先有身份

每个信号进注册中心，owner、用途、保留期必填。新增信号在上报代码合入前完成注册，做成流水线上的一道检查，而不是事后补录。存量信号的 owner 按最后修改上报代码的团队回填，用途和保留期允许先标「待确认」，但标记会一直挂着，直到有人认领。

血缘：让消费自己说话

消费关系不靠人登记。从查询日志、调度依赖、特征与实验配置里自动抽取「谁读了哪个信号」，定期写回到信号上。个人账号下的临时查询同样会被抓到，只是权重更低，并触发一条提醒：这个信号只有你在用，要不要认领。

生命周期：让存活有依据

信号的状态由血缘决定，而不是由某个人决定。连续一段时间无消费的信号进入「待归档」，通知 owner；无异议则停采，到期后按保留期删除。owner 如果认为该留，需要给出一个具体的消费方，而不是一句「以后可能有用」。

取舍

治理从哪里切入，我见过三种起点。

从采集端管最直觉，也是多数团队第一次尝试的方向。问题在于只管得住增量，对已经堆积的存量无能为力，而且审核本身会成为瓶颈，最后往往退化成走形式。

从消费端管对业务几乎无感，靠血缘就能找出无人消费的信号。但它回答不了「为什么采」。在合规审计里，「没人用所以删了」和「知道为什么采、采了多久」是两种完全不同的回答。

我最终从注册中心切入，不是因为它最省力，而是因为它是唯一能把另外两条路接进来的位置：采集端的门禁变成「未注册不得上报」，消费端的血缘变成注册中心里的一个字段。代价是存量回填期和血缘不全时的误判，决策记录里已经写明。

结果

最大的变化不在系统上，在人的认知上。

过去删一个信号是道德风险，谁删的谁背锅，所以没人删。现在删信号是一个流程：触发条件可查，申诉通道现成，责任落在流程而不是某个人身上。讨论的话题也变了，以前是「你能不能证明没人用」，现在是「owner 是谁、用途是什么、血缘上有谁」。前者无法证伪，后者是三条可以查的记录。

合规侧的变化同样具体。最小化和保留期第一次从「原则」变成「可执行」：最小化对应注册时必填的用途，保留期对应生命周期里的删除动作。审计不再依赖某个人的回忆，而是直接查注册中心。

平台侧则第一次拿到一份「可以动」的清单：哪些可以立刻归档，哪些要 owner 确认，哪些血缘不全需要先补，都是明确的，而不是一份看着吓人却无从下手的全量列表。

可迁移的经验

• 先做责任，再做裁剪。裁剪需要依据，依据只能来自被记录下来的责任。顺序反了，治理就会卡在「证明没人用」这一步。
• 把责任做成数据，不要做成文档。owner、用途、保留期、血缘落在系统里才能被检查、被审计；写在文档里的责任只在写的那天有效。
• 消费血缘要自动抽取，不靠人登记。任何依赖人主动填写的机制，都会在相关方最忙的季度失效。
• 把主观判断收进申诉环节，而不是放在默认入口。默认路径由数据决定，人只在例外时介入。
• 指标失控和埋点失控是同一个病。早年统一指标口径，本质上也是给每个指标找一个负责到底的人。换了一层数据，问题没有变。