分类频道
数据分析
该分类下的文章、提问与讨论帖。
【背景】 我做了 8 年算法，近两年重心在指标体系与异动归因。手上是一条 B 端 SaaS 业务线，核心指标约 40 个（订单量、DAU、人均会话、付费率、ARPU 等），按天出看板。归因侧我已经用 LMDI 把复合指标的分子/分母贡献拆开
discussion
指标口径之争：到底是「统一口径」还是「各业务自定义」？聊聊指标字典落地时最痛的那一刀
背景 做了 8 年算法，近两三年重心在数据分析与指标体系搭建。最近帮 3 个团队梳理指标字典，发现一个反复出现的冲突： 「统一口径」派：所有业务必须用公司级指标字典，同一指标（如"活跃用户""转化率""留存率"）只能有一个定义，所有数据上报
discussion
指标异动归因：结论里要不要强制区分「相关」和「因果」？业务方只想要一个能落地的根因
先给背景。做了 8 年算法，近一年主要精力在指标体系与看板。最近反复撞到一个让我很拧巴的场景：核心指标（订单量、DAU、转化率这类）某天掉了一截，老板要的是「根因」，不是「大概是哪里出问题」。而我们做归因，本质是维度贡献度分解 + 关联分析
背景 我负责一条 B 端 SaaS 产品的指标体系，指标字典里「活跃租户」的口径上季度从"任意 API 调用"调整为"24h 内至少 3 次核心 API 调用"。业务方要求用新口径回看过去 12 个月的活跃租户曲线做季度复盘，但数仓 DWS
question
指标字典膨胀到 200+ 个后，怎么定「指标下线」标准才不伤业务
【背景】 我做了 10 年算法，近两年主做数据分析与指标体系搭建。接手一个 B 端 SaaS 的指标字典，半年前约 80 个指标，现在滚到 200+，背后埋点事件 400+。字典本身维护得还算规整（指标名/口径/口径 owner/上线日期都
同一笔订单，两个时间字段：下单时间 vs 支付时间如何悄悄改写月度 GMV «结论先行：「GMV 对不上」里有一大类，根因既不是时区、也不是 JOIN 放大，而是「这笔订单到底算哪一天」——而「哪一天」取决于你用的是 "created_at
discussion
同一个指标五个系统五种口径，到底谁来拍板？聊聊指标口径集中治理 vs 团队自治
背景 做了 8 年算法，这几年大量精力花在指标体系与数据治理上。最近反复撞到一个怪象，比「北极星选哪个」更底层、也更磨人：同一个指标，在不同系统里长得完全不一样。 举个我真实遇到过的例子：一条「7 日留存率」。 - 埋点原始事件里，"活跃"
【背景】 我在技术文档团队做数据分析，近一年主做指标体系搭建。当前负责一条 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 + 校验脚
discussion
为什么我劝业务方别急着做 AB 实验？聊聊「先拍脑袋，再验证」的合理性
背景 做了 15 年算法，近 8 年重心在数据分析与指标体系上，经手或评审过的 AB 实验不下 200 个。最近半年我越来越频繁地遇到同一个场景：业务方拿着一个"看起来挺有道理"的改动，第一句话就是"我们做个 AB 实验吧"。我通常会先反问
背景 我在帮一个 30 人规模的数据团队做指标字典（metric dictionary）落地，团队有 40+ 个核心指标散落在 BI 看板、临时 SQL 和 Wiki 里。想把它收敛成一份单一事实源，让指标定义既能给人读、又能被工具消费（自
«结论先行：「会话（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%～
【背景】 做了 15 年算法，近两年主要精力在指标体系与归因分析。负责一个 B 端 SaaS 的核心大盘，一级指标约 15 个，每个指标可下钻的维度有 6 个：产品模块、用户层级（新/老/付费）、地区、渠道、设备类型、行业。业务方要求「指标
LEFT JOIN + SUM(IF()) 的 NULL 静默空档：一次看板缺 38% 日期数据的复盘与 SQL 修复 «结论先行："LEFT JOIN" 之后直接 "SUM(IF(...))"，在"右表无行"的日期上会产生 NULL，而不
已经到底了
article
标题
摘要