浏览器的页面日志采集

1 概述

浏览器的页面日志采集分两大类：页面浏览日志采集、页面交互日志采集。

1.1 页面浏览日志采集

1. 页面浏览日志采集指采集当一个页面被浏览器加载呈现时的日志；
2. 此类日志是最基础的互联网日志，也是当前所有互联网产品的两大基本指标：页面浏览量（Page View，PV）和访客数（Unique Visitors，UV）的统计基础；
3. 页面浏览日志是目前成熟度和完备度最高、同时也是最具挑战性的日志采集任务；

1.2 页面交互日志采集

1. 当页面加载和渲染完成后，用户可以在页面上执行各类操作；
2. 随着前端技术的发展，用户在浏览器上与网页的互动越来越丰富，互动设计要求用户的互动行为数据，以便通过量化获知用户的兴趣点和体验优化点；
3. 交互日志采集就是因此类业务场景而生的；

2 页面浏览日志采集流程

2.1 页面访问过程

概述

1. 典型的页面访问过程是以浏览器请求、服务器响应并返回所请求的内容（大多以HTML文档的形式）这种模式进行的；
2. 浏览器和服务器之间的通信普遍遵守HTTP协议（超文本传输协议，目前以HTTP1.1为主，逐渐向最新的HTTP2.0过渡）；
3. 浏览器发起的请求被称为HTTP请求（HTTP Request），服务器的返回则被称为HTTP响应（HTTP Response);

示例：访问淘宝首页

1. 用户在浏览器内点击淘宝首页链接（或在地址栏输入www.taobao.com并回车);
2. 浏览器向淘宝服务器发起HTTP请求。在本例中，用户可以看见的内容只是显示在浏览器地址栏内的http://www.taobao.com，而浏览器在执行时，会解析用户请求并按照HTTP协议中约定的格式将其转化为一个HTTP请求发送出去，一个标准HTTP请求由以下三部分构成：
   1. 请求行（HTTP Request Line）：请求行内有三个要素，分别是请求方法、所请求资源的URL及HTTP协议版本号。在本例中，三者分别是GET、http://www.taobao.com/以及HTTP1.1；
   2. 请求报头（HTTP Message Header):请求报头是浏览器在请求时向服务器提交的附加信息，请求报头一般会附加很多内容项，每项内容被称为一个头域（Header Field)。如果用户在本次页面访问之前已经到访过网站或者已经登录，则一般都会在请求头中附加一个或多个被称为Cookie的数据项，其中记录了用户上一次访问时的状态或身份信息；
   3. 请求正文（HTTP Message Body):这部分可选，一般而言，HTTP请求的正文都是空的，可以忽略；
3. 服务器接收并解析请求。服务器端业务处理模块按业务逻辑处理本次请求并按照HTTP协议规定的格式，将处理结果以HTTP响应形式发回浏览器。一个标准的HTTP响应也由三部分组成：
   1. 状态行。状态行标识了服务器对于此次HTTP请求的处理结果，状态行内的主要内容是一个由三位数字构成的状态码，例如代表成功响应的200（OK）和代表请求资源没有找到的404（Not Found);
   2. 响应报头。服务器在执行响应时，同样可以附加一些数据项，这些数据项将在浏览器端被读取和使用，响应报头内的内容在确保页面正确显示和业务正常进行方面发挥着重要作用。其中最重要的一类Header即上面提到的Cookie，浏览器记录的Cookie，其实是由服务器在响应报头内指令浏览器记录的。如果用户在页面登录，则服务器会在登录请求的响应报头内指示浏览器新增一个名为userid的Cookie项，其中记录了登录用户的id。如此一来，当用户随后再次访问该网站时，浏览器将自动在请求报头内附加这个Cookie，服务器由此即可得知本次请求对应的用户是谁；如果服务器发现浏览器在请求时传递过来的Cookie有缺失、错误或需要更新，则会在响应报头内指令浏览器增加或更新对应的Cookie；
   3. 响应正文。浏览器请求的文档、图片、脚本等，就是被包装在正文内返回浏览器的。本例中，服务器会将淘宝首页对应的HTML文档封装在正文内；
4. 浏览器接收到服务器的响应内容，并将其按照文档规范展现给用户，从而完成一次请求。在本例中，浏览器请求淘宝首页，服务器返回对应的HTML文档，浏览器即按照HTML文档规范解析文档并将整个页面渲染在屏幕上。

2.2 日志采集思路

1. 上面描述了一次典型的网页浏览过程，如果需要记录这次浏览行为，则采集日志的动作必然是附加在上述四个步骤中的某环节内完成的。在第一步和第二步，用户的请求尚未抵达服务器；而直到第三步完成，我们也只能认为服务器处理了请求，不能保证浏览器能够正确地解析和渲染页面，尚不能确保用户已确实打开页面，因此在前三步是无法采集用户的浏览日志的。那么采集日志的动作，需要在第四步，也就是浏览器开始解析文档时才能进行；
2. 思路：在 HTML 文档内的适当位置增加一个日志采集节点，当浏览器解析到这个节点时，将自动触发一个特定HTTP 请求到日志采集服务器。如此一来，当日志采集服务器接收到这个请求时，就可以确定浏览器已经成功地接收和打开了页面。

2.3 日志采集方案

