标签频道
指标体系
该标签下的文章、提问与讨论帖。
指标链路从日级批处理迁移到流式实时：等价性验证的量化判据与实践 «结论先行：流式处理与批处理的等价性验证需从「指标类型分档容差」、「窗口粒度分层对比」、「近似算法偏差声明」三维度构建判据框架。本文基于 20 个核心指标双跑 14 天的实测数
结算系统 52 小时断流没人报警：低量时段的 DQC 盲区与四层对账方案 «结论先行：DQC 规则「全部通过」≠ 数据没坏。我复盘过一次真实的结算断流事故：上游 52 小时没出数，21 条 DQC 规则一条都没响，最终靠商家投诉才被发现，少
一、现象与背景 去年双十一前一周，我们电商大盘的下单转化率从 4.7% 跌到 4.3%，绝对值跌 0.4pp、相对跌幅 8.5%。告警是凌晨 2 点推的，值班数据同学手动拆了「地域 × 渠道 × 设备」三个维度，拆了 40 分钟只敢说"华东
一、现象或背景 在做技术文档和数据指标体系的过程中，我深刻体会到一个现实：团队里最昂贵的不是 SQL 跑不出数，而是「数跑出来了，但三个部门对不上」。 以「周活跃用户数（WAU）」为例： - 产品团队认为「7 天内有过任意一次登录」； -
比率型指标为什么总跳变甚至超过 100%：分子分母不同源的四种形态与一套同源校验门禁的取舍 «结论先行：比率型指标（转化率、留存率、占比、接口成功率、连接池水位）出问题，90% 不是「分子算错」或「分母算错」，而是分子和分母根本不是同一个集
小分母比率指标为什么会「天天抖」：用最小样本量 + Wilson 置信区间把 62% 的假告警拦在阈值外 «结论先行：转化率、客单价、人均时长这类比率指标，在分母（UV / 会话数 / 订单数）小的时候，它的"抖动"不是埋点 bug、也不是
【背景】 我在一家 10 人左右的数据团队做指标体系，核心看板有 30+ 指标。最近半年业务方把「周活跃用户」的口径改了三次，从「7 天内任意登录」→「7 天内登录≥2 次」→「7 天内完成一次核心行为」。每次改完，看板上一条曲线直接出现「
一、现象与背景 我是一名有 15 年经验的技术文档工程师，正在撰写一篇关于「如何为数据产品搭建指标体系」的经验博客。动笔前需要一份扎实的素材底稿，将 5 种主流指标体系设计方法论做系统性对比。 二、原理与根因：为什么需要对比不同的方法论 指
现象或背景：3000+ 查询模板多租户库，执行计划漂移如何定义成可计算、可基线、能事前拦截的指标？ 我是一名技术文档工程师，日常帮 30 人数据团队搭建指标体系。现在接手一个新课题：给一个 MySQL 8.0.36 / InnoDB 多租户
«结论先行：指标被回写不是 bug，是迟到数据、退款冲减、维度表变更的必然结果——但「没人知道哪些指标被改过、改了多少、什么时候才稳定」是治理缺失。本文给一套可复现的三件套：分区级改写检测快照、变更分级归因、指标级新鲜度/冻结 SLA，把「
背景 做了 5 年指标体系，我发现一个反直觉的事实：同一个服务，团队 A 和团队 B 算出来的「错误率」可能差一个数量级，而差异不在于监控系统，在于「什么算一次失败」的定义根本没对齐。 举一个真实场景：一个商品搜索接口，日请求量 2000
「周均日活」比「周活去重」高 38%：均值化与去重化的数学关系、一个重叠系数与看板双指标呈现方案 «结论先行：「一周内每天日活的算术平均」和「一周内的去重活跃用户」不是同一个指标的两种精度，而是两个不同的指标——前者是"人次的平均密度"，后
【背景】 做了 8 年技术文档和指标体系搭建，最扎心的一次经历：去年接手一个 200+ 微服务的告警体系，翻指标字典，发现 40% 的指标"owner"是已离职同学，30% 的 SLO 目标还是 2021 年定的（当时 P99 < 80ms
【背景】 做了 3 年指标体系搭建，最头疼的不是「指标怎么算」，而是「指标谁来定」。 一个真实场景：上周产品拉了个「核心留存率」复盘会，PPT 里写 42.3%。我拉了同一时间窗的数据，算出来 38.7%。差的那 3.6 个点是去重逻辑——
【背景】 15 年技术文档工程师，近两年主做 B 端 SaaS 的指标体系。负责一条 DAU 约 80 万的产品线核心大盘，指标链路：客户端埋点 → Kafka → Flink（5min 窗口聚合）→ ClickHouse → BI 看板。
文
标题
摘要