CN113901372A - 一种用户行为数据仓构建系统及方法 - Google Patents

Abstract

本发明公开了一种用户行为数据仓构建系统及方法，综合考虑到数据传输安全性、扩展性、二次开发难度以及和数据的结合，数据采集方面主要是依托代码埋点和服务端埋点建设全端全栈的全埋点体系，数据仓中存储的用户行为的业务信息和全埋点信息进行关联，数据仓数据与后台业务流程数据对应便于做进一步的关联分析；由全埋点采集系统自动根据上报请求进行采集，无需人工线下管理，提高实效性并降低成本；引入埋点树状管理结构，保存有各个埋点的历史数据并根据上报的用户行为的埋点信息实时更新，且埋点树状管理结构可以实时查看各埋点的历史数据，为管理和查看带来便利。

Description

一种用户行为数据仓构建系统及方法

技术领域

本发明涉及大数据技术领域，具体涉及一种用户行为数据仓构建系统及方法。

背景技术

在大数据应用领域，我们一般把数据处理分为5个大的环节，即“采集”、“加工”、“存储”、“计算”、“可视化”。在这些环节中，采集作为数据的源头，需要有效的手段和方式来保证它的全面、准确和及时。

对于不同类型的数据，我们的采集方法可能大相径庭。比如交通数据通过路口监控摄像头，自动驾驶数据通过毫米波雷达、机器视觉等等；对于用户行为，特别是具体到智能设备上的端上行为，我们就通过埋点感知和采集，或者也叫“事件追踪”。埋点就是指对用户行为事件的感知、捕获、处理和上报。类似于道路上的各种摄像头采集车辆、车牌、车道、车速、路况等信息，埋点也是通过在软件系统(当然也包括手机端的各种应用)中特定的环节和页面上进行预设置，从而收集用户的身份识别、行为、环境等信息。

按照埋点位置，埋点可分为客户端埋点和服务端埋点，客户端埋点按照埋点工具和交互方式，又分为代码埋点、全埋点和交互式埋点。

现有的用户行为数据仓构建，用户采集的埋点体系主要依赖代码埋点，它存在以下技术问题：

(1)不全面，埋点需要提前提需求，埋点前的历史行为数据不可回溯；埋点收集的用户行为数据，无法与后台业务流程数据对应，就没办法做进一步的关联分析。

(2)不准确，用户身份在某些场景下获取不到，特别是系统间跳转或者合作方的单点登陆环节，用户身份识别有误或者无法识别，用户相关数据分析会不全面，对于用户体验性功能和客服的服务质量造成很大挑战。

(3)不及时，埋点点位通过人工线下管理，解决的是项目上线需求管理，没有与上报的数据对应。

(4)成本高，手动埋点开发和管理成本高，由于每个点位和环节都需要人工处理，涉及到变更或者技术升级时，影响范围特别巨大；在加工环节，由于用户身份识别问题，点位管理问题，客户端埋点和服务端埋点的数据打通问题，造成两方面结果延误。

由于数据仓管理中数据没有及时加工和打通，造成一些实时性数据比如数据大盘、实时精准营销、实时异常行为监控和告警等有误，难以开展应用。

发明内容

本发明所要解决的技术问题是现有的数据仓构建过程中，用户采集的埋点体系主要依赖代码埋点，采集过程复杂不全面、成本高，最终构建好的数据关联性和实时性较差，为解决上述技术题，本发明目的在于提供一种用户行为数据仓构建系统及方法。

本发明通过下述技术方案实现：

本方案提供一种用户行为数据仓构建系统，包括：全埋点采集系统、业务系统和数据仓；所述全埋点采集系统包括点位管理系统；

用户行为背后产生埋点上报请求和业务上报请求；根据埋点上报请求，用户行为的埋点信息实时上报至全埋点采集系统；根据业务上报请求，用户行为的业务信息实时上报至业务系统；

业务系统将用户行为的业务信息同步至数据仓；

点位管理系统基于用户行为的埋点信息构建埋点树状管理结构，或对已构建好的埋点树状管理结构进行更新；

