返回介绍

7.4 流量采集分析系统的工作机制

发布于 2024-01-27 22:54:28 字数 5950 浏览 0 评论 0 收藏 0

完整的流量采集分析系统的工作机制包括数据采集、数据处理和数据应用三个部分,如图7-1所示。

图7-1 流量采集分析系统的工作机制

数据采集层:包括在线数据和外部数据的采集。

数据处理层:在线数据在采集规则的约束下完成原始数据采集、处理和预运算,同时根据处理规则整合外部接入数据并做整合计算,最终可供外部调用的数据仓库数据或服务数据。

数据应用层:根据外部特定请求以报告、数据源、数据服务、数据API、数据仓库等形式返回结果。

7.4.1 流量数据采集

数据采集层分为两层,第一层是通过特定页面或Activity标记实现在线数据采集,在线数据是网站数据的核心组成;第二层是通过外部系统或手动形式导入的外部数据源,外部数据源是在线数据的拓展。

1.在线数据采集

在线数据采集根据平台可分为WEB站、WAP站和APP站。Web站以及由HTML5开发的WAP站都支持JS脚本采集;较早开发的不支持JS的WAP站则采用NoScript,即一个像素的硬图片实现数据跟踪;SDK是针对APP进行数据采集的特定方法和框架。这三种方法可以实现目前所有线上数据采集需求。数据采集阶段的工作流程如图7-2所示。

图7-2 在线数据采集流程

当点击网站/APP时,用户客户端向网站服务器端发送请求,如①所示。

网站服务器返回请求结果,如②所示。

用户客户端开始加载页面,同时触发特定标记,特定标记将采集到的数据发送到网站分析系统的采集服务器处理,如③所示。

这种客户端-服务器的数据采集方法适用于大多数数据采集需求,但在这种采集方法的前期是页面标记需要在用户客户端触发才能实现,如果数据不是通过客户客户端触发或触发时的数据在网站外部则无法收集。

比如:用户在使用在线支付的过程中,除了企业拥有结算工具意外,大多数网站都需要跳到特定网站如支付宝、网银等完成支付,而在这些支付由于存在于外部网站,无法通过页面标记形式收集支付成功数据,此时这种客户端-服务器端的采集方法失效。

另外,由于数据经历了从网站服务器→用户客户端→采集服务器三个节点,从网站服务器到用户客户端的过程可能会有数据丢失情况,尤其在于订单结算等核心信息上,这种客户端-服务器的采集方法可靠性较小。注意:不管采用何种采集方法,任何网站分析系统的数据都不可能与企业内部数据系统数据完全一致,数据不一致性存在于任何网站分析系统中,对网站分析系统数据准确性的要求是数据误差与企业数据系统误差比例较小(通常在5%以下)且数据误差稳定。

针对上述情况,某些网站分析系统如Webtrekk支持Server to Server即网站服务器对采集服务器的方法进行在线数据采集,这样就避免了数据在客户端的中转流失,如图7-2中④所示,S-S的数据采集过程如下:

1)当点击网站/APP时,用户客户端向网站服务器端发送请求,如①所示;

2)网站服务器将处理完的请求直接发送到采集服务器,而不必经过用户客户端,如④所示。

所有在线数据采集都会受到采集规则的制约,比如排除特定IP地址的流量、只采集某个域名下的数据等。数据采集规则是数据采集的重要控制节点,如果出现某些排除、隐藏或直接忽视数据的采集规则,将可能导致数据丢失。

所有SAAS网站分析系统都不能处理历史数据,这意味着,如果在数据采集阶段出现数据丢失将产生无法挽回的后果,建议原始数据采集阶段不设定任何排除规则;如果数据中可能含有大量的内部测试数据,测试环境与生产环境分账号采集。

2.外部接入数据

外部接入数据根据接入方式不同可分为API接入、Excel接入和Log接入等。

API是主流的大批量数据集成方法,常见的数据源系统包括Baidu和Google的SEM数据、EDM数据等营销类数据,企业CRM数据等用户类数据、企业订单及销售数据等;

Excel是临时性、小数据量的导入方式,人工通过前端界面上传实现;

Log是原始服务器日志,部分网站分析系统日Webtrends支持混合页面标记数据和日志数据,共同作为网站分析系统数据源,支持Log的网站分析系统主要采用Local即本地服务器形式,数据直接在企业内部交换。

外部数据接入与在线数据采集是异步进行的。外部接入数据进入网站分析系统后,根据数据处理层的处理规则,在经过数据抽取、加载、转换之后,与在线采集数据整合形成完整数据源。外部接入数据必须具备一定的特征才能与在线采集数据整合,常见的特征是以某个字段作为关联主键,比如产品ID、渠道ID、用户ID、页面ID或订单ID等;也可以通过时间性特征进行数据整合处理,如按时间导入费用、站外投放数据等。

外部接入数据的工作流程大体是:原始外部数据(文档、服务器日志、在线其他系统数据、离线数据)通过自动或人工整理形成符合特定规范的数据文件,然后根据接入机制的不同完成数据整合工作,如图7-3所示。

图7-3 外部接入数据工作流程

文档类数据文件通常通过前端界面手动上传实现数据导入;

在线其他系统数据以及离线数据通过API进入网站分析系统;

服务器日志、在线其他系统数据以及离线数据也可以通过特定FTP服务器上传数据,具体流程为:企业内部通过程序生成特定数据文档,将稳定自动上传到网站分析系统指定的FTP服务器,网站分析系统从FTP服务器采集数据,通过验证后处理数据。

