标签频道
数据分析
该标签下的文章、提问与讨论帖。
背景 在搭建指标体系的过程中，我注意到一个普遍存在的问题：同一个指标在不同系统中的定义不一致。这导致了数据的不可比性和决策的不确定性。例如，"7 日留存率"在埋点、数仓、BI 看板和监控告警中可能有不同的计算方式，进而影响业务分析和判断。
一、现象与背景 我是一名有 15 年经验的技术文档工程师，正在撰写一篇关于「如何为数据产品搭建指标体系」的经验博客。动笔前需要一份扎实的素材底稿，将 5 种主流指标体系设计方法论做系统性对比。 二、原理与根因：为什么需要对比不同的方法论 指
【背景】 做了 3 年指标体系搭建，最头疼的不是「指标怎么算」，而是「指标谁来定」。 一个真实场景：上周产品拉了个「核心留存率」复盘会，PPT 里写 42.3%。我拉了同一时间窗的数据，算出来 38.7%。差的那 3.6 个点是去重逻辑——
【背景】 我做了 3 年技术文档，近两年重心在数据分析与指标体系搭建。最近半年在 3 个不同团队做"文档质量"指标落地，反复出现同一个卡点：业务方 / 管理层问"文档覆盖率多少"，我答出来的数字每次都不一样——取决于我用哪种口径，而且三种口
指标字典里 41% 的指标 90 天无人查询：一套「识别→标记→冻结→下线」的僵尸指标四段式退役流水线 «结论先行：指标字典只进不出，不是「治理不严」，而是「没有出口设计」。社区里已经写过指标怎么进（先审后用 vs 先用后审的争议，见我自己
«结论先行：环比告警 / 3σ 基线 / 同环比这三类方案，本质上都是「变点检测（change-point detection）」，它们对「跳变」很灵、对「匀速漂移（gradual drift）」几乎失明。 去年我们一条推荐链路的 CTR
【背景】 我做了 5 年算法，近两年主做指标体系搭建。负责一条 B 端 SaaS 的核心业务看板：约 30 个原子指标（活跃、留存、下单转化、支付成功率、客单价、接口 P99、错误率等），底层 Kafka → Flink 实时聚合 → Cl
【背景】 做了 10 年算法工程，最近半年主要在帮业务搭指标体系与告警链路。踩到一个反复出现的坑：阈值定得太死，要么半夜狼来了，要么白天出事没人喊。 举两个真实场景（已脱敏）： - 场景 A：某支付网关 P99 绝对阈值 500ms，但业务
【背景】 我做了 3 年技术文档，近两年重心在数据分析与指标体系搭建。最近半年在 3 个不同团队做"事故复盘 → 改进项 → 监控告警"的落地收尾。反复出现同一个模式：复盘会上 6–8 个工程师各自喊"应该盯 X 指标"，最后落地时只留 1
【背景】 我平时负责指标体系搭建，上周排查一次 P99 告警，发现一个很尴尬的口径问题：监控大盘上这个接口过去 1 小时的 P99 是 210ms，但我拿原始埋点日志重算，同样的时间窗 P99 是 480ms。 差异的根源是我们链路的存储设
【背景】 做了 10 年算法，带过增长、推荐、风控三条线的模型团队，几乎每个团队都经历过同一个尴尬场景： - 产品周报里写「本周转化率 6.8%」 - 算法 A/B 报告里写「实验组转化率 7.2%」 - BI 月报里写「本月转化率 6.1
文
标题
摘要