全埋点采集系统将由点位管理系统得到的埋点树状管理结构也作为用户行为的埋点信息的一部分，并将用户行为的埋点信息同步至数据仓；

数据仓基于埋点上报请求和业务上报请求对用户行为的业务信息和全埋点信息进行关联并存储。

本方案原理：本方案提供的用户行为数据仓构建系统，综合考虑到数据传输安全性、扩展性、二次开发难度以及和数据的结合，数据采集方面主要是依托代码埋点和服务端埋点建设全端全栈的全埋点体系，数据仓中存储的用户行为的业务信息和全埋点信息进行关联，数据仓数据与后台业务流程数据对应便于做进一步的关联分析；由全埋点采集系统自动根据上报请求进行采集，无需人工线下管理，提高实效性并降低成本；引入埋点树状管理结构，保存有各个埋点的历史数据并根据上报的用户行为的埋点信息实时更新，且埋点树状管理结构可以实时查看各埋点的历史数据，为管理和查看带来便利；本方案从数据仓构建过程中的采集、加工和储存三个方面都进行改进，通过对用户行为数据的采集、加工、存储的统一规划，使得数据仓中存储已经被加工和关联处理过后的数据，为用户行为分析应用提供统一的数据支撑，大大提高了户体验性功能和客服的服务质量。

埋点树状管理结构就可以相当于一个实时的离线数据仓，便于进行实时查看，为用户行为路径查询、多维分析和留存分析提供数据基础；而最终得到的数据仓中将埋点数据与业务流程数据进行关联，便于对应做进一步的关联分析。

进一步优化方案为，所述用户行为指用户在客户端上所有的有用行为，所述有用行为包括：登录行为、退出行为、进入页面和用户与客户端的交互行为。

有用行为即为用户在客户端上所有有意义的用户交互行为，用户与客户端的交互行为例如弹窗、跳转和按钮，有用行为不包括无意义的交互行为，如滚屏或非操作区点击，如热区图。

进一步优化方案为，所述客户端包括小程序、APP和Web页面。Web页面如各种网页链接等。

进一步优化方案为，所述用户行为的埋点信息包括：页面ID、交互行为ID、客户端基本信息、标准信息和业务自定义信息；

所述页面ID为用户进入页面时，根据页面的URL生成的元素ID；

所述交互行为ID为用户与客户端的交互行为生成的元素ID；

所述客户端基本信息包括客户端设备的标识、浏览器、版本、网络、型号和地理位置；

所述标准信息包括用户行为的服务渠道标识、会话ID、时间戳、事件类型和用户ID；

所述业务自定义信息包括用户token、内部渠道码、版本号、窗口大小、分辨率、来源URL和请求页面标题。

所述服务渠道标识为用户产生行为的途径，每种类型的服务端对应一种途径，通过对各途径添加标识以示区别；业务自定义信息主要为用户进行业务行为过程中实时创建的信息(例如用户请求汇款业务行为过程中，用户自定义输入的汇款额等信息)，由于全埋点采集系统是预先布设好的标准系统，采集的都是固定属性，对于业务过程中用户自定义输入的这类信息无法通过全埋点采集系统自动采集，因此需要依托代码埋点进行单独采集。

手动埋点开发和管理成本高，由于每个点位和环节都需要人工处理，涉及到变更或者技术升级时，影响范围特别巨大；本方案提供的全埋点采集系统依托于现有的代码埋点和服务端埋点建设全端全栈的全埋点体系，为各客户端(H5、小程序、APP)提供全埋点SDK，在项目中引入，并在项目初始化后，自动完成信息收集和上报，业务数据由代码埋点采集，不仅能够降低成本，还保证了数据的准确性。

进一步优化方案为，埋点树状管理结构的构建方法为：

S1：根据用户行为的埋点信息提取出页面信息和点位信息；所述页面信息包括：页面ID、页面URL和页面名称，所述点位信息包括埋点ID和埋点名称；所述页面名称和埋点名称为自定义设置获得；

