埋点——about前端

所谓“埋点”，是数据采集领域(尤其是用户行为数据采集领域)的术语，指的是针对特定用户行为或事件进行捕获、处理和发送的相关技术及其实施过程。比如用户某个icon点击次数、观看某个视频的时长等等,埋点的技术实质，是先监听软件应用运行过程中的事件，当需要关注的事件发生时进行判断和捕获。（比方说一些大数据杀熟，多次访问价格直接涨价）

前端通过JS监听到行为数据/业务数据/属性数据/广告数据

特别注意需要明确事件发生时间点、判别条件，这里如果遇到不清楚的，需要和开发沟通清楚，避免采集数据与理想存在差异。比如进入某个页面、点击某个按钮等，会自动触发记录和存储，然后这些数据会被收集并被传输到终端提供商，或者是通过后端采集用户使用服务过程中的请求数据。

为什么需要埋点

数据生产->数据采集->数据处理->数据分析挖掘->数据驱动/用户反馈->产品优化/迭代上述是整个数据从产生到最终作用于产品优化上的过程。埋点是整个流程的开始点，终端提供商在收集到埋点数据之后，通过大数据处理、数据统计、数据分析、数据挖掘等加工处理，可以得到衡量产品状态的一些基本指标，比如活跃、留存、新增等大盘数据，从而洞察产品的状态，随着数据挖掘等技术的兴起，埋点采集到的数据在以下方面的作用也越来越凸显。

代码埋点

因为需要监测网站上/app上用户的行为，是需要在网页/app上加载一些代码的，当用户触发相应行为时，进行数据上报，也就是代码埋点。这一的代码在网站上叫检测代码，在app中叫SDK（Software Development Kit）。市场上的第三数据采集均支持代码埋点，GA,GrowingIO,神策等。

优点:可以详细的设置某一个事件自定义属性缺点:时间、人力成本大，数据传输的时效性。
缺点：时间、人力成本大，数据传输的时效性。

如何去埋点

一般情况下，主要有三类埋点：展现埋点+曝光埋点+交互埋点

展现埋点

定义展现其实是一个服务端的触发。服务端被触发后，用户侧将会展现什么内容，展现埋点需要记录的是页面展现的内容信息，即服务端下发的内容是什么(这些东西一定是当前页面主要内容，不包含一些交互信息)。

曝光埋点

哪些下发的内容被用户实际看到了。和展现埋点类似，由于屏幕有限，但内容可以无限。哪些内容被用户侧实际看到(曝光)，需要记录的是单个“内容”被看到。一系列被下发的内容，可以触发多次曝光埋点。

交互埋点

交互埋点表明的是功能/内容被用户“点击”了。从埋点时机来说，这个是展现 & 曝光的下游。记录对于我们提供的“服务”的“消费”情况。比如，一个页面，用户可以点击，那么我们需要记录相应的交互动作埋点;比如，一个视频可以点赞，我们也可以记录交互埋点;比如，一个视频可以播放暂停，我们也可以记录消费埋点。总体来说，就是，我们要记录被看到的可交互功能/信息的“消费”数据

埋点记录

关于埋点记录需要明确记录两个信息:点位信息、点位映射。

点位信息:明确每个业务事件下的具体的参数信息，包含公共参数、业务参数。

点位映射:每个埋点对应的业务含义。

前端监控

一般来讲一个成熟的产品，运营与产品团队需要关注用户在产品内的行为记录，通过用户的行为记录来优化产品，研发与测试团队则需要关注产品的性能以及异常，确保产品的性能体验以及安全迭代。

所以前端监控一般也分为三大类：

数据监控（监控用户行为）

PV/UV: PV(page view):即页面浏览量或点击量;UV:指访问某个站点或点击某条新闻的不同 IP 地址的人数用户在每一个页面的停留时间
用户通过什么入口来访问该网页
用户在相应的页面中触发的行为，等…

统计这些数据是有意义的，比如我们知道了用户来源的渠道，可以促进产品的推广，知道用户在每一个页面停留的时间，可以针对停留较长的页面，增加广告推送等等。

性能监控（监控页面性能）

不同用户，不同机型和不同系统下的首屏加载时间
白屏时间
http 等请求的响应时间
静态资源整体下载时间
页面渲染时间
页面交互动画完成时间，等…

这些性能监控的结果，可以展示前端性能的好坏，根据性能监测的结果可以进一步的去优化前端性能，尽可能的提高用户体验。

异常监控（监控产品、系统异常）

及时的上报异常情况，可以避免线上故障的发上。虽然大部分异常可以通过 try catch 的方式捕获，但是比如内存泄漏以及其他偶现的异常难以捕获。常见的需要监控的异常包括:

Javascript 的异常监控
样式丢失的异常监控

埋点上报

OK，上面我们说到了前端监控的三个分类，了解了一个产品需要监控哪些内容以及为什么需要监控这些内容,那么我们应该怎么实现前端监控呢?

实现前端监控

肯定是将我们要监控的事项(数据)给收集起来，再提交给后台进行入库，最后再给数据分析组进行数据分析，最后处理好的数据再同步给运营或者是产品。

数据收集的丰富性和准确性会直接影响到我们做前端监控的质量，因为我们会以此为基础，为产品的未来发展指引方向。

埋点上报的方法

现在常见的埋点上报方法有三种:手动埋点、可视化埋点、无埋点

手动埋点

手动埋点，也叫代码埋点，它的本质其实就是用JS代码拿到一些基本信息，然后再一些特定的位置返回给服务端，调用埋点 SDK 的函数，在需要埋点的业务逻辑功能位置调用接口，上报埋点数据，像友盟、百度统计等第三方数据统计服务商大都采用这种方案。