1. 客户端日志采集。日志采集工作由一小段被植入页面HTML 文档内的JavaScript 脚本来执行。采集脚本被浏览器加载解析后执行，在执行时采集当前页面参数、浏览行为的上下文信息（如读取用户访问当前页面时的上一步页面）以及一些运行环境信息（如当前的浏览器和分辨率等）。在 HTML 文档内植入日志采集脚本的动作可以由业务服务器在响应业务请求时动态执行，也可以在开发页面时由开发人员手动植入；
   
2. 客户端日志发送。采集脚本执行时，会向日志服务器发起请求，以将采集到的数据发送到日志服务器。在大多数情况下，采集完成之后会立即执行发送；但在个别场景下，日志采集之后可能会经过一段时间的延迟才被发出。日志采集和发送模块一般会集成在同一个JavaScript 脚本文件内，且通过互联网浏览器必然支持的 HTTP 协议与日志服务器通信，采集到的日志信息一般以 URL 参数形式放在 HTTP日志请求的请求行内；
3. 服务器端日志收集。日志服务器接收到客户端发来的日志请求后，一般会立即向浏览器发回一个请求成功的响应，以免对页面的正常加载造成影响；同时，日志服务器的日志收集模块会将日志请求内容写入一个日志缓冲区内，完成此条浏览日志的收集；
4. 服务器端日志解析存档。服务器接收到的浏览日志进人缓冲区后，会被一段专门的日志处理程序顺序读出并按照约定的日志处理逻辑解析。由日志采集脚本记录在日志请求行内的参数，将在这个环节被解析（有时候伴随着转义和解码）出来，转存入标准的日志文件中并注入实时消息通道内供其他后端程序读取和进一步加工处理；

3 页面交互日志采集流程

1. PV日志的采集解决了页面流量和流量来源统计的问题，但随着互联网业务的发展，仅了解用户到访过的页面和访问路径，已经远远不能满足用户细分研究的需求；
2. 在很多场合下，需要了解用户在访问某个页面时具体的互动行为特征，比如鼠标或输入焦点的移动变化（代表用户关注内容的变化）、对某些页面交互的反应（可借此判断用户是否对某些页面元素发生认知困难）等；
3. 由于这些行为往往并不触发浏览器加载新页面，所以无法通过常规的日志采集方法来收集；
4. 阿里通过一套名为“黄金令箭”的采集方案来解决交互日志的采集问题；
5. 因为终端类型页面内容、交互方式和用户实际行为的千变万化不可预估，交互日志的采集和日志的采集不同，无法规定统一的采集内容，呈现出高度自定义的业务特征。与之相适应，在阿里巴巴的日志采集实践中，交互日志的采集（即“黄金令箭”）是以技术服务的形式呈现的；

具体而言，“黄金令箭”是一个开放的基于 HTTP 协议的日志服务，需要采集交互日志的业务（下文简称“业务方”），经过如下步骤即可将自助采集的交互日志发送到日志服务器：

1. 业务方在“黄金令箭”的元数据管理界面依次注册需要采集交互日志的业务、具体的业务场景以及场景下的具体交互采集点，在注册完成之后，系统将生成与之对应的交互日志采集代码模板；
2. 业务方将交互日志采集代码植入目标页面，并将采集代码与需监测的交互行为做绑定；
3. 当用户在页面上产生指定行为时，采集代码和正常的业务互动代码一起被触发和执行；
4. 采集代码在采集动作完成后将对应的日志通过 HTTP 协议发送到日志服务器，日志服务器接收到日志后，对于保存在 HTTP 请求参数部分的自定义数据（即用户上传的数据），原则上不做解析处理，只做简单的转储；
5. 经过上述步骤采集到日志服务器的业务随后可被业务方按需自行解析处理，并可与正常的 PV 日志做关联运算；

4 页面日志的服务器端清洗和预处理

上面介绍了阿里巴巴的两类浏览器页面日志的采集方案，并粗略介绍了日志到达日志服务器之后的解析处理。但在大部分场合下，经过上述解析处理之后的日志并不直接提供给下游使用。基于如下几个原因，对时效要求较宽松的应用场合下，一般还需要进行相应的离线预处理：

1. 识别流量攻击、网络爬虫和流量作弊（虚假流量）。页面日志是互联网分析和大数据应用的基础源数据，在实际应用中，往往存在占一定比例的虚假或者恶意流量日志，导致日志相关指标的统计发生偏差或明显谬误。为此，需要对所采集的日志进行合法性校验，依托算法识别非正常的流量并归纳出对应的过滤规则集加以滤除。这是一个长期而艰苦的对抗过程；
2. 数据缺项补正。为了便利后续的日志应用和保证基本的数据统计口径一致，在大多数情况下，需要对日志中的某些公用且重要的数据项做取值归一、标准化处理或反向补正。反向补正，即根据新日志对稍早收集的日志中的个别数据项做回补或修订（例如，在用户登录后，对登录前页面日志做身份信息的回补）；
3. 无效数据剔除。在某些情况下，因业务变更或配置不当，在采集到的日志中会存在一些无意义、已经失效或者冗余的数据项。这些数据项不仅消耗存储空间和运算能力，而且在偶然的情况下还可能干扰正常计算的进行。为了避免此类异常的发生，需要定时检查配置并依照配置将此类数据项剔除；
4. 日志隔离分发。基于数据安全或者业务特性的考虑，某些日志在进入公共数据环境之前需要做隔离；

原始日志经过上述的清洗、修正，并结构化变形处理之后， Web页面日志的采集流程就算完成了。此时的日志已经具备了结构化或者半结构化的特征，可以方便地被关系型数据库装载和使用。