说说前端数据采集与分析的那些事

说说“手工”、“可视化”、“无”埋点基本原理

● 手动埋点（代码埋点）：手动写代码，调用埋点SDK的函数，在需要埋点的业务逻辑功能位置调用接口上报埋点数据，友盟、百度统计等第三方数据统计服务商大都采用这种方案；需要深入下钻，并精细化自定义分析时，比较适合。此类埋点需要产品和开发反复沟通，埋点容易出现手动差错，如果错误，重新埋点的成本很高。这会导致整个数据收集周期很长，收集成本很高，而且效率很低。

● 可视化埋点（框架式埋点、无痕埋点），解决了纯手动埋点的开发成本和更新成本，通过可视化工具快速配置采集节点（圈点），在前端自动解析配置，并根据配置上传埋点数据，比起手动埋点看起来更“无痕”，这里的配置数据可以设置过滤条件，避免针对所有元素（比如全埋点），可以在调用开启自动监控api时通过设置一些特征属性，来过滤不符合条件的元素，实现只针对某些元素进行自动上报数据的需求； 比如Mixpanel；

● 无埋点（自动埋点、全埋点）：它并不是没有任何埋点，只是不需要工程师在业务代码里面插入代码. 只需要加载了一段定义好的SDK代码。技术门槛更低，使用与部署也简单，避免了需求变更，埋点错误导致的重新埋点。通过这个SDK代码，前端会自动全量采集全部事件并上报埋点数据，能够呈现用户行为的每一次点击、每一次跳转、每一次登录等全量、实时用户行为数据，这些数据传到后端后，可通过用户分群、漏斗对比等功能，分析不同访问来源、不同城市、不同广告来源等多维度的不同转化细节，细而全。问题是自定义属性不灵活，传输时效性差，数据可靠性欠佳，耗费网络流量，并增加服务器负载，而且兼容性也不佳。比如Heap analytics、GrowingIO、神策。

https://www.threejs.online/ 这个站点，我就装了很多SDK。

可视化和无埋点，作为一个手动埋点的深度用户和开发者，可以谈谈常见的痛点：

1、埋点混乱

2、常常埋错，漏埋

3、业务变化后，老埋点数据失去意义

4、埋点数据无人使用，浪费资源

5、数据团队、研发团队、产品团队协作配合难度大

6、很多时候不太重视数据，而是重视业务的快速上线

自动埋点与手工埋点的区别？

根据工作中对埋点的对比和整理，我们汇集一下相关的对比：

1、对于语义明确的UI事件，自动埋点的数据一般会比手动埋点更加准确，更贴近用户行为，也更节省开发成本，侵入性更低。

主要是因为自动埋点语义简单明确，不像手动埋点由于开发习惯、代码风格、人的理解误差、分支处理等各种不确定因素变得没那么清晰明了。

比如：“下单”事件，自动埋点的PV肯定是>=手动埋点的，UV差别可能不大。分析开发代码发现在onClick Listener中包含其他未覆盖到的分支，差别很可能就在代码分支当中。如果更进一步分析下代码可以发现，为什么开发不在分支当中埋点？可能这个分支会认为用户的这一次点击是“无效”的，但这只是程序逻辑的看法，用户可能不这么认为，用户很可能会觉得很奇怪没反应，然后再点一次。这些手动埋点不易察觉的细节，自动埋点都能记录，所以说，自动埋点在这些情况下会更贴近真正的用户行为。

2、自动埋点可降低原来手动埋点的个数和复杂性，使之更简化

比如：进入“商品详情页面”（展现），目前包括5个手动埋点，实际上用自动埋点只需要一个就够了，而且自动埋点不会遗漏。从数据来看，一个自动埋点的PV已经超过5个手动埋点之和。

3、自动埋点可采集界面环境数据，但是数据不够纯，需要进一步去噪

自动埋点能采集到大部分用户“看到的而且有用数据”。比如：“价格”这一属性，手动埋点可直接定义“amout: 5.2“来轻松获取数据，而自动埋点获取的是一串文本： “价格预估5.2元”，若要获取精确的5.2这个数值，就需要进一步解析。

4、自动埋点无法替代手动埋点，但可大大减少手动埋点工作量