S2：根据页面信息和点位信息自动生成埋点树状管理结构。

点位管理系统进行点位管理主要解决的是点位和从属关系自动生成，并可以依据点位进行自定义业务名称的能力，在埋点采集系统收到用户行为信息后，将页面信息(ID、URL、页面标题)和点位信息(ID、点位名称)上报到点位管理系统，并自动生成客户端的端-页面-元素的三级树状管理结构；在此基础上，提供对页面名称、点位名称自定义的能力。将点位管理系统的数据同时也作为埋点数据的元数据的一部分，自动同步到用户行为数仓，用作持续的行为数据分析结果。

进一步优化方案为，所述全埋点采集系统和业务系统具有统一的RESTful接口，通过TLS加密的方式进行通信和上报接收。

进一步优化方案为，所述数据仓对用户行为的业务信息和全埋点信息进行实时关联的方法为：

T1：对用户行为的埋点信息进行补充；

T2：将埋点上报请求的入口数据和业务上报请求的入口数据同步至数据仓；

T3：数据仓根据入口数据将业务上报请求与埋点上报请求直接关联，进而实现业务信息和全埋点信息的关联。

业务上报请求的入口数据和埋点上报请求的入口数据都带有用户身份信息(即加密后的用户ID)，以及发生时的客户端的时间戳。通过这两个维度，就可以将业务上报请求与埋点上报请求直接关联，由于业务上报请求在后端系统可以通过分布式追踪ID(即TraceID)来跨系统关联，这样用户行为(埋点数据)上就可以附带上追踪ID，而跨业务系统与链路上的业务系统数据打通。

进一步优化方案为，所述业务系统通过代码埋点采集用户行为的业务信息。

本方案还提供一种用户行为数据仓构建方法，应用于上述用户行为数据仓构建系统，包括：

步骤一：在客户端构建全埋点体系采集用户行为的埋点信息；

步骤二：根据埋点上报请求实时上报用户行为的埋点信息，根据业务上报请求实时上报用户行为的业务信息；

步骤三：基于用户行为的埋点信息构建埋点树状管理结构，或对已构建好的埋点树状管理结构进行更新，

步骤四：将步骤三获得的埋点树状管理结构也作为用户行为的埋点信息的一部分；

步骤五：基于埋点上报请求和业务上报请求对用户行为的业务信息和埋点信息进行关联并存储。

进一步优化方案为，构建好全埋点体系后，需要对户行为数据仓构建系统进行接口性能压测和处理异步化操作。

考虑到数据仓构建系统的性能和吞吐量，在进行客户端全局全埋点后，日均百万级到千万的点击和数据量，对埋点采集系统和管理系统的考验增大，需要提前进行接口性能压测和处理异步化，保证数据能够正常上报，并不影响用户体验。

本发明与现有技术相比，具有如下的优点和有益效果：

本发明提供的一种用户行为数据仓构建系统及方法，综合考虑到数据传输安全性、扩展性、二次开发难度以及和数据的结合，数据采集方面主要是依托代码埋点和服务端埋点建设全端全栈的全埋点体系，数据仓中存储的用户行为的业务信息和全埋点信息进行关联，数据仓数据与后台业务流程数据对应便于做进一步的关联分析；由全埋点采集系统自动根据上报请求进行采集，无需人工线下管理，提高实效性并降低成本；引入埋点树状管理结构，保存有各个埋点的历史数据并根据上报的用户行为的埋点信息实时更新，且埋点树状管理结构可以实时查看各埋点的历史数据，为管理和查看带来便利。

附图说明

为了更清楚地说明本发明示例性实施方式的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本发明的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。在附图中：

图1为用户行为数据仓构建系统示意图；

图2为用户行为数据流向图；

图3为实施例1系统整体方案架构示意图；

图4为实施例3前后端数据串联示意图；

图5为实施例3数据存储架构图示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚明白，下面结合实施例和附图，对本发明作进一步的详细说明，本发明的示意性实施方式及其说明仅用于解释本发明，并不作为对本发明的限定。

实施例1

