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");
那么这样就会导致出现 “天量” 的请求。
所以说，在上报的时候，要根据 “埋点策略” 进行 批量合并。按照 不同的优先级划分实时上报和统一上报的方案。
设计终极解决方案
如果咱们想要好好的完成埋点功能，既能拿到有效数据，又不会把服务器 “打崩”。那么就需要对整个埋点方案进行设计了。
闽公网安备 35020602001684号