数据的全流程一般涉及到采集、传输、加工、存储、应用等过程。
-
采集
数据采集
上图完成了一个页面的曝光展示。
如果对该曝光事件加上埋点，前两步是没有影响的，在第三步：服务器在返回HTTP内容时，会加入一段与埋点相关的脚本代码（这段代码可能是手动埋点写入的，也可能是半自动或全自动埋点方式写入的）。
客户端或浏览器解析到这部分内容时，会向埋点日志接收服务器（以下简称埋点服务器）发送一个请求。这个请求中即带有我们通过埋点想获得的宝贵的数据信息。埋点服务器接受到请求后，会返回一个已接收的信息给客户端。同时，埋点服务器会将这些信息传输到后续环节。
数据准确性
在客户端向埋点服务器发送信息的过程中，可能存在丢包，即数据发送失败信息没有传输过去的情况。该发送过程一般通过POST格式，发送JSON串信息，具体方式分两种：一种是单条发送；一种是在本地打包成zip包，积累一定量后发送。两种方式中，zip的丢包情况更严重些。所以PM在看数据时候，也应当清楚，数据会有一定误差。（据作者实践经验，单条POST格式数据误差一般不超过2%）
-
传输流程
传输流程
埋点数据产生之后，被埋点服务器接收，有些时候会进行解析操作，然后会通过消息订阅通道例如kafka之类进行消息的分发，进入离线或实时的储存中，用于后续的计算和分析。
- 加工和存储过程
加工：经过加工存储这一步后，埋点数据基本可以从收集到的原材料状态变为可以为业务服务的有用数据了。埋点数据都是一条一条，是用户触发埋点对应事件时上传的。
这些数据可能包括：用户会话id，用户id，当前页面编码，当前事件编码，触发时间，用户设备id，ip信息等，这些零散的信息需要通过加工处理进行聚合，变成更加通用常用的数据，便于后续调用。
例如：一些通用的处理：针对APP首页曝光事件，选取当日首页曝光事件上传的数据条数，对用户id去重并加和即可以得到当日的UV。
存储：对于离线存储来说，埋点原始数据会以表（类似excel表）的形式存储于数据仓库的原始数据层，经过上述处理过的数据，会以另外一张表的形式存储于数据仓库的汇总层。如果数据仓库建设比较完善，通用的业务数据，直接从汇总层甚至更上层的应用层中取即可，而不必再去取原始层的埋点数据，省去了每次计算的工作量。
数据仓库三层结构
详细的ETL流程
- 应用过程
任何需要用户行为数据的场景，可能都能用到埋点信息。
埋点数据可以用来计算页面的UV/PV、控件的点击PV/UV等基础数据，按照不同维度进一步加工可得APP的日活月活；也可以计算页面停留时间，流失率等；更为复杂一些，通过当前事件和上一事件间的关系（需要在埋点中定义），可以绘制出用户的行为路径图，计算漏斗转化率等等。
