埋点异常是什么情况

一、埋点数据在网络传输环节丢失

网络环境差，如果一些埋点没有数据暂存机制的话，或数据量超出了缓存上限而导致数据丢失。在网络高峰期，用户行为集中，给后台服务器带来较大压力，导致一些请求丢失

二、统计口径不同

客户端的情况很多，组织内部对指标的统计口径可能存在不统一，例如为了应对网络异常，会采取重传、间隔上传等策略，而这些策略可能存在标准不统一而导致统计结果有问题。

三、客户端的运行环境多样：手机有不同的型号，手机系统又分ios与安卓，而安卓还有大量定制，再加上部分刷机、越狱、同一系统不同版本，埋点代码可能无法兼容一部分运行环境，导致SDK在某些情况下不能有效调用，或者重复发送

四、脏数据

理想状态，使用我们app的都是一个个自然人，但现实环境要复杂得多，最常见的就是可能会有爬虫，甚至竞争对手的恶意攻击（比如DDoS）。

1.统计口径定义不一致，导致数据和后台差异大。例如登录，究竟是指指纹登录还是不含指纹验证登录。

2.埋点定义不一样，导致数据不准确。例如提交订单，究竟是参照前端埋点，点击提交按钮就触发，还是采取后端上报，订单成功后才触发上报。

3.采集方式带来的误差。前端采集一般会有一部分数据丢失，丢失率在5%左右属于正常范围。

埋点是个系统性的工作，以订单支付埋点为例，最后分析一下前后端埋点的优缺点。

所谓“埋点”，是数据采集领域（尤其是用户行为数据采集领域）的术语，指的是针对特定用户行为或事件进行捕获、处理和发送的相关技术及其实施过程。比如用户某个icon点击次数、观看某个视频的时长等等。

埋点的技术实质，是先监听软件应用运行过程中的事件，当需要关注的事件发生时进行判断和捕获。

特别注意需要明确事件发生时间点、判别条件，这里如果遇到不清楚的，需要和开发沟通清楚，避免采集数据与理想存在差异。例如：期望采集某个app的某个广告的有效曝光数，有效曝光的判别条件是停留时长超过1秒且有效加载出广告内容。

能捕捉到的异常，必须是线程执行已经进入 try catch 但 try catch 未执行完的时候抛出来的,以下都是无法被捕获到的情形。

异步任务抛出的异常（执行时try catch已经从执行完了）

promise（异常内部捕获到了，并未往上抛异常，使用catch处理）

语法错误（代码运行前，在编译时就检查出来了的错误）

优点：能够较好地进行异常捕获，不至于使得页面由于一处错误挂掉

缺点：显得过于臃肿，大多代码使用try ... catch包裹，影响代码可读性。

埋藏异常

omaly）：发现埋藏异常是比较困难的。但有时可以通过其上方运积物中的水成异常来探索。出露在基岩表面的原生异常被运积物掩埋时，也可称为埋藏异常。

正文

埋藏异常（buried anomaly）：发现埋藏异常是比较困难的。但有时可以通过其上方运积物中的水成异常来探索。如果水成异常不存在，就必须使用深部采样方法，或者使用一些新技术如气体测量方法等。出露在基岩表面的原生异常被运积物掩埋时，也可称为埋藏异常。

在ES3之前js代码执行的过程中，一旦出现错误，整个js代码都会停止执行，这样就显的代码非常的不健壮。

从ES3开始，js也提供了类似的异常处理机制，从而让js代码变的更健壮，程序执行的过程中出现了异常，也可以让程序具有了一部分的异常恢复能力。js异常的特点是，出现不会导致JS引擎崩溃，最多只会终止当前执行的任务。

开发者有时会面临上线的生产环境包出现了异常 ，在长期生产bug并修复bug的循环中总结出一下几个痛点：

无法快速定位到发生错误的代码位置，因为脚手架构建时会用webapck自动帮我们压缩代码，而上线版本又通常不会保留 source map（开源贡献者除外）

无法第一时间通知开发人员异常发生

不知道用户OS与浏览器版本、请求参数（如页面ID）；而对于页面逻辑是否错误问题，通常除了用户OS与浏览器版本外，需要的是报错的堆栈信息及具体报错位置。

错误埋点追踪系统的出现就是为了应对上述问题的解决方案，笔者正好最近接触了不少前端埋点与错误处理的博客内容，按例阶段性产出博客总结一下。