Hello ，前端埋点大家好 ，为啥务器我是上线 Sunday 。 说起埋点很多同学肯定是后服不陌生的 ，面试的直接时候经常会聊到 ，实际项目中更是前端埋点“标配” 。 但是为啥务器 ，有些同学为项目添加了埋点之后，上线上线第一天 ，后服服务器就直接被挤爆了 。直接 。模板下载前端埋点 。为啥务器 。上线 。后服 。直接这是为什么呢？ 典型的错误场景让咱们先来看几个埋点的典型错误场景 1. 全量直传很多同学写埋点的时候 ，最直观的想法就是：用户点一下按钮 ，我就发一次请求。 于是代码就长这样 ： 复制button.addEventListener("click", () => { fetch("/track", { method: "POST", body: JSON.stringify({ event: "button_click", time: Date.now() }), }); });看起来挺合理的 ，高防服务器对吧 ？点一下就上报一下呀 ，没毛病 。 但你有没有想过 ：当 1 万个用户同时点按钮会发生什么 ？ 1 万次点击 === 1 万个请求 ，直接打到后端接口 。如果有大型的活动 ，那么活动一上线，可能瞬间涌来几十万请求 。后端在没有做好充足准备的情况下 ，就可能会被直接 “冲死” 了 。 2. 没有采样逻辑有的同学觉得 ：“埋点嘛，多多益善 ，反正数据越全越好。”（这样想的云计算同学可不少） 于是页面里几乎所有的动作都打点 ： 用户点击按钮 → 埋点用户滚动页面 → 埋点用户划过一个元素 → 也埋点结果就是 ：用户在一个页面里随便滑动几下 ，前端 SDK 就疯狂地往后端塞数据 。 PS：这里给大家说一个同学遇到过的真实情况 某位同事，直接在一个列表滚动事件里写了埋点 。既 ：用户每滚动 1px 就发一次请求 。结果一批用户刚进入页面 ，后端就已经被几万条无效数据给搞懵了 。 所以说 ：埋点不是“越多越好”，而是要 有所取舍。否则 ，服务器租用你想要的洞察没拿到 ，反而先收获了一堆垃圾数据 。 3. 没有合并上报很多同学在写埋点的时候 ，完全没考虑“合并上报” 的情况 ，于是每次事件触发就立刻单独发一个请求 。 比如： 复制tracker.track("page_view"); tracker.track("button_click"); tracker.track("api_success");那么这样就会导致出现 “天量” 的请求 。 所以说，在上报的时候 ，要根据 “埋点策略” 进行 批量合并 。按照 不同的亿华云优先级划分 实时上报 和 统一上报 的方案。 设计终极解决方案如果咱们想要好好的完成埋点功能 ，既能拿到有效数据 ，又不会把服务器 “打崩” 。那么就需要对整个埋点方案进行设计了 。 先建立一份事件白名单表（事件名 、层级 、采样率 、是否实时 、字段 schema 、去重规则 、负责人），非白名单事件不进行上报 。建站模板
然后制定 采样策略，目的以 能看清趋势与差异 位标准 。 比如： 固定采样 ：滚动 10% ，曝光 30%，点击 50%（可按业务调参）分流采样 ：userId % 10 < 1 → 10% 样本动态采样 ：活动高峰服务端下发更高采样 ，平峰自动降采样分层采样 ：Core=100%，Important=30%~100% ，General=5%~20%然后根据数据的优先级 ，采用 实时 + 统一上报 的结合方式 实时上报 ：Core 事件（下单/支付/注册/登录），用于风控/实时看板统一上报 ：Important 事件 ，批量触发（条数阈值或时间阈值）离线上报(可选的) ：General 事件 ，集中批量，延迟可以更宽松一些因为篇幅有限 ，所以咱们今天就先说这些 。 总结来说 ：埋点得有策略 。不能所有的埋点数据都直接实时上报 。大家在实际埋点的方案中 ，也可以使用一些第三方的库或者平台 ，比如 ：sentry 、神策、GrowingIO 等等的 。 |
图片