基于现有的用户行为数据仓的弊端，本实施例提供一种用户行为数据仓构建系统，如图1所示，包括：全埋点采集系统、业务系统和数据仓；所述全埋点采集系统包括点位管理系统；

用户行为背后产生埋点上报请求和业务上报请求；根据埋点上报请求，用户行为的埋点信息实时上报至全埋点采集系统；根据业务上报请求，用户行为的业务信息实时上报至业务系统；

如图2所示，业务系统将用户行为的业务信息同步至数据仓；

点位管理系统基于用户行为的埋点信息构建埋点树状管理结构，或对已构建好的埋点树状管理结构进行更新；

全埋点采集系统将由点位管理系统得到的埋点树状管理结构也作为用户行为的埋点信息的一部分，并将用户行为的埋点信息同步至数据仓；

数据仓基于埋点上报请求和业务上报请求对用户行为的业务信息和全埋点信息进行关联并存储。

用户行为指用户在客户端上所有的有用行为，所述有用行为包括：登录行为、退出行为、进入页面和用户与客户端的交互行为。

用户行为的埋点信息包括：页面ID、交互行为ID、客户端基本信息、标准信息和业务自定义信息；

所述页面ID为用户进入页面时，根据页面的URL生成的元素ID；

所述交互行为ID为用户与客户端的交互行为生成的元素ID；

所述客户端基本信息包括客户端设备的标识、浏览器、版本、网络、型号和地理位置；

所述标准信息包括用户行为的服务渠道标识、会话ID、时间戳、事件类型和用户ID；

所述业务自定义信息包括用户token、内部渠道码、版本号、窗口大小、分辨率、来源URL和请求页面标题。

埋点树状管理结构的构建方法为：

S1：根据用户行为的埋点信息提取出页面信息和点位信息；所述页面信息包括：页面ID、页面URL和页面名称，所述点位信息包括埋点ID和埋点名称；所述页面名称和埋点名称为自定义设置获得；

S2：根据页面信息和点位信息自动生成埋点树状管理结构。

在已构建好埋点树状管理结构的前提下，点位管理系统基于用户行为的埋点信息实时对埋点树状管理结构进行自动维护，将对应的液面信息和点位信息进行更新，在埋点树状管理结构中，还可以自定义进行点位命名和页面命名，自定义完成的点位命名和页面命名信息也会一并保存至数据仓中；同时可以实时调取埋点树状管理结构中的信息进行查看。

全埋点采集系统和业务系统具有统一的RESTful接口，通过TLS加密的方式进行通信和上报接收。restful接口和tls加密，实现客户端与服务器的通讯，还能够为系统提供足够好的兼容性与安全性。

数据仓对用户行为的业务信息和全埋点信息进行实时关联的方法为：

T1：对用户行为的埋点信息进行补充；

T2：将埋点上报请求的入口数据和业务上报请求的入口数据同步至数据仓；

T3：数据仓根据入口数据将业务上报请求与埋点上报请求直接关联，进而实现业务信息和全埋点信息的关联。

业务系统通过代码埋点采集用户行为的业务信息。

系统整体方案架构如图3所示，用户客户端包括小程序、APP和Web页面；在各客户端设置全埋点SDK和代码埋点SDK；用户行为背后产生埋点上报请求和业务上报请求，业务数据经过网关等网络设备到达业务系统形成日志收集消息队列，埋点数据经过买点采集系统处理后形成埋点消息队列，日志收集消息队列和埋点消息队列在数据仓关联储存；同时埋点数据经过买点采集系统处理后还得到实时离线数仓为数据分析提供基础。

实施例2

基于上一实施例，本实施例提供一种用户行为数据仓构建方法，包括：

步骤一：在客户端构建全埋点体系采集用户行为的埋点信息；

步骤二：根据埋点上报请求实时上报用户行为的埋点信息，根据业务上报请求实时上报用户行为的业务信息；

步骤三：基于用户行为的埋点信息构建埋点树状管理结构，或对已构建好的埋点树状管理结构进行更新，

