想看埋点数据？产品经理有必要了解的埋点知识（2）

2017-08-15 10:25:00

本文是数据埋点知识系列的第二篇文章，主要分享关于埋点数据的采集、传输、加工、存储、应用和管理等内容。

正如上篇文章所提的，埋点是互联网公司获取数据信息的重要方式。数据的全流程一般涉及到采集、传输、加工、存储、应用等过程。下面就将按照这个顺序，对埋点全流程进行说明。最后，加入了一个埋点系统设计者对埋点管理过程的理解，期待同行的交流~

采集过程：

上文提到了埋点信息采集的方式，那么具体埋点信息采集的过程是怎么样的呢？

以H5网页某页面曝光埋点为例子，先讲一下网页页面展现的流程。框图如下：

具体细节如下：

用户点击或输入某页面链接。
APP客户端或浏览器向服务器发送HTTP请求。该请求内容一般包括请求的URL、请求方法、请求报头（一些必要的内容例如用户cookie等）、请求内容。
服务器接受HTTP请求，进行解析，并将内容返回给客户端或浏览器。返回内容一般包括返回状态（是否成功，例如著名的404就是在这里进行添加的），返回具体内容（请求的网页中包含的内容如图片等），返回报头（cookie等）
客户端或浏览器对返回内容进行解析，并把内容展示给用户。

这样就完成了一个页面的曝光展示。如果对该曝光事件加上埋点，前两步是没有影响的，在第三步：服务器在返回HTTP内容时，会加入一段与埋点相关的脚本代码（如上文埋点方式部分所说，这段代码可能是手动埋点写入的，也可能是半自动或全自动埋点方式写入的）。

客户端或浏览器解析到这部分内容时，会向埋点日志接收服务器（以下简称埋点服务器）发送一个请求。这个请求中即带有我们通过埋点想获得的宝贵的数据信息。埋点服务器接受到请求后，会返回一个已接收的信息给客户端。同时，埋点服务器会将这些信息传输到后续环节。如下图：

这里再说一下和数据准确性有关的内容。在客户端向埋点服务器发送信息的过程中，可能存在丢包，即数据发送失败信息没有传输过去的情况。该发送过程一般通过POST格式，发送JSON串信息，具体方式分两种：一种是单条发送；一种是在本地打包成zip包，积累一定量后发送。两种方式中，zip的丢包情况更严重些。所以PM在看数据时候，也应当清楚，数据会有一定误差。（据作者实践经验，单条POST格式数据误差一般不超过2%）

传输流程：

埋点数据产生之后，被埋点服务器接收，有些时候会进行解析操作，然后会通过消息订阅通道例如kafka之类进行消息的分发，进入离线或实时的储存中，用于后续的计算和分析。

加工和存储过程：

加工：经过加工存储这一步后，埋点数据基本可以从收集到的原材料状态变为可以为业务服务的有用数据了。上文提到，埋点数据都是一条一条，是用户触发埋点对应事件时上传的。

这些数据可能包括：用户会话id，用户id，当前页面编码，当前事件编码，触发时间，用户设备id，ip信息等，这些零散的信息需要通过加工处理进行聚合，变成更加通用常用的数据，便于后续调用。

例如一些通用的处理：针对APP首页曝光事件，选取当日首页曝光事件上传的数据条数，对用户id去重并加和即可以得到当日的UV。

存储：对于离线存储来说，埋点原始数据会以表（类似excel表）的形式存储于数据仓库的原始数据层，经过上述处理过的数据，会以另外一张表的形式存储于数据仓库的汇总层。如果数据仓库建设比较完善，通用的业务数据，直接从汇总层甚至更上层的应用层中取即可，而不必再去取原始层的埋点数据，省去了每次计算的工作量。

应用过程：

任何需要用户行为数据的场景，可能都能用到埋点信息。埋点数据可以用来计算页面的UV/PV、控件的点击PV/UV等基础数据，按照不同维度进一步加工可得APP的日活月活；也可以计算页面停留时间，流失率等；更为复杂一些，通过当前事件和上一事件间的关系（需要在埋点中定义），可以绘制出用户的行为路径图，计算漏斗转化率等等。

这些业务上的应用实现：

大一点的公司可能有自己的可视化工具，直连到数据仓库应用层中已经加工聚合过的埋点数据并进行可视化展示；
有些公司可能需要BI人员使用tableau等可视化工具，写SQL跑数据去处理数据仓库中较为原始的埋点数据，然后得以展现。

如果是后者，需要BI人员的排期，则周期会比较长。

对于实时的数据源，还有开源的grafana、kibana等可视化工具可以利用进行展示，但使用门槛较高，PM等非技术人员上手比较困难。

埋点管理过程：

最原始的埋点管理方式是用文档或表格记录下来埋点的编码命名、业务含义及其他必备信息，在埋点业务方内部共享即可。

但当公司的产品越做越多越做越大，相应的埋点就会越多（多达成千甚至上万）。对互联网规模企业，管理大量埋点往往也需要配套的工具：埋点信息管理系统。

埋点信息管理系统主要有的功能：

提供埋点信息的录入功能。
记录各埋点是否存在，进行埋点层级管理。因为埋点较多，往往需要按照APP-页面-控件的层级进行分类、记录和查询。
展示并可查询某埋点的详细信息。例如物理编码信息和对应的业务含义信息，埋点的上线版本和时间，埋点管理员责任人，埋点信息储存的数仓表名称以及必要的埋点数据结构体（对个性化埋点可能出现的上传数据中新加字段的解释）。
辅助功能。如埋点数据量的监控，埋点信息预览，埋点数据通用分析及可视化展示等。

埋点管理是建立在埋点生成、传输、储存等过程的基础之上的。管理的重点和难点，在于大量埋点物理编码（命名编码）和业务含义的对应。这个对应是将不可读的英文编码字段和易于理解的汉语业务含义连接起来的过程。对应可能是一对多，多对一，甚至多对多的。

1.对应过程在手动埋点中，反应在PM与开发沟通及开发具体埋点行为中。首先PM需要根据业务含义，选择要埋的点并取或生成一个物理编码；之后开发按照这个对应关系，将物理编码写入到业务含义对应的页面或事件上。这个过程是抽象且容易出错的。

2.对应过程在全自动埋点中，反应在PM和开发沟通并“认领”自动埋点的行为中。PM需要向开发了解，已经存在的某物理编码代表的是什么意思即其业务含义是什么，然后将这两者关联。往往还需要将IOS和安卓两个不同的物理编码关联到同一业务含义上，因为这两个物理编码实际就是同一页面或控件。这个过程，也是抽象易错的。

抽象易错，主要是因为需要凭脑中想象将两种文字编码级的内容进行关联。上文提到的可视化埋点则可通过直观的APP展现，显示出物理编码及业务含义，解决抽象的问题。伴随着产品迭代埋点数目增长，似乎有效的可视化埋点是大公司做埋点管理有必要尝试的方向。

文/Chase

关键字：产品经理, 埋点

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击举报进行投诉反馈！