标签频道
指标体系
该标签下的文章、提问与讨论帖。
【背景】 我做了 8 年算法，近两年重心在指标体系与异动归因。手上是一条 B 端 SaaS 业务线，核心指标约 40 个（订单量、DAU、人均会话、付费率、ARPU 等），按天出看板。归因侧我已经用 LMDI 把复合指标的分子/分母贡献拆开
discussion
指标口径之争：到底是「统一口径」还是「各业务自定义」？聊聊指标字典落地时最痛的那一刀
背景 做了 8 年算法，近两三年重心在数据分析与指标体系搭建。最近帮 3 个团队梳理指标字典，发现一个反复出现的冲突： 「统一口径」派：所有业务必须用公司级指标字典，同一指标（如"活跃用户""转化率""留存率"）只能有一个定义，所有数据上报
discussion
指标异动归因：结论里要不要强制区分「相关」和「因果」？业务方只想要一个能落地的根因
先给背景。做了 8 年算法，近一年主要精力在指标体系与看板。最近反复撞到一个让我很拧巴的场景：核心指标（订单量、DAU、转化率这类）某天掉了一截，老板要的是「根因」，不是「大概是哪里出问题」。而我们做归因，本质是维度贡献度分解 + 关联分析
question
指标字典膨胀到 200+ 个后，怎么定「指标下线」标准才不伤业务
【背景】 我做了 10 年算法，近两年主做数据分析与指标体系搭建。接手一个 B 端 SaaS 的指标字典，半年前约 80 个指标，现在滚到 200+，背后埋点事件 400+。字典本身维护得还算规整（指标名/口径/口径 owner/上线日期都
【背景】 我在技术文档团队做数据分析，近一年主做指标体系搭建。当前负责一条 B 端 SaaS 业务线：核心指标 50 多个、埋点事件 160+，事件定义文档（指标字典）由我和数据同学维护，但埋点代码散在前端 3 个仓库 + 后端 2 个服务
一、现象与背景 去年我接手一条 C 端工具型产品的数据体系。接手时第一张周报里塞了 37 个指标：DAU、次日留存、人均会话时长、启动次数、崩溃率、分享率、付费率、ARPU、任务完成率……每个都标着「核心」。产品、运营、算法各盯一组，月底对
discussion
指标突然掉了 8%，你第一步是怀疑数据、拆维度，还是先对齐最近的事件？
背景 我做了 3 年技术文档，最近重心转到数据分析与指标异动排查。最典型的一个场景：早上打开看板，核心指标（比如任务完成率、付费转化）环比掉了 8%，群里立刻有人甩一句"为什么"。接下来那一两个小时团队怎么反应，我见过好几种，差异极大，也直
question
A/B 实验中 MDE 用绝对值还是相对值？样本量估算的实际差异与取舍
背景 我在做推荐排序策略的指标体系，核心验证手段是 A/B 实验。团队内部对 MDE（Minimum Detectable Effect，最小可检测效应）的设定方式有分歧： - 派 A（绝对值）：转化率提升 0.5pp 就算显著，不管基线是
«站在指标体系落地的视角，讲一次把「散落在 Wiki 和群聊里的指标口径」收敛成结构化定义、用 git 版本化、并在 CI 里做口径冲突检测的完整落地。重点是「口径 = 五要素」这个模型，以及一套可复现的 YAML schema + 校验脚
«结论先行：「会话（session）数」看起来是个简单的去重计数，但它是一个有状态的流式聚合——切分阈值、事件到达顺序、去重键粒度三个自由度任一不同，同一批事件就会算出 1.5~2 倍的 session 数。本文给一套用 "lag()" 物
question
指标口径文档的颗粒度：事件-指标映射表该独立维护还是并入指标字典
背景：我做技术文档，最近帮一个 30 人左右的产品团队搭指标体系，负责把「指标定义」沉淀成一份能长期维护的指标字典。指标约 40 个，背后埋点事件 100+。 现象：一开始我把每个指标口径直接写进字典表格（指标名 / 定义 / 计算公式 /
«结论先行：同名指标在不同报表里跑出 3~5 个不同的数，90% 不是 SQL 写错，而是「口径」没对齐。本文以一个真实的电商 App DAU 案例，给出 4 类根因、一份 30 行指标字典模板，以及 3 段可直接复用的 SQL。» 一、现
discussion
同一份数据，高管看板、数据团队、业务方各要一套数：「唯一可信源」是不是伪命题？
先给背景。做技术文档 15 年，近五年一直在帮团队搭指标体系。我见过最有代表性的一类事故，根因不是 SQL 写错，而是「同一个数字，三张看板三个值」：高管周报里的 GMV、数据团队的日报、业务方自己拉出来的 Excel，三个数能差出 3%～
LEFT JOIN + SUM(IF()) 的 NULL 静默空档：一次看板缺 38% 日期数据的复盘与 SQL 修复 «结论先行："LEFT JOIN" 之后直接 "SUM(IF(...))"，在"右表无行"的日期上会产生 NULL，而不
discussion
为什么指标字典越做越乱？聊聊指标治理的「越治越乱」悖论
背景 做了十年算法，近两年重心放在数据分析和指标体系上。我见过一个很反直觉的现象：很多团队花大精力建了指标字典（metric dictionary / metric layer），上线时口径清晰、大家点赞，但半年后字典就成了"历史遗迹"——
question
指标口径一改，历史曲线就断崖：指标版本化到底怎么落地才不被业务骂？
【背景】 我在一家 10 人左右的数据团队做指标体系，核心看板有 30+ 指标。业务方最近半年把"周活跃用户"的口径来回改了三次：从"7 天内任意登录"→"7 天内登录≥2 次"→"7 天内完成一次核心行为"。 【现象】 每次改完口径，看板
question
指标口径变更后，历史数据到底要不要回刷？回刷后老报表怎么办？
【背景】 我在技术文档团队做数据分析，去年帮一个 8 人产品团队做过指标盘点，核心指标 30 多个，散在 4 张 BI 看板 + 2 张宽表里。最近一次「活跃用户」口径变更，从「打开 App 即算」改成「产生一次有效交互（点击或停留 ≥5s
discussion
AI 产品的北极星指标怎么定？DAU 和转化率可能都不够用
背景 做了 8 年技术文档，近两三年重心在数据分析和指标体系。最近帮两个做 LLM / AI Agent 的团队搭指标，发现一个很有意思的现象：传统产品那套「DAU → 留存 → 转化」的指标树，套到 AI 产品上突然就「不灵」了。 举几个
question
加法型指标异动时，维度贡献度分解的具体公式与剪枝策略
背景：做了 8 年算法，近一年主要精力在指标体系与看板。最近在一个 B 端平台上反复撞到一个「归因不落地」的痛点：核心指标是加法型（订单量、DAU 这类可以按维度直接相加的），某天掉了一截，老板要的是「哪个维度组合贡献了多少」，而不是「大概
«站在「指标体系搭建」视角，对比三种异常判定方案的误报率、维护成本与适用场景，给一套可直接跑的 SQL 与阈值参数。» 一、现象与背景：告警疲劳比漏报更致命 接手一个 B 端数据平台，监控 42 个核心业务指标（DAU、付费转化率、订单量、
已经到底了
article
标题
摘要