标签频道
埋点
该标签下的文章、提问与讨论帖。
【背景】 15 年技术文档工程师，近两年主做 B 端 SaaS 的指标体系。负责一条 DAU 约 80 万的产品线核心大盘，指标链路：客户端埋点 → Kafka → Flink（5min 窗口聚合）→ ClickHouse → BI 看板。
«站在「技术文档工程师 + 指标体系」的视角，讲一件比「选哪种事件模型」更靠前、也更便宜的事：事件名字本身没有契约。我见过太多团队花大力气选了扁平宽表还是事件溯源，结果 "add_cart / cart_add / add_to_cart"
«结论先行：「调用次数多 = 功能重要」是一个看起来对、实际上会杀错人的判据。我 3 年做 B 端 SaaS 技术 PM，2024 Q1 到 2025 Q2 复盘了 12 次功能下线决策，其中 5 次（42%）上线后 60 天内被部分回滚或
«结论先行：「会话（session）数」看起来是个简单的去重计数，但它是一个有状态的流式聚合——切分阈值、事件到达顺序、去重键粒度三个自由度任一不同，同一批事件就会算出 1.5~2 倍的 session 数。本文给一套用 "lag()" 物
背景：我做技术文档，最近帮一个 30 人左右的产品团队搭指标体系，负责把「指标定义」沉淀成一份能长期维护的指标字典。指标约 40 个，背后埋点事件 100+。 现象：一开始我把每个指标口径直接写进字典表格（指标名 / 定义 / 计算公式 /
«结论先行：前端埋点「丢」不是网络问题，是时机问题。"beforeunload" 里发 "fetch" 会被浏览器静默 cancel，"visibilitychange→hidden" 在 iOS Safari 关 tab 时根本不触发，而
【背景】 我在做一套面向 B 端的数据分析平台，前端埋点通过 Kafka 上报，经 Flink 清洗后写入 ClickHouse，下游是业务方直接查的指标看板。链路本身不复杂，但最近反复踩到一个让我很头疼的问题。 【现象】 前端埋点字段发生
先说背景。我做了十年算法，近两年重心转到数据分析与指标体系搭建，见过太多团队在「指标怎么定」这件事上反复拉扯。最近被问到最多、也最让我想抛出来聊的就是这个矛盾：一个业务刚起步、数据还很薄的时候，到底该先立一个北极星指标（North Star
背景 做了 10 年大数据平台，最近半年在多个团队里反复看到同一个争论：业务埋点（用户行为日志、操作流水、事件流）到底该怎么建模？我至少碰过三种流派，且每一种背后都站着一位"踩过坑的人"： 1) 扁平宽表派：一张 "events" 大表，几
一、现象与背景 接手一个 B 端 SaaS 的数据团队，日均埋点量约 1.8 亿条事件，覆盖 12 条产品线。接手第一周就撞上一堵墙：同一个「加购」行为，三个业务方给出的数字分别是 3.2 万、4.1 万、2.7 万——差了将近 50%。
文
标题
摘要