指标口径

【背景】我在技术文档团队做了 15 年文档，近两年主做指标体系。习惯从现象倒推根因。最近接手一个 B 端 SaaS 的"付费转化率"核心指标，口径字典里已经写得很清楚：付费转化率 = 当日产生有效付费事件的独立用户数 ÷ 当日进入收银台页的

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

【背景】 做了 10 年算法，近两年重心在指标体系与数据管道。负责一条 B 端 SaaS 的核心指标大盘，约 25 个指标，日粒度计算，底层是 ClickHouse（批）+ Flink（实时流）+ T+1 离线批。 【现象】 最近重构「独立

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

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

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

先给背景：我在技术文档团队做数据分析，这几年最大的体会是——指标口径不一致，是跨团队协作里最容易被低估的成本。 举几个常见的分歧场景，看看大家有没有同感： 1. 「活跃用户」到底是什么 业务方说「打开过 App 就算」，数据方说「要有有效行

人均 GMV 凭空多出 2.5 倍：一对多 JOIN 放大（fan-out）让 SUM/COUNT 静默虚增的根因与三层解法 «结论先行：大多数「指标对不上」不是数据错了，而是聚合粒度错了。当你把「一」侧的指标（如订单金额）和「多」侧的行（

【背景】 我做了 10 年技术文档，近两年转做指标体系搭建，负责一条 B 端 SaaS 的核心大盘。其中「今日活跃会话数」这个指标，公司要求白天看实时大盘、月底看月报，于是我们跑了两条链路： - 实时：Flink 消费 Kafka 事件流，

一、现象与背景 过去一年我在三家团队都撞过同一堵墙：产品说「7 日留存只有 18%」，增长说「我们 7 日留存稳定在 27%」，数据看板上一周前是 21%。三个数都来自同一张用户表、同一个埋点，差异不是噪声，而是口径。 规模上这件事很贵：一

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