认识达内从这里开始

埋点是我们在进行数据收集的时候会经常采用的一种方法，今天我们就通过案例分析来了解一下，常见的几种埋点方法都有哪些，希望通过对本文的阅读，大家对于数据收集能够有更多的了解。

1.代码手动埋点

该方案情况下，如果需要埋点，则需要在工程代码中，写埋点相关代码。因为侵入了业务代码，对业务代码产生了污染，显而易见的缺点是埋点的成本较高、且违背了单一原则。

例1：假如你需要知道用户在点击“购买按钮”时的相关信息(手机型号、App版本、页面路径、停留时间、动作等等)，那么就需要在按钮的点击事件里面去写埋点统计的代码。这样明显的弊端就是在之前业务逻辑的代码上面又多出了埋点的代码。由于埋点代码分散、埋点的工作量很大、代码维护成本较高、后期重构很头痛。

例2：假如App采用了Hybrid架构，当App的一版本发布的时候H5的关键业务逻辑统计是由Native定义好关键逻辑(比如H5调起了Native的分享功能，那么存在一个分享的埋点事件)的桥接。假如某天增加了一个扫一扫功能，未定义扫一扫的埋点桥接，那么H5页面变动的时候，Native埋点代码不去更新的话，变动的H5的业务就未被精确统计。

优点：产品、运营工作量少，对照业务映射表就可以还原出相关业务场景、数据精细无须大量的加工和处理

缺点：开发工作量大、前期需要和运营、产品指定的好业务标识，以便产品和运营进行数据统计分析

2.可视化埋点

可视化埋点的出现，是为解决代码埋点流程复杂、成本高、新开发的页面(H5、或者服务端下发的json去生成相应页面)不能及时拥有埋点能力

前端在「埋点编辑模式」下，以“可视化”的方式去配置、绑定关键业务模块的路径到前端可以确定到view的xpath过程。

用户每次操作的控件，都生成一个xpath字符串，然后通过接口将xpath字符串(view在前端系统中的定位。以iOS为例，App名称、控制器名称、一层层view、同类型view的序号：“GoodCell.21.RetailTableView.GoodsViewController.*baoApp”)到真正的业务模块(“宝App-商城控制器-分销商品列表-21个商品被点击了”)的映射关系上传到服务端。xpath具体是什么在下文会有介绍。

之后操作App就生成对应的xpath和埋点数据(开发者通过技术手段将从服务端获取的关键数据塞到前端的UI控件上。iOS端为例，UIView的accessibilityIdentifier属性可以设置我们从服务端获取的埋点数据)上传到服务端。

优点：数据量相对准确、后期数据分析成本低

缺点：前期控件的识别、定位都需要额外开发;可视化平台的开发成本较高;对于额外需求的分析可能会比较困难

3.无痕埋点

通过技术手段无差别地记录用户在前端页面上的行为。可以正确的获取PV、UV、IP、Action、Time等信息。

缺点：前期开发统计基础信息的技术产品成本较高、后期数据分析数据量很大、分析成本较高(大量数据传统的关系型数据库压力大)

优点：开发人员工作量小、数据全面、无遗漏、产品和运营按需分析、支持动态页面的统计分析

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。