数据治理

背景 做了 15 年技术文档，近几年重心转向数据分析与指标体系搭建。这两年帮 4 个团队做过指标盘点，有一个数字让我一直没想通： - 一个 20 人产品团队，BI 看板 + 数据仓库 + 临时 SQL 里累计沉淀了 300+ 个指标； -

数据质量监控（DQC）规则怎么分层落地：从「天天误报」到「该响的响」 «站在指标体系落地视角，对比「全量规则一刀切」与「规则分层 + 阈值分级」两种 DQC 方案的取舍，给一套可复现的规则分层、阈值定法与误报治理路径。» 一、现象与背景：规

转化率为什么不能直接求平均：简单平均、加权平均、先汇总再除三种口径的取舍 «结论先行：比率型指标（转化率、ARPU、客单价、人均时长）不可加——"对每日转化率取算术平均"和"先汇总分子分母再相除"算出来的不是同一个数，且前者在流量波动越大时

改一个字段炸掉 14 个看板：指标血缘断点排查与下游影响面评估的两种方案取舍 «站在「动手改表之前」这个最容易被忽略的环节，对比 dbt 原生血缘与自研 SQL 爬取血缘两种方案的覆盖度、维护成本与断点识别能力，给出一套可复现的下游影响面评

背景 做了 10 年数据分析，最近帮 3 个团队做指标字典治理，反复撞到一个根本矛盾：指标上线到底该走「先审后用」还是「先用后审」？ 这个矛盾不是「要不要做指标字典」的问题，而是「指标字典的治理成本」和「业务想快速看数」之间的真实拉扯。我见

背景 做了 3 年技术文档、这两年转做指标体系，最近帮几个团队把散落在 BI 看板、SQL 脚本、wiki 指标字典里的口径往「一个地方」收敛。做着做着撞到一个根本分歧：口径到底算「文档」还是「代码」？ 这个分歧站内其实已经有人聊过「口径该

背景：做技术文档和数据指标体系这些年，我最大的感受是——团队里最贵的往往不是 SQL 跑不出数，而是「数跑出来了，但三个部门对不上」。举个很典型的场景：同一个「周活跃用户数（WAU）」，产品口径是「7 天内有过任意一次登录」，数据口径是「7

一、现象与背景 接手一个 B 端数据平台后，第一个季度就经历了一次「口径变更事故」：业务方要求把「付费转化率」的分母从 "uv（按访客会话去重）" 改成 "distinct user_id（按自然人去重）"，理由是「同一用户换设备不该被算两

【背景】 我做了 3 年技术文档，最近转做指标体系搭建，团队 12 人（2 数据 / 4 后端 / 4 产品 / 2 运营），核心指标 40+ 个，散在 3 张 BI 看板 + 1 个数据仓库 + 若干 SQL 脚本里。习惯「从现象倒推根因

【背景】 我做了 3 年技术文档，最近转做指标体系搭建，团队 12 人（2 数据 / 4 后端 / 4 产品 / 2 运营）。我习惯「从现象倒推根因」，但最近发现一个反复出现的卡点：业务方质疑某个指标时，我无法在 5 分钟内给出可复现的证据

背景 做了 10 年大数据平台，最近半年在多个团队里反复看到同一个争论：业务埋点（用户行为日志、操作流水、事件流）到底该怎么建模？我至少碰过三种流派，且每一种背后都站着一位"踩过坑的人"： 1) 扁平宽表派：一张 "events" 大表，几

一、现象与背景 接手一个 B 端 SaaS 的数据团队，日均埋点量约 1.8 亿条事件，覆盖 12 条产品线。接手第一周就撞上一堵墙：同一个「加购」行为，三个业务方给出的数字分别是 3.2 万、4.1 万、2.7 万——差了将近 50%。

【背景】 我做了 3 年技术文档，最近转做指标体系搭建。团队约 12 人：2 个数据、4 个后端、4 个产品、2 个运营。核心业务指标有 40 多个，散落在 3 张 BI 看板 + 1 个数据仓库 + 若干 SQL 脚本里。 【现象（具体可