理想情况下通过API接口导入外部数据是最优选择,但综合IT人力、物力和时间投入因素,通过FTP导入数据的方式却更易于实现。前期可以考虑使用FTP自动上传的机制,待数据需求稳定且业务实现思路无误后再通过技术开发API。

7.4.2 流量数据处理

在数据处理之前,由于原始在线采集数据和外部数据的都是细粒度的数据,无法无法提供支撑后期应用需求,因此需要经过特定规则处理。

1.数据规则层

不同网站分析系统的数据处理规则有所差异,网站分析系统的功能越强大,其处理规则越复杂。数据规则按照数据处理过程可分为代码部署规则、数据采集规则和数据处理规则。

(1)代码部署规则

代码部署规则是在数据采集阶段的语法规则,不同字段通过不同的语法实现。常见的收集规则包括用户类、事件类、页面浏览类、交互类、电子商务类等。

(2)数据采集规则

数据采集规则是在数据发送到服务器端时设置的只收集符合特定条件的数据,而对其他数据全部“忽略”,常见的数据采集规则是包含和排除,如只包含符合条件的数据,排除符合条件的数据;规则内容则有如下几种形式:

特定网站内容的流量:如主机名、目录、请求URL、网页标题、着陆页地址信息;

特定外部来源的流量:如推荐链接、社会化媒体来源、自定义来源跟踪标记(来源、媒介、位置、广告活动、内容、关键字等);

特定用户属性的流量:如浏览器、操作系统、设备信息、网络服务信息、操作设备(PC、WAP、APP应用)、国家、城市、地区、IP地址等;

特定用户行为的流量:如搜索、购买、特殊事件标记、自定义用户维度等;

(3)数据处理规则

数据处理规则是指对原始采集数据进行处理的规则要求,除满足日常系统功能需求而设定的处理逻辑以外,还有部分通过人工或API设定的特殊处理规则,这些规则综合影响最终的数据仓库数据。常见的数据处理规则可以包含上述所有的数据采集规则的内容,除此以外还包括某些特定用法,如数据提取、复制、转换、组合等。

2.数据处理层

数据处理层的处理对象分为两种,一是通用信息处理,二是特殊数据处理。

(1)通用信息处理

尽管不同网站分析系统功能有所差异,但有些功能是所有网站分析系统都具备的,这些信息在数据报告中可能涉及分析维度包括:全部来源渠道、引荐来源、搜索引擎和关键字、全部页面、进入网页、退出网页、访客地域、新老访客、时间等。涉及的指标包括UV、访问量、浏览量、停留时间、IP数、跳出数、跳出率等。

这些通过信息来源于客户端发出请求的HTTP中的标准内容,包括:发出请求的IP地址、时间戳、请求类型、请求主干、返回状态码、返回字节数、客户端信息等。如下是一段通用数据记录示例:

219.133.0.1 - - [17/Jan/2014:09:23:46 +0800] "GET /adobe-analytics-anomaly-detection.html HTTP/1.1" 200 10935 "http://www.searchmarketingart.com/webtrekk-a-concern-commercial-web-site-analysis-tools.html" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; aff-kingsoft-ciba; .NET4.0E)"

(2)特殊数据处理

这部分数据是系统根据自身功能定义的数据规则信息,该信息受网站分析系统规则定义和页面代码部署双重影响。

特殊数据可能包括维度有:电子商务跟踪信息、产品信息、自定义渠道信息、站内搜索信息、用户路径信息、访问设备信息、目标转化信息、事件信息、漏斗信息、关联信息、用户细分和区段、归因模型信息、多渠道转化、异常检测信息、分组信息、媒体跟踪信息、A/B测试信息以及自定义维度信息等。可提供的指标可能包括:支持度、频次、首次转化价值、辅助转化价值、各级转化率、到达数、放弃率、完成率、交互度、访问价值、价格、数量、实例、位置值、登录注册数、排名、登入率、CTR、费用、周转率以及自定义指标等。

在经过数据处理之后,现在大多数的结果数据都会被放在“数据仓库”中,这里的数据仓库是泛指,其中包括MySQL等传统数据库,也包括Hive、HBase等大数据下常用存储。网站数据仓库是支撑高级分析需求的数据基础,初级的网站分析工具由于功能简单而无需网站数据仓库,所有数据报表都可以基于原始Log日志直接生成报表即可。

不同网站分析系统对于自身的数据仓库的数据结构定义不同。如Adobe Analytics的网站数据仓库是一个Data Feed集,拥有超过500个字段的巨型表;Webtrekk和Webtrends的网站数据仓库是一个结构化、雪花型数据仓库,含有超过20个关系表共同组成点击流数据仓库。

7.4.3 流量数据应用

数据应用层是网站数据输出的出口,常见用的请求主体有:Web Service、Report API、Excel API、Feed API、DataWarehouse。

Web Service:SAAS模式的网站分析系统都是通过在线访问进入系统,所有在线访问产生的数据请求都可以归为Web Service,包括数据报告的下载、下钻、筛选、展现、上卷、更新、删除、新增等功能操作和分析操作。

Report API:部分网站分析系统支持通过API调用数据报告,并集成到其他系统。

Excel API:部分网站分析工具提供Excel插件,通过Excel实现数据查询、导出等操作。

Feed API:Data Feed只在高端网站分析工具中才提供,DataFeed是结构化的原始网站数据的集合,也可以看成是结构化后的网站行为日志,Data Feed常用来与企业数据仓库(EDW)做数据整合使用。

DataWarehouse:部分高端网站分析工具提供数据仓库导出接口,可直接通过数据仓库构成完整的点击流数据,这种方式更利于企业数据仓库的实现。

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。
列表为空,暂无数据
    我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
    原文