.jpeg)
数据收集原理分析
简单来说，网站统计分析工具需要收集到用户浏览目标网站的行为（如打开某网页、点击某按钮、将商品加入购物车等）及行为附加数据（如某下单行为产生的订单金额等）。早期的网站统计往往只收集一种用户行为：页面的打开。而后用户在页面中的行为均无法收集。这种收集策略能满足基本的流量分析、来源分析、内容分析及访客属性等常用分析视角，但是，随着Ajax技术的广泛使用及电子商务网站对于电子商务目标的统计分析的需求越来越强烈，这种传统的收集策略已经显得力不能及。
后来，Google在其产品谷歌分析中创新性的引入了可定制的数据收集脚本，用户通过谷歌分析定义好的可扩展接口，只需编写少量的JavaScript代码就可以实现自定义事件和自定义指标的跟踪和分析。目前百度统计、搜狗分析等产品均照搬了谷歌分析的模式。
其实说起来两种数据收集模式的基本原理和流程是一致的，只是后一种通过JavaScript收集到了更多的信息。下面看一下现在各种网站统计工具的数据收集基本原理。
1 第三方统计工具
第一种是直接使用友盟、百度统计这样的第三方统计工具，通过嵌入 App SDK 或 JS SDK，然后就可以看统计数据了。这种方式的好处是简单、免费，因此使用非常普及。对于看一些网站访问量、活跃用户量这样的宏观数据需求，基本能够满足。但是，现在一些订单相关的产品，越来越不满足于看这些宏观统计数据，还想做一些深度的用户渠道转化、留存、多维度交叉分析等操作，这个时候就会发现很难满足。这里的问题倒不是出在分析能力的薄弱，而是出现数据采集的不完整。
通过这种 SDK 只能够采集到一些基本的用户行为数据，比如设备的基本信息，用户执行的基本操作等。但是服务端、数据库中的数据并没有采集，对于一些提交操作，比如提交订单对应的成本价格、折扣情况等信息也没有采集，这样就导致后续的分析成了“巧妇难为无米之炊”。
通过客户端 SDK 还有一个问题就是经常觉得统计的不准，和自己的业务数据库数据对不上，出现丢数据的情况。这是前端数据采集的先天缺陷，因为网络异常，或者统计口径不一致，都会导致数据对不上。
2 使用业务数据库
第二种是直接使用业务数据库做统计分析。一般的互联网的产品，后端都是有业务数据库，里面存储了订单、用户注册信息等数据，基于这些数据，一些常用的统计分析都能够搞定了。这种方式天然的就能分析业务数据，并且是实时、准确的。但不足之处有两点：一是业务数据库在设计之初就是为了满足正常的业务运转，给机器读写访问的。为了提升性能，会进行一些分表等操作。一个正常的业务都要有几十张甚至上百张数据表，这些表之间有复杂的依赖关系。这就导致业务分析人员很难理解表含义。即使硬着头皮花了两三个月时间搞懂了，隔天工程师又告诉你因为性能问题拆表了，你就崩溃了。二是业务数据表的设计在于高并发低延迟的小操作，而数据分析常常是针对大数据进行批量操作，这样就导致性能很差。
3 通过 Web 日志
第三种是通过 Web 日志进行统计分析。这种方式相比基于业务数据库的方式，完成了解耦，使业务运行和统计分析两个数据流相分离。这里的问题是打印日志往往是工程师顺便搞搞，完全是以 Debug 的需求来打印日志字段，但在业务分析上，往往发现缺斤少两。并且从打印日志到处理日志到输出统计结果，整个过程很容易出错，我在百度就花了几年的时间解决这一问题。
以上三种方式都多多少少解决了一部分数据采集的问题，但又都解决的不彻底。
存在问题
一般数据采集有点很多，每次数据产品经理提了数据采集的需求，工程师就会按照要求给做了，然后交给数据产品经理去验证。数据产品经理在试用的时候也感觉不到异常，可等上线之后，发现埋的不对，再进行升级发版操作，整个效率就比较低了。一个公司发展到一定程度，没有专人去负责埋点管理工作，数据采集完全没有准确性可言。还有产品上线之后，才发现数据采集的工作没有做，也就是漏埋了。
于是数据相关的同学甚至管理者都在幻想，既然埋点这么容易出问题，有没有不埋点就可以解决所有问题？这就像寻找可以祈求风调雨顺的神灵。百度曾经做了一个产品，只要页面上嵌入 SDK，就可以采集下来页面上所有的点击行为，然后就可以绘制出用户点击的热力图，这种方式对于一些探索式的调研还是比较有用的。后来国外的Heap Analytics，把这种方式更近一步，将 App 的操作尽量多的采集下来，然后通过界面配置的方式对关键行为进行定义，这样就可以不用工程师的配合就可以完成数据采集操作了，这是其中的一个优点。这里要说明的是，要使用这种方案，必须在产品里实现嵌入 SDK，等于做了一个统一的埋点，所以“无埋点”这种叫法本身就不严谨，这种方式更像是“全埋点”。
这种方式只能是进行前端的数据采集，后端服务器和数据库中的数据，依旧是无可奈何的。即使进行前端的数据采集，也不能够进行细粒度的数据采集。比如对于提交订单操作，订单的运费、成本价格之类的维度信息，等于都丢失掉了，只剩下提交这么一个行为类型。
对于非技术人员，容易被这种方式的名称和直接优势所吸引，但很快又会发现许多深度数据分析需求无法直接满足，进而有种被忽悠的感觉，会感到失望。原理的关键点：一是事先在产品上埋一个 SDK，二是通过可视化的方式，生成配置信息，也就是事件名称之类的定义，三是将采集的数据按照配置重命名，进而做分析。
埋点和无埋点
用户行为数据收集技术主要有两种：埋点和无埋点
1 埋点
所谓埋点就是为了数据分析的需求在原本的复杂的代码逻辑之上在加上N行获取数据的代码。比如如果想获取某商品的点击数量，就得在点击事件的中搜集点击的商品数据，发出包含商品名称和点击事件的数据（{productname,clicktime}）。
1.1 埋点的优势
1）埋点最大的优势就是数据都是手动编码产生的，灵活性比较大，可以更好得支持一些扩展数据。
2）埋点由于是按照埋点逻辑进行的预处理，所以对之后的分析友好，分析效果也比较好。
1.2 埋点的劣势
1）埋点最重要的前提条件是必须十分清楚目标，即需要收集什么样的数据必须提前确定。所以埋点最容易出现的问题就是漏埋，一般来说在发布前一定要经过谨慎的校验和测试，因为一旦版本发布出去而数据采集出了问题。
2）在产品的迭代过程中，如果代码再迭代的时候忽略了埋点逻辑的更改，从而导致后续的分析逻辑不准，甚至导致产品bug。更甚于对于产品迭代比较快的场景，埋点就是一个定时炸弹。
2 无埋点
埋点技术和无埋点技术都需要在原有的业务代码上进行改动。无埋点就是通过编程语言自身的特点来完成数据收集的自动化过程。比如前台无埋点其实就是通过监听JS事件，把页面上发生的所有事件都采集下来。后台无埋点实现比较复杂，但是说起来很简单，其实就是将网络数据进行旁路反解析，前后端交互的数据肯定都会经过网络，所以网络中应该包含了绝大多数业务数据。
2.1 无埋点的优势
1) 相对于埋点方式带来的收益就是正好就是埋点容易产生的问题，由于采集的是全量数据，所以产品迭代过程中是不需要关注埋点逻辑的，也不会出现漏埋、误埋等现象。
2）无埋点方式因为收集的是全量数据，可以大大减少运营和产品的试错成本，试错的可能性高了，可以带来更多启发性的信息。
3）最后一点，也是最清楚的一点，就是减少了因为人员流动带来的沟通成本。
2.2 无埋点的缺陷
无埋点的缺陷，也是无埋点存在的一些质疑点：
1）适用大部门，通用的场景，有少部分需要埋点的场景覆盖不了。
2）无埋点采集全量数据，给数据传输和服务器增加压力
根据前面关于埋点和无埋点的科普，我们都明白其实两个方式都有其自身的优势和缺陷，知乎和其他技术博客上关于这两个讨论点的文章也有很多，有人在批埋点，有人在批无埋点。关于技术，我们还是理性看待吧，它们两个不是你死我活的关系，通过我们调研的得到的情况是，目前没有方案能够完美解决无埋点问题，但是我们致力于研究最大限度通过通用方式解决埋点问题，尽量减少埋点代码，埋点代码越少，出错的可能性就越低。我们选择使用前台无埋点和后台无埋点技术相结合的方式来获取用户数据。