步骤四：将步骤三获得的埋点树状管理结构也作为用户行为的埋点信息的一部分；

步骤五：基于埋点上报请求和业务上报请求对用户行为的业务信息和埋点信息进行关联并存储。

在进行全局全埋点后，日均百万级到千万的点击和数据量，对埋点采集系统和管理系统的考验增大，因此构建好全埋点体系后，需要对户行为数据仓构建系统进行接口性能压测和处理异步化操作。

实施例3

本实施例基于本发明构建数据仓，形成如图5所示的数据存储架构，用户在客户端进行数据消费：般若离线报表、客户旅程分析、智能营销策略和智能催收策略等，客户端产生相应的用户行为数据；用户行为数据被贴源数据全埋点实时收集，进行数据整合处理后存储在数据仓，埋点树状管理结构相当于离线数仓便于日终整合存储，进一步在运营集市中应用；数据仓和离线数仓进一步为数据服务提供优质的数据基础，反过来实现数据治理和消费引导；形成闭环数据系统。

现对针对用户行为数据仓构建过程的主要环节的实施方式分别做说明：

一、采集

1)提供SDK：H5(Web网页)、小程序、安卓端、APP端，分别按整体端上方案提供全埋点SDK接入，并提供接入指引。

2)引入和开发：所有的新系统和页面，均按照指引接入用户行为采集SDK并进行本地测试。

3)测试和验证：测试人员需要在所有的需求里面，默认验证是否上报、上报内容是否正确等信息。

4)现有点位改造：对代码埋点的点，逐步改造和迁移。

二、加工和存储

1)信息补全：按照各模块(用户信息、地址、码表、点位)分别补全后再往后流转

2)前后端串联：将业务追踪ID关联到埋点请求上再往后流转；数据关联和转换需要进行：

用户信息补全：通过用户ID(密)，关联用户中心获取名称和手机号等信息；

地址补全：通过GPS位置，结合位置信息库，得到省市区详细地址的信息；

码表映射转换：对于业务和渠道相关的产品码、渠道码等，转换为统一；

点位转换：将点位信息(页面URL、元素位置等)传输到点位管理系统进行二次加工

如图4所示，每一次用户行为背后，会产生两条互相隔离请求，即业务请求(到业务系统)和埋点上报请求(到埋点采集系统)。为了将这两个请求能够进行关联，我们将这两个请求的入口数据都即时的同步到实时数仓。

这两个请求都带有用户身份信息(即加密后的用户ID)，以及发生时的客户端时间戳。通过这两个维度，就可以将业务请求与埋点请求直接关联。由于业务请求在后端系统可以通过分布式追踪ID(即TraceID)来跨系统关联，这样用户行为(埋点数据)上就可以附带上追踪ID，而跨业务系统与链路上的业务系统数据打通。

3)数据按照3套模型实时存储，出于性能考量，在数据仓库只保留5～7天的热数据，更老的数据将被移动和加工到离线数据仓库。

数据模型：

代码埋点数据包括(数据格式统一保持)：

设备标识、浏览器、版本、网络相关、手机型号、经纬度、渠道标识、会话id、时间戳、事件类型、用户ID

用户事件：用户token、内部渠道码、版本号、窗口大小、分辨率

浏览事件：页面id、页面url、来源url、页面title

自定义事件：事件id、事件报文

全埋点数据：包含代码埋点的3种数据

设备标识、浏览器、版本、网络相关、手机型号、经纬度、渠道标识、会话id、时间戳、事件类型、用户ID；内部渠道码、版本号、窗口大小、分辨率、页面url、来源url、页面title。

网关日志数据包括，用户信息：用户ID；请求信息，方式、url…；响应信息：状态码；

性能信息：请求时间、响应时间、耗时；关联信息：三码一号。

本实施例解决了用户行为数据仓库建设过程中的数据不全面，身份识别，点位管理、前后端数据关联打通方面的问题，建设了实时数据仓库，为基于其上的数据应用提供一站式支持。

以上所述的具体实施方式，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施方式而已，并不用于限定本发明的保护范围，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (10)