手动埋点让使用者可以方便地设置自定义属性、自定义事件;
所以当你需要深入下钻，并精细化自定义分析时，比较适合使用手动埋点。
缺陷就是，项目工程量大，需要埋点的位置太多，而且需要产品开发运营之间相互反复沟通，容易出现手动差错，如果错误，重新埋点的成本也很高。

可视化埋点

通过可视化交互的手段，代替上述的代码埋点。将业务代码和埋点代码分离，提供一个可视化交互的页面，输入为业务代码，通过这个可视化系统，可以在业务代码中自定义的增加埋点事件等等，最后输出的代码耦合了业务代码和埋点代码。

无埋点

无埋点则是前端自动采集全部事件，上报埋点数据，由后端来过滤和计算出有用的数据。优点是前端只要一次加载埋点脚本，缺点是流量和采集的数据过于庞大，服务器性能压力山大。

如何埋点

手动埋点

手动埋点的本质其实就是用JS代码拿到一些基本信息（发送给到服务器，发送给到服务器就会有我们的AJAX请求，服务器拿到这些数据统计保留下来），然后再一些特定的位置返回给服务端,such as

域名:document.domainURLdocument.URL
页面标题:document.title
分辨率:window.screen.height & window.screen.width
颜色深度:window.screen.colorDepth
Referrer: document.referrer
客户端语言:navigator.language

如以上我们可以拿到这些内容，再比如：还可以拿到性能花费多久时间/用户网络的性能怎么样/用户什么时候开始滚动页面，这些是怎么拿到的呢？

Performance

通过Performance我们可以拿到DNS解析时间、TCP建立连接、首页白屏时间、DOM渲染完成时间、页面load时间

// //拿到performance并且初始化一些参数
let timing = performance.timing,
    strat = timing.navigationStart,
    dnsTime = 0,
    tcpTime = 0,
    firstPaintTime = 0,
    domRenderTime = 0,
    loadTime = 0;
//根据提供的api和属性拿到对应的时间
dnsTime = timing.domainLookupEnd - timing.domainLookupStart
tcpTime = timing.connectEnd - timing.connectStart
firstPaintTime = timing.domContentLoadedEventEnd - start
loadTime = timing.loadEventEnd - start
console.log('DNS解析时间:',dnsTime,'\nTCP建立时间:',tcpTime,'\n首屏时间:',firstPaintTime,
'\ndom渲染完成时间:',domRenderTime,'\n页面onload时间:',loadTime);

拿到数据以后我们可以再提交，或者通过图片的方式去提交埋点内容

可视化埋点

这种埋点方案，又叫无痕埋点，解放了前端手动操的工作量，其实本质就是用系统去插入本来需要手动插入的埋点，这种埋点方式由于自带技术壁垒，所以开发人员基本基本不用考虑，花钱即可，比较靠谱的服务商国外的Mixpanel，国内较早支持可视化埋点的有TalkingData、诸葛I0，腾讯 MTA 等

无埋点

无埋点并不是没有任何埋点，所谓无只是不需要工程师在业务代码里面插入侵入式的代码。只需要简单的加载了-段定义好的SDK代码，技术门槛更低，使用与部署也简单，避免了需求变更，埋点错误导致的重新埋点。这也是大多网站的选择，因为实在太简单了我们先来看看百度埋点``长什么样子

<script>
// 定义或获取 _hmt 数组,用于存储百度统计的相关配置和数据
var _hmt = _hmt || [];

// 立即执行函数,用于封装代码并防止变量污染全局命名空间
(function() {
  // 创建一个新的 script 元素,用于插入百度统计的 JavaScript 文件
  var hm = document.createElement('script');

  // 设置 script 元素的 src 属性,指向百度统计的 JavaScript 文件
  // 其中 <%htmlWebpackPlugin.options.baiduCode %> 是一个 webpack 插件的占位符,
  // 它会被替换为实际的百度统计代码
  hm.src = 'https://hm.baidu.com/hm.js?<%htmlWebpackPlugin.options.baiduCode %>';

  // 获取当前页面中第一个 script 元素
  var s = document.getElementsByTagName('script')[0];

  // 将创建的 script 元素插入到当前页面的第一个 script 元素之前
  s.parentNode.insertBefore(hm, s);
})();
</script>

将这一段代码插入我们的HTML中

我们便能清晰的看到统计数据，省时省力，就是不省钱!但是缺点就是由于是自动完成，无法针对特定场景拿到数据，由后端来过滤和计算出有用的数据。导致服务器压力山大

为什么都用GIF上报埋点

发现过程

使用GIF上报的原因

向服务器端上报数据，可以通过请求接口，请求普通文件，或者请求图片资源的方式进行。只要能上报数据，无论是请求GIF文件还是请求js文件或者是调用页面接口，服务器端其实并不关心具体的上报方式。那为什么所有系统都统一使用了请求GIF图片的方式上报数据呢?

防止跨域

1般而言，打点域名都不是当前域名，所以所有的接口请求都会构成跨域。而跨域请求很容易出现由于配置不当被浏览器拦截并报错，这是不能接受的。但图片的src属性并不会跨域，并且同样可以发起请求。 (排除接口上报)

防止阻塞页面加载，影响用户体验

通常，创建资源节点后只有将对象注入到浏览器DOM树后，浏览器才会实际发送资源请求。反复操作DOM不仅会引发性能问题，而且载入js/css资源还会阻塞页面渲染，影响用户体验。但是图片请求例外。构造图片打点不仅不用插入DOM，只要在is中new出Image对象就能发起请求，而且还没有阻塞问题，在没有js的浏览器环境中也能通过img标签正常打点，这是其他类型的资源请求所做不到的。(排除文件方式)