前言
本系列的技术文章不涉及实现细节，仅探讨实现思路。由于数据仓库不仅仅是一个理论概念，其数据质量等原则包含了大量的技术实现细节，因此从数据采集开始，到数据处理，至最终的数据展现，都需要进行原理上和实现上的思路分析，才能保证最终数据仓库理论的完整实现。另外，需要强调的是，本系列文章非原创，是笔者多年从业经历的一种思路整理，对于日常理解数据仓库的实现有着很大的帮助，因而用到了非常多其他文章的引用，并介绍很多业界的好用工具及优秀做法。
一、技术路线图
二、Web端日志采集的业务概述
Web端数据采集主要通过三种方式实现：服务器日志、URL解析及JS回传，详情如下：
- 服务器日志 ，指Web服务器软件，例如Httpd、Nginx、Tomcat等自带的日志，例如Nginx的access.log日志等。
- URL解析 ，指访问服务器时，将URL信息及携带的参数进行解析后，上传服务器，例如访问百度首页：https://www.baidu.com/s?ie=utf-8&wd=你好，我们可以获得本次访问的word为“你好”。
- JS回传 ，指在Web页面上添加的各类统计插件，通过在页面嵌入自定义的Javascript代码来获取用户的访问行为(比如鼠标悬停的位置，点击的页面组件等)，然后通过Ajax请求到后台记录日志。
浏览器的日志采集种类可以分为两大类：
- 页面浏览日志 ：别名为“展现日志”；指当一个页面被浏览器加载时所采集的日志，该类型为最基础的互联网日志，也是PV及UV统计的基础。
- 页面交互日志 ：别名为“点击日志”；指当页面加载和渲染完成后，用户可以在页面上执行的各类操作，以便量化感知用户的兴趣点。
除此之外，还有一些针对特定场合统计的日志，例如页面曝光时长日志、用户在线操作监控等，但原理都基于上述两类日志，只是在统计上有所区分。
Web端重要指标主要包括三个部分：
- 页面浏览 ：PV、UV、IP、跳出率、平均访问时长、转化次数等。
- 页面交互 ：搜索词、控件点击、页面跳转等。
- 其他 ：转化路径分析、设备分析、访客分析、系统环境、地域分布等。
三、Web端日志采集流程
目前典型的网页访问过程是以浏览器请求、服务器响应并返回所请求的内容为主，主要传输HTML文档，浏览器和服务器之间的通信普遍遵守HTTP协议，并逐渐过渡到最新的HTTP2.0版本。一次典型的访问过程由如下几部分组成：
- 用户在浏览器中点击网页链接。
- 浏览器在执行时，会解析用户请求内容，并按照HTTP协议中约定的格式将其转化为一个 HTTP请求 发送出去。
- 服务器按照业务逻辑处理本次请求，并按照 HTTP协议规定 的格式，将响应结果返回浏览器。
- 浏览器收到服务器相应内容，并将其按照文档规范展现给用户。
在实际的处理过程中，前三步是无法采集用户的浏览日志，采集主要在第四步，也就是浏览器解析文档时才能进行。因此可以很自然的想得到，HTML文档中适当位置增加一个日志采集节点，当浏览器解析到这个节点时，便会发出一个特定的HTTP请求到日志采集服务器，日志采集服务器接收到请求时，便可以确定浏览器已经成功接收和打开了页面。目前业界常见的日志采集方案，只是在实现的细节上有所不同，原理都是相通的。
但只统计页面流浪是不能满足业务需求的，很多场合下用户的具体行为特征也需要采集，因为往往会在特定的位置添加一个JS空间，当用户在页面上执行某个行为时，便会触发一个异步请求，按照约定的格式向日志服务器发送点击、等待、报错等交互行为。
四、Web端日志的清洗和预处理
在大部分场合下，直接收到的日志不能提供给下游使用，只能作为ODS基础日志进行保存，由于大数据平台的半结构化特征要求，需要进行一些修正，转化为DWD基础日志才可以使用，具体原因有如下几种：
- 反作弊、反爬虫、反攻击要求 ：由于Web端日志是互联网行业大数据分析的基础数据源，在实际业务场景下，往往会包含比例不小的恶意攻击行为，例如流量作弊、爬虫抓取、流量攻击等，导致日志相关统计指标发生明显的偏差。为此需要进行日志合法性的校验，并由专门的团队来处理相关攻击，这是一个长期而艰苦的过程。
- 数据项修正 ：为了保证后续日志应用的统计口径统一，往往需要对日志中一些公用且重要的数据值做归一、标准化处理或反向补正。例如用户登录后，需要对登录前的日志做身份信息回补、例如当金额信息因为部分原因出现负值时，需要人工进行补正操作，等等。
- 无效数据剔除 ：在很多情况下，因为业务变更等原因，会导致采集到的非常多的无意义数据，在特定统计情况下会干扰最终指标的实现。要知道，很多运营对于哪怕一个百分点都要扣的非常仔细，如果发现因为一些无效数据导致KPI发生了偏差，结果会非常不妙。为了避免此类异常的发生，需要定时更新处理代码，以处理掉已经不需要的统计日志。
- 日志隔离分发 ：如果团队规模变得非常庞大时，很多数据，例如实际金额等，就不可能全部对外公开了，需要走特殊的采集流程，以保障数据的安全和隐私。
五、漏斗模型简介
Web端的分析经常用到的模型为：漏斗模型。这里介绍漏斗模型，对于理解一些常见的统计方式有比较好的帮助，例如淘宝SPM体系，当你熟悉和了解之后，会发现它真的很好用。
漏斗模型全称为“ 搜索营销效果转化漏斗 ”，对应了企业搜索营销的各个环节，反映了从展现、点击、访问、咨询，直到生成订单过程中的客户数量及流失。从最大的展现量到最小的订单量，这个一层层缩小的过程表示不断有客户因为各种原因离开，对企业失去兴趣或放弃购买。可以说，互联网商业价值的体现，与漏斗模型有着直接的关联关系，因此也是一系列技术实现及数据分析的重点。
漏斗模型是一个线性流程，从开始到结束，用户在每一个环节，都会产生流失，就像漏斗一样。以电商为例，最常见漏斗模型就是：浏览/搜索-加购-下单-支付-复购，因此对于统计数据而言，找出用户购买一个商品的搜索过程，来反思用户的行为，就显得十分有必要。数据人要做的工作，就是整理出路径中各个环节的数据，考虑用户流失的因素，进行对应的优化，或者通过缩短用户路径来优化产品体验。其实不论在电商平台、招聘平台、广告平台等常见的互联网业务模式中，漏斗模型始终是数据分析工作的重点。这里通过一个图来理解漏斗模型的商业价值：
但说实话，很多公司在数据统计上，可能并没有这么强的需求来搭建一个完整的平台，也有很多公司想从不同的地方来看一看自己的数据是否准备，这 时 大家都会选择Google GA来进行统计或者是对比数据。 公司的统计往往是两条线，一条是自有线的统计，另一条便是发给Google GA来进行对比分析。 因此在统计平台的功能设置上，经常要与Google GA对标，因此数据仓库不仅是一个过程的搭建，还有很多固有的业务逻辑在其中。
六、淘宝SPM码
漏斗模型比较优秀的应用案例为 淘宝SPM码 。查看淘宝网页的源代码会经常看到http://detail.tmall.com/item.htm?id=XXX&& spm=2014.123456789.1.2 这样的例子，这是淘宝提供的SPM是淘宝社区电商业务（xTao）为外部合作伙伴（外站）提供的一套跟踪引导成交效果数据的解决方案。简单说来， SPM编码 是一种 用来跟踪页面模块位置的编码，标准spm编码由4段组成，采用a. b.c.d的格式（建议全部使用数字），其中：
- a代表站点类型 ，对于xTao合作伙伴（外站），a为固定值，a=2014。
- b代表外站ID （即外站所使用的TOP appkey），比如您的站点使用的TOP appkey=123456789，则b=123456789。
- c代表b站点上的频道ID ，比如是外站某个团购频道，某个逛街频道，某个试用频道等。
- d代表c频道上的页面ID ，比如是某个团购详情页，某个宝贝详情页，某个试用详情页等。
完整的SPM四位编码能标识出某网站中某一个频道的某一个具体页面。比如xTao合作伙伴（a=2014）中某个外站appkey为123456789（b=123456789），频道ID为1（c=1），页面ID为2（d=2），那么spm=2014.123456789.1.2，就唯一标识外站123456789的频道1上的页面2，从这个页面点击出去的链接，后面都应该携带spm=2014.123456789.1.2的参数串。这样，通过这个编码，我们就能唯一的定位到一个url是由外站中哪个具体页面点击生成的。
因为spm编码本身是有层次的，因此，我们可以：
- 单独统计spm的a部分 ，我们可以知道某一类站点的访问和点击情况，以及后续引导和成交情况。
- 单独统计spm的a.b部分 ，我们可以用来评估某一个站点的访问和点击效果，以及后续引导和成交情况。
- 单独统计spm的a.b.c部分 ，我们可以用来评估某一个站点上某一频道的访问和点击效果，以及后续引导和成交情况。
- 单独统计spm的a.b.c.d部分 ，我们可以用来评估某一个频道上某一具体页面的点击效果，以及后续引导和成交情况。
基于SPM可以得到的效果统计指标：
- PV ：通过指定spm编码引导到宝贝详情页面的PV。
- UV ：通过指定spm编码引导到宝贝详情页面的UV。
- 支付宝成交人数 ：通过指定spm编码引导到宝贝详情页面的用户当天对同店商品的支付宝成交人数。
- 转化率 =支付宝成交人数/UV，代表通过指定spm编码引导的用户最终转化为购买用户的比率。
七、客户端日志采集
与网页日志对应的，是手机应用为基础的客户端日志，由于早期手机网络通讯能力较差，因而SDK往往采用 延迟发送 日志的方式，也就是将日志统计在本地，然后选择在Wifi环境下上传，因而往往会出现统计数据延迟的情况。现如今网络环境好了很多，4G、5G流量充足，尤其是视频类APP基本上都是一直联网，因而很多统计能够做到实时统计。
客户端的日志统计主要通过SDK来完成，根据不同的用户行为分成不同的事件，“事件”是客户端日志行为的最小单位，根据类型的不同，可以分为 页面事件 （类比页面浏览）和 控件点击事件 （类比页面交互）。
页面事件的统计主要统计如下三类信息：
- 设备及用户的基本信息 ，例如IMEI、用户账号等。
- 被访问页面的信息 ，例如商品ID、浏览店铺等。
- 访问的路径信息 ，例如上一个页面来源等。
与Web日志采集类似的是，交互日志的采集同样无法规定统一的采集内容，除了记录基本的设备信息和用户信息外，很多统计的方式是可以由业务方自定义统计的，也就是根据业务需求的不同，产品在配置平台上自定义一个统计项，下次SDK更新时便可以加入统计项，自主看到统计内容，便于自动化的管理运维。但在每个事件上，会提供一些额外的统计信息，例如事件名称、事件时长、事件属性、事件页面等。
八、客户端日志的聚合
由于事件的统计涉及到很多参数，基本上是一个行为能够产生一条日志，不仅客户端会产生大量的记录数据，对于服务端的接收通常会产生很大的流量负担。因此统计SDK往往会有聚合和压缩的功能，对于一些展现场景，可以适当的合并日志，以减少数据量。例如在淘宝等APP中，一次商品页的浏览会产生上百条日志，从下游分析的角度来看，只需要知道哪些内容被曝光了即可，因此完全可以在一条日志中记录曝光的ID，而无需每个都统计一遍。
还有一种场景，因为APP存在回退的情况，因此在访问路径的分析中，往往会产生干扰统计，因此在统计时需要添加一些特殊的标识，来鉴别该行为是否属于回退行为。
九、统计SDK
市面上最常见的，如 友盟 、Talkingdata、百度统计、腾讯云分析、GA等第三方统计服务提供商，也诞生了很多在某些分析方面更加专一、深入的统计服务商，比如诸葛io、growingio、神策等，看自己需求进行配置。
十、唯一设备标识符
在客户端的相关统计中，如何鉴定一个用户是非常难的，因为网页有统一的Cookie来进行识别，但客户端并没有。历史上， IMEI、IMSI、MAC地址 、苹果禁用之前的UDID，都可以用，但由于用户自我保护意识的提高及系统的升级，很多基本的设备信息都难以获取到了，Android也进行了设备信息获取的限制。对于单个App的公司来说，识别唯一用户并不是难事，但对于多App的公司来说，这一点就尤为重要，也这是业界难题。
十一、H5与Native的统一
App有两种类型，一种是纯 Native 的App，另一种是既有Native，也有 H5 页面嵌入的App，目前大部分的App都是两者兼有的状况。Native页面的数据统计主要通过SDK进行，但H5页面的数据统计还是基于浏览器的页面日志来进行，由于采集方式的不同，很多情况下两个页面互相跳转时，便无法还原用户访问路径，对于数据的统计分析产生很严重的影响。解决的思路有两种，一种是Native日志归拢到H5日志中，另一种是H5日志归拢到Native日志中，但综合考虑，归拢到Native日志更为合理，因为SDK能够采集更为全面的日子信息。具体实现方式上，可以在H5页面中嵌入JS代码，通过调用WebView框架中的JSBridge接口，来实现参数的传入，并由统计SDK进行日志的封装。当然方法不是万能的，有其他的好方式也可以尝试。
十二、大促保障
大促保障指在双十一等类似场景下，流量短时间内保障的情况，需要对系统进行一定的改造。在高并发场景下，从数据的埋点采集，到日志服务器的收集，再到数据传输，再到数据的分析和统计，任何一个环节出现问题，大促保障就是失效的。由于日志处理的链路非常长，因此可以通过限制流量、消息队列削弱峰值、异步处理、内存缓冲、扩展服务等方式进行，在日志采集环节中，可以通过延迟非核心日志上传的方式，优先处理核心日志，以保障统计效果。在天猫双十一中，可以经常看到暂停部分服务的通知，便是这种方式的实现。