1.一种用户行为数据仓构建系统，其特征在于，包括：全埋点采集系统、业务系统和数据仓；所述全埋点采集系统包括点位管理系统；

用户行为背后产生埋点上报请求和业务上报请求；根据埋点上报请求，用户行为的埋点信息实时上报至全埋点采集系统；根据业务上报请求，用户行为的业务信息实时上报至业务系统；

业务系统将用户行为的业务信息同步至数据仓；

点位管理系统基于用户行为的埋点信息构建埋点树状管理结构，或对已构建好的埋点树状管理结构进行更新；

全埋点采集系统将经点位管理系统得到的埋点树状管理结构也作为用户行为的埋点信息的一部分，并将用户行为的埋点信息同步至数据仓；

数据仓基于埋点上报请求和业务上报请求对用户行为的业务信息和全埋点信息进行关联并存储。

2.根据权利要求1所述的一种用户行为数据仓构建系统，其特征在于，所述用户行为指用户在客户端上所有的有用行为，所述有用行为包括：登录行为、退出行为、进入页面和用户与客户端的交互行为。

3.根据权利要求2所述的一种用户行为数据仓构建系统，其特征在于，所述客户端包括小程序、APP和Web页面。

4.根据权利要求2所述的一种用户行为数据仓构建系统，其特征在于，所述用户行为的埋点信息包括：页面ID、交互行为ID、客户端基本信息、标准信息和业务自定义信息；

所述页面ID为用户进入页面时，根据页面的URL生成的元素ID；

所述交互行为ID为用户与客户端的交互行为生成的元素ID；

所述客户端基本信息包括客户端设备的标识、浏览器、版本、网络、型号和地理位置；

所述标准信息包括用户行为的服务渠道标识、会话ID、时间戳、事件类型和用户ID；

所述业务自定义信息包括用户token、内部渠道码、版本号、窗口大小、分辨率、来源URL和请求页面标题。

5.根据权利要求4所述的一种用户行为数据仓构建系统，其特征在于，埋点树状管理结构的构建方法为：

S1：根据用户行为的埋点信息提取出页面信息和点位信息；所述页面信息包括：页面ID、页面URL和页面名称，所述点位信息包括埋点ID和埋点名称；所述页面名称和埋点名称为自定义设置获得；

S2：根据页面信息和点位信息自动生成埋点树状管理结构。

6.根据权利要求4所述的一种用户行为数据仓构建系统，其特征在于，所述全埋点采集系统和业务系统具有统一的RESTful接口，通过TLS加密的方式进行通信和上报接收。

7.根据权利要求6所述的一种用户行为数据仓构建系统，其特征在于，所述数据仓对用户行为的业务信息和全埋点信息进行实时关联的方法为：

T1：对用户行为的埋点信息进行补充；

T2：将埋点上报请求中的入口数据和业务上报请求中的入口数据同步至数据仓；

T3：数据仓基于入口数据将业务上报请求与埋点上报请求直接关联，进而实现业务信息和全埋点信息的关联。

8.根据权利要求1所述的一种用户行为数据仓构建系统，其特征在于，所述业务系统通过代码埋点采集用户行为的业务信息。

9.一种用户行为数据仓构建方法，其特征在于，应用于权利要求1-8任意一项所述用户行为数据仓构建系统，包括：

步骤一：在客户端构建全埋点体系采集用户行为的埋点信息；

步骤二：根据埋点上报请求实时上报用户行为的埋点信息，根据业务上报请求实时上报用户行为的业务信息；

步骤三：基于用户行为的埋点信息构建埋点树状管理结构，或对已构建好的埋点树状管理结构进行更新，

步骤四：将步骤三获得的埋点树状管理结构也作为用户行为的埋点信息的一部分；

步骤五：基于埋点上报请求和业务上报请求对用户行为的业务信息和埋点信息进行关联并存储。

10.根据权利要求9所述的一种用户行为数据仓构建方法，其特征在于，构建好全埋点体系后，需要对户行为数据仓构建系统进行接口性能压测和处理异步化操作。

Images