数据运营系列1→数据采集

巧妇难为无米之炊，做数据的尤其如此。在数据采集-处理-存储-分析-可视化的一整套流程中，数据采集作为整个过程的起点，关系到分析结果的准确性，所以尤为重要。

目前市面上数据采集的方式多种多样，让人眼花缭乱。今天我们就来梳理一下数据采集的各种方式，了解一下其内在逻辑和优缺点。

在开始列举之前，我们先来看一看用户获取服务的信息流转过程：

通过以上内容我们可以看出，用户获取服务的过程就是一个用户行为进行传递和反馈的过程。

理想状态下，如果我们想要获取用户行为数据，可以在这个过程中随意找一个点进行监测，都可以获取到相同的结果。

然而实际上却并非如此，因为各种软硬件具有不同的特性和局限，所以我们能监测的点是有限的，并且由于每一个节点的数据传输都有错误的可能，从而导致监测不同节点所获取的数据有所差异。

根据数据采集位置的差异，可以将其分为两类，一类是前端采集，另一类是后端采集。顾名思义，前端采集是采集用户在前端的操作数据，而后端采集是采集后端与前端的交互数据。

两类方法各有优劣。首先，因为前端采集的数据是用户点击、输入类的数据而非用户真正使用某个功能的数据（例如，虽然用户点击了N次提交键，但呈现给用户的结果只有一次），因此从应用性上来说前端数据是不如后端数据的。

其次，因为前端的数据采集是在功能逻辑中添加了统计逻辑，为不妨碍功能逻辑的运行，前端采集数据并非采集到后立即传输给服务器，而是会在客户端暂存起来，在攒够一定量后或网络状态良好时再发送给服务器，因此会存在本地暂存空间有限、传输不及时和数据可靠性上的一些问题。

但是，有些地方前端采集是无法被替代的，例如分析前端界面设计的合理性，分析一些与后端没有交互的前端行为，以及性价比等方面。

从技术方面来说，数据采集的方式有三种，第一种是代码埋点，第二种是可视化埋点也就无埋点或全埋点，第三种是后端日志。

在进行细说之前需要了解，无论是代码埋点还是可视化埋点，想要对一个网站或者app进行用户数据采集，都要在网站的每一页或app中加上一些基础程序代码。这类代码在网站上叫监测代码，在app中叫SDK。

这类基础代码具有一定的数据采集作用，简单讲基础代码可以采集的是那些遵守http（超文本传输协议）的交互，最典型的是网页的链接。通过它我们可以间接推断出一些用户行为数据，至于具体的用户行为数据则无法获取，而代码埋点和可视化埋点无疑弥补了它的缺点。

我们先来说一下代码埋点。代码埋点在埋点位置上有前后端之分，但在技术手段上却并无差别。为了收集到详细的用户互动行为数据，我们需要在前端或后端布置很多监测点，而每一个监测点都需要部署上专用的事件监测代码。这些代码需要专门的人-数据猿，一个个一行行的敲下来，不可以重复不可以敲错，还要和监测事件进行一 一对应。

通过上面的描述我们可以了解到，代码埋点虽然目的性强、准确度高，但却是一种繁琐且成本高的数据采集方式，而可视化埋点在这一方面却是完胜它的。

可视化埋点是一种前端区域的定向监测，即，在页面上直接用鼠标或手指点击我想监测的这些事件所在位置，然后监测系统就能知道并且记录下来这个地方并开始进行自动监测。

它的优点就在于快速部署、快速评估、快速决策，但它的缺点也是显而易见的，例如它无法获取没有具体“地点”的交互，只能机械记录交互发生的次数不能记录交互行为背后的详细信息，并且因为缺少对行为属性的标识而造成对不同监测事件分类汇总的繁琐。

最后要说的是后端日志。日志文件本身是专门用于记录系统操作事件的记录文件，操作系统有操作系统日志文件，数据库有数据库日志文件，这里我们说的后端日志是数据库的日志文件。

日志的主要功能是记录对数据所作的修改，其目的是保护数据库以防故障，所以它并不像代码埋点和可视化埋点那样是专门为了采集所需数据而产生的，由此造成了从日志文件获取标准数据两个难点：一是内容繁杂，很难清理；二是不成体系，很难获取。但它的优点也是有目共睹的，那就是详尽，所以可以作为最后的“粮仓”。

数据采集的方法多种多样，没有绝对的优劣之分，只是看哪一种或哪种组合更能满足你当下的需求符合你未来的期盼。