可预想的是，在用户行为分析上，自动埋点可以满足很大一部分需求

函数级的埋点无法用自动埋点代替，后台非UI的事件也无法用自动埋点代替，自动埋点无法携带当时的业务场景数据，这些都表明了自动埋点无法完全替代手动埋点。

但单就用户行为分析来讲，自动埋点是可以覆盖用户的一些基本行为路径的，并能做一些较浅层次的分析。如果需要探究用户行为背后的原因、或需要进一步深入分析行为的时候，就是需要更多的后台逻辑事件、需要携带更多属性值的时候，就需要通过手动埋点来完成。所以，但是深层次的分析是你的重点，就需要使用手动埋点来解决。

前端手动埋点的常用方法

埋点技术除了刚才的方式划分，还可以划分为前端埋点和后端埋点，后端埋点数据更可靠、更集中（无需多端）、更实时，前端可以离线运行，因为我们是FE团队，今天也主要是和大家聊聊前端埋点。

前端埋点中的代码手动埋点一般有以下几种：

1、命令式：

$(document).ready(()=>{   // … 业务逻辑   sendData(params); }); // 按钮点击时发送埋点请求 $(‘button’).click(()=>{   // … 业务逻辑   sendData(params); });

senddata就是发埋点数据。

2、声明式：

<button data-mydata=”{key:’uber_comt_share_ck’, act: ‘click’,msg:{}}”>打车</button>

3、前端框架式：

如果我们使用Vue或者React等前端框架，是可以在各个生命周期位置进行你所需的埋点。这里不展开。

4、css埋点：

.link:active::after{        content: url(“http://www.example.com?action=yourdata”);  }

<a class=”link”>点击我，会发埋点数据</a>

上面的截图是Google Analytics的上报内容。

上图是talkingdata的接入代码。

上图是TD的上报内容。

上图是GA的接入。

上图是GA的上报。

local storage和cookie一样，有生命周期，可以把一些任务队列放里面，也可以把一些用户识别的ID放里面。和Cookie的功效有一些相同

企业什么阶段选择自动埋点和可视化埋点？

某些企业，保守估计，手动埋点的错误率可能会高达50%，比如一些简单页面的进入应该埋在 viewDidAppear（didMount…），按钮点击应该埋在 onClickListener等等都经常被开发弄错。埋点工作本身并不难，是纯粹的体力活，但是要展开一个好的埋点工作，需要BI先梳理，然后再传达给RD，然后RD再去开发实现，最后应该经过测试验收，因为没有统一的标准，每个人的理解不一样，就很容易弄错，后面会和大家在详细聊聊埋点规范的问题。

我们了解的一些大公司，像Facebook等硅谷公司已经将埋点看得与产品设计同等重要，新功能还在设计阶段就先把衡量指标及埋点梳理好，而具体负责埋点的RD也是团队中最资深的RD（如果不是专职的话），RD需要每天不断的与BI沟通确保语义一致。

而我负责过的滴滴、陆金所等公司的项目现状是，埋点的RD很多时候都是随机的，甚至经常被安排给实习生，埋点质量难以保证。还有一种情况是产品为了快速上线需求，一味追求上线速度，在需求评审阶段没有梳理和提出埋点需求，上线后临时插入埋点需求，在未经过分析理解和测试验收的情况下匆匆加入埋点代码，而且测试经常也不重视测试（提出免测），导致埋点错误，甚至是业务代码错误等线上问题（后续的埋点规范会更进步一步针对这个问题做分析，并提出方案）。这种情况下自动埋点既能减少沟通开发的工作量，又能降低埋点出错的概率。所以，自动埋点很适合公司在埋点规范没有完全建立，埋点质量普遍不高的阶段。

根据以上的总结，可以看出，手动埋点技术需要在企业的网页或者客户端内写入相应的代码，虽然操作过程会复杂一些，但可以更精准的采集后端模块的数据。例如当用户提交了一个订单，有埋点技术不仅可以采集到“订单提交”这一行为事件，还可以获取到该订单的具体商品类别信息。有埋点的技术的缺点在于，因为目前大多企业在采集数据这一块没有一定的规划，大多都是提出一个需求之后，再写入一定的代码，这样就会容易造成整个埋点铺设混乱，极易出现一些故障。