CN116467153A

CN116467153A - 数据处理方法、装置、计算机设备及存储介质

Info

Publication number: CN116467153A
Application number: CN202210027292.2A
Authority: CN
Inventors: 朱学彬; 王飞; 李佩; 谢梁; 余成跃; 邓宇; 张力
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2022-01-11
Filing date: 2022-01-11
Publication date: 2023-07-21

Abstract

本申请公开了一种数据处理方法、装置、计算机设备及存储介质，属于计算机技术领域。该方法包括：获取目标测试关联的每个账号的第一场景序列；从每个账号的第一场景序列中筛选得到第二场景序列；从多个账号的第二场景序列中筛选得到第三场景序列；基于第三场景序列获取业务分析数据。本申请可应用于云技术、人工智能、智慧交通、辅助驾驶等各种场景，由于第一场景序列都是以第一界面为起点的，能够保证第三场景序列也是以第一界面为起点，从而保证业务分析数据不会偏离第一界面所在的测试生效场景，从而提高了对目标测试的业务分析数据进行数据计算时的准确度。

Description

数据处理方法、装置、计算机设备及存储介质

技术领域

本申请涉及计算机技术领域，特别涉及一种数据处理方法、装置、计算机设备及存储介质。

背景技术

随着计算机技术的发展，在对一些互联网产品进行更新迭代时，通常需要将新版本或者新功能投放到一些用户的客户端以进行AB测试，AB测试是指：对互联网产品如应用程序(Application，APP)的界面、控件、功能或者交互流程等优化目标制作多个方案，在同一测试时间段内，将不同的方案随机投放到客户端，让客户端随机地使用任一方案，从而收集得到登录客户端的账号的行为数据，最后根据显著性检验分析评估出效果最好的方案在正式版本中采用。

在上述AB测试完成后，如何利用收集到的行为数据，来有效分析AB测试的优化目标对相关业务指标所造成的影响，逐渐成为一个亟需解决的问题。

发明内容

本申请实施例提供了一种数据处理方法、装置、计算机设备及存储介质，能够提供获取到的业务分析数据的准确度。该技术方案如下：

一方面，提供了一种数据处理方法，该方法包括：

获取目标测试关联的每个账号的多个第一场景序列，所述第一场景序列用于表征所述账号从客户端的第一界面跳转至的至少一个第二界面以及界面间的跳转顺序；

从所述多个第一场景序列中，筛选得到每个账号的第二场景序列，所述第二场景序列的至少一个业务指标符合第一目标条件；

从多个账号的所述第二场景序列中，筛选得到至少一个第三场景序列，所述第三场景序列的至少一个业务指标符合第二目标条件；

基于所述至少一个第三场景序列，获取所述目标测试的业务分析数据，所述业务分析数据用于分析所述目标测试对所述客户端中以所述第一界面为起点的场景跳转的业务影响。

一方面，提供了一种数据处理装置，该装置包括：

第一获取模块，用于获取目标测试关联的每个账号的多个第一场景序列，所述第一场景序列用于表征所述账号从客户端的第一界面跳转至的至少一个第二界面以及界面间的跳转顺序；

第一筛选模块，用于从所述多个第一场景序列中，筛选得到每个账号的第二场景序列，所述第二场景序列的至少一个业务指标符合第一目标条件；

第二筛选模块，用于从多个账号的所述第二场景序列中，筛选得到至少一个第三场景序列，所述第三场景序列的至少一个业务指标符合第二目标条件；

第二获取模块，用于基于所述至少一个第三场景序列，获取所述目标测试的业务分析数据，所述业务分析数据用于分析所述目标测试对所述客户端中以所述第一界面为起点的场景跳转的业务影响。

在一种可能实施方式中，所述第一获取模块用于：

获取所述账号在所述目标测试的测试时间段中产生的行为数据，所述行为数据用于表征所述账号在所述客户端所执行的界面跳转的触发行为；

基于所述行为数据，获取所述账号的原始场景序列，所述原始场景序列用于表征基于所述触发行为跳转至的各个界面以及界面间的跳转顺序；

基于所述第一界面，对所述原始场景序列进行划分，得到所述账号的多个第一场景序列，其中，所述第一场景序列的第一个元素为所述第一界面。

在一种可能实施方式中，所述第一筛选模块包括：

第一获取单元，用于对任一账号的任一第一场景序列，基于所述至少一个业务指标，获取所述第一场景序列的第一评分参数，所述第一评分参数用于表征所述第一场景序列在所述至少一个业务指标上的综合评分情况；

确定单元，用于将第一评分参数最高的第一场景序列确定为所述账号的第二场景序列。

在一种可能实施方式中，所述第一获取单元用于：

基于所述至少一个业务指标，获取所述第一场景序列的业务特征，所述业务特征用于表征所述第一场景序列在每个业务指标上评估得到的指标值；

基于第一权重向量，对所述第一场景序列的业务特征进行加权，得到所述第一评分参数，所述第一权重向量用于表征每个业务指标所对应的第一权重。

在一种可能实施方式中，所述第二筛选模块包括：

去重单元，用于对多个账号的所述第二场景序列进行去重，得到去重后的多个第二场景序列；

筛选单元，用于从所述去重后的多个第二场景序列中，基于所述至少一个业务指标，筛选得到所述至少一个第三场景序列。

在一种可能实施方式中，所述筛选单元包括：

获取子单元，用于对去重后的每个第二场景序列，基于所述至少一个业务指标，获取所述第二场景序列的第二评分参数，所述第二评分参数用于表征所述第二场景序列在所述至少一个业务指标上的综合评分情况；

排序确定子单元，用于按照第二评分参数从大到小的顺序对去重后的各个第二场景序列进行排序，将在所述排序中位于前目标数量的第二场景序列确定为所述至少一个第三场景序列。

在一种可能实施方式中，所述获取子单元用于：

基于所述至少一个业务指标，获取所述第二场景序列的业务特征，所述业务特征用于表征所述第二场景序列在每个业务指标上评估得到的指标值；

基于第二权重向量，对所述第二场景序列的业务特征进行加权，得到所述第二评分参数，所述第二权重向量用于表征每个业务指标所对应的第二权重。

在一种可能实施方式中，所述业务分析数据包括场景关系图，所述场景关系图用于表征所述客户端中在所述目标测试的作用下所影响的场景跳转链路；

所述第二获取模块包括：

第二获取单元，用于基于所述至少一个第三场景序列，获取场景集合和关系集合，所述场景集合用于表征各个所述第三场景序列中不同界面所形成的集合，所述关系集合用于表征所述场景集合中不同界面之间的跳转顺序；

构建单元，用于基于所述场景集合和所述关系集合，构建所述场景关系图。

在一种可能实施方式中，所述构建单元用于：

对所述场景集合中每个界面，在所述场景关系图中生成所述界面对应的节点；

对所述关系集合中任意两个界面间的跳转顺序，在所述场景关系图中生成所述两个界面所对应的两个节点之间的有向边。

在一种可能实施方式中，所述业务分析数据还包括所述场景关系图中每个节点在业务指标上的显著性检验结果；

所述装置还包括：

第三获取模块，用于获取预先配置的业务指标集合和业务指标与界面的映射关系；

确定模块，用于基于所述映射关系，从所述业务指标集合中，确定与所述场景集合中每个界面关联的第一业务指标；

检验模块，用于对所述场景关系图中的每个节点，对所述节点所对应界面关联的第一业务指标的指标值进行显著性检验，得到所述节点的显著性检验结果。

在一种可能实施方式中，所述确定模块用于：

获取输入的对所述场景关系图的分析指标集合；

获取所述分析指标集合与所述业务指标集合的交集；

对所述场景集合中的每个界面，基于所述映射关系，从所述交集中查询得到所述界面对应的第一业务指标。

在一种可能实施方式中，所述装置还包括：

第四获取模块，用于获取输入的目标界面；

输出模块，用于在所述至少一个第三场景序列中任一第三场景序列包含所述目标界面的情况下，输出包含所述目标界面的第三场景序列为目标场景序列；

所述输出模块，还用于在所述至少一个第三场景序列均不包含所述目标界面的情况下，输出从多个账号的第二场景序列中筛选得到的目标场景序列，所述目标场景序列包含所述目标界面，且所述目标场景序列的至少一个业务指标符合第三目标条件。

在一种可能实施方式中，所述输出模块还用于：

对多个账号的所述第二场景序列进行去重，得到去重后的多个第二场景序列；

从所述去重后的多个第二场景序列中，筛选得到包含所述目标界面的各个第二场景序列；

从包含所述目标界面的各个第二场景序列中，筛选得到业务指标符合所述第三目标条件的目标场景序列，输出所述目标场景序列。

一方面，提供了一种计算机设备，该计算机设备包括一个或多个处理器和一个或多个存储器，该一个或多个存储器中存储有至少一条计算机程序，该至少一条计算机程序由该一个或多个处理器加载并执行以实现如上述数据处理方法。

一方面，提供了一种存储介质，该存储介质中存储有至少一条计算机程序，该至少一条计算机程序由处理器加载并执行以实现如上述数据处理方法。

一方面，提供一种计算机程序产品或计算机程序，所述计算机程序产品或所述计算机程序包括一条或多条程序代码，所述一条或多条程序代码存储在计算机可读存储介质中。计算机设备的一个或多个处理器能够从计算机可读存储介质中读取所述一条或多条程序代码，所述一个或多个处理器执行所述一条或多条程序代码，使得计算机设备能够执行上述数据处理方法。

本申请实施例提供的技术方案带来的有益效果至少包括：

通过对目标测试关联的每个账号，均获取以第一界面为起点的第一场景序列，从第一场景序列中对每个账号筛选得到业务指标符合条件的第二场景序列，再对所有账号的第二场景序列再次筛选得到业务指标符合条件的第三场景序列，利用最终的第三场景序列进行数据分析，来预测本次目标测试的业务分析数据，由于第一场景序列都是以第一界面为起点的，从而能够保证最终筛选出的第三场景序列也是以第一界面为起点，即在设定好目标测试对应的第一界面后，最终得到的业务分析数据不会偏离第一界面所在的测试生效场景，从而提高了获取到的业务分析数据的准确度。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还能够根据这些附图获得其他的附图。

图1是本申请实施例提供的一种数据处理方法的实施环境示意图；

图2是本申请实施例提供的一种数据处理方法的流程图；

图3是本申请实施例提供的一种数据处理方法的流程图；

图4是本申请实施例提供的一种场景关系图的示意图；

图5是本申请实施例提供的一种实验生效链路图的示意图；

图6是本申请实施例提供的一种CSG算法的输入参数配置界面的界面示意图；

图7是本申请实施例提供的一种目标测试的原理性流程图；

图8是本申请实施例提供的一种数据处理装置的结构示意图；

图9是本申请实施例提供的一种计算机设备的结构示意图；

图10是本申请实施例提供的一种计算机设备的结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施方式作进一步地详细描述。

本申请中术语“第一”“第二”等字样用于对作用和功能基本相同的相同项或相似项进行区分，应理解，“第一”、“第二”、“第n”之间不具有逻辑或时序上的依赖关系，也不对数量和执行顺序进行限定。

本申请中术语“至少一个”是指一个或多个，“多个”的含义是指两个或两个以上，例如，多个第一位置是指两个或两个以上的第一位置。

本申请中术语“包括A或B中至少一项”涉及如下几种情况：仅包括A，仅包括B，以及包括A和B两者。

本申请涉及的与用户相关的各类数据，如用户使用账号在测试时间段中产生的行为数据、用户使用账号在浏览每个界面的停留时长等，当以本申请实施例的方法运用到具体产品或技术中时，都需要获取用户许可或者同意或者充分授权，且相关数据的收集、使用和处理需要遵守所在国家相关法律法规和国家标准。

以下，对本申请实施例涉及的术语进行解释说明。

云技术(Cloud Technology)：是指在广域网或局域网内将硬件、软件、网络等系列资源统一起来，实现数据的计算、储存、处理和共享的一种托管技术，也即是基于云计算商业模式应用的网络技术、信息技术、整合技术、管理平台技术、应用技术等的总称，可以组成资源池，按需所用，灵活便利。云计算技术将变成云技术领域的重要支撑。技术网络系统的后台服务需要大量的计算、存储资源，如视频网站、图片类网站和更多的门户网站。伴随着互联网行业的高度发展和应用，将来每个物品都有可能存在自己的识别标志，都需要传输到后台系统进行逻辑处理，不同程度级别的数据将会分开处理，各类行业数据皆需要强大的系统后盾支撑，均能通过云计算来实现。

大数据(Big data)：是指无法在一定时间范围内用常规软件工具进行捕捉、管理和处理的数据集合，是需要新处理模式才能具有更强的决策力、洞察发现力和流程优化能力的海量、高增长率和多样化的信息资产。随着云时代的来临，大数据也吸引了越来越多的关注，大数据需要特殊的技术，以有效地处理大量的容忍经过时间内的数据。适用于大数据的技术，包括大规模并行处理数据库、数据挖掘、分布式文件系统、分布式数据库、云计算平台、互联网和可扩展的存储系统。

AB测试(AB Test)：也称为AB实验，是一种适用于互联网产品的、用于测试新版本或新功能的方法，通常为同一个优化目标制定两种(或两种以上)不同的方案，比如，优化目标包括：修改界面布局、修改控件外观、上线新功能、修改交互流程等，在同一个测试时间段内，将不同的方案随机投放到各个用户的客户端，让每个客户端随机地使用任意一个方案，收集登录各个客户端的账号的行为数据，最后根据显著性检验分析评估出效果最好的方案在正式版本中采用。

假设检验(Hypothesis Testing)：又称统计假设检验，是用来判断样本与样本、样本与总体的差异是由抽样误差引起还是本质差别造成的统计推断方法。

显著性检验(Significance Test)：是假设检验中的一种方法，也是一种统计推断形式，其基本原理是：先对总体(随机变量)的参数或总体分布形式做出某种假设，然后利用样本信息来判断这个假设(备择假设)是否合理，即判断总体的真实情况与原假设是否有显著性差异。或者说，显著性检验要判断样本与上述对总体所做的假设之间的差异是纯属机会变异，还是由我们所做的假设与总体真实情况之间不一致所引起的。例如，显著性检验方法包括：Z检验、t检验、卡方检验、F检验等。

序列数据库(Sequence Database)：储存有序事件的数据库。如本申请实施例涉及的账号的行为数据，在经过预处理后能够得到每个账号的原始场景序列，原始场景序列中包括一系列有序排布的界面(属于有序事件的一种示例性说明)，不同界面对应于不同场景类型，因此原始场景序列能够表征账号在处于登录状态期间客户端中的场景流转顺序，因此各个账号的原始场景序列能够构成一个序列数据库。

项(Item)：序列数据库的最小单元。比如，上述各个账号的原始场景序列构成的序列数据库中，最小单元就是任一原始场景序列中的一个界面，因此序列数据库中的界面就是项。

项集(Item Set)：由若干个项构成。比如，由序列数据库中的一个或多个界面组成了一个项集。

序列(Sequence)：由若干个有序项集构成。比如，上述原始场景序列中的每个元素都是一个项集，每个项集中包含一个或多个界面(即项)。

子序列(Subsequence)：给定两条序列α＝(a₁,a₂,…,a_n)，β＝(b₁,b₂,…,b_m)，如果存在整数1≤j₁<j₂…<j_n≤m，满足则称α是β的子序列，标记为即，如果保证对序列α中的每个项集，都能够在序列β中找到一个目标项集包含该项集或者等于该项集，则将序列α称为序列β的子序列。

频繁模式(Frequent Pattern)：序列数据库中出现的频率不低于预设阈值的项集、子序列或序列集合。其中，预设阈值为任一大于0的数值。

序列模式挖掘(Sequential Pattern Mining)：从序列数据库中找到满足约束条件的所有或若干频繁模式。

支持度(Support)：序列α的支持度是指α在序列数据库中出现的次数，标记为support(α)。

在序列模式挖掘算法中，不同的算法主要在以下两个步骤有所区别：A)生成和存储候选序列的过程；B)计算候选序列的支持度和频率的过程。其中，计算候选序列的支持度和频率的方法通常涉及先验算法(Apriori Based Algorithm)和模式增长算法(PatternGrowth Based Algorithm)。此外，对于生成和存储候选序列的数据结构，先验算法主要涉及水平数据表示(Horizontal Data Format)和垂直数据表示(Vertical Data Format)，而模式增长算法则主要涉及投影数据库(Projected Database)和投影树数据库(TreeProjection Database)。

基于上述分类方式，对于传统的序列模式挖掘算法来说，由于全都是基于项集来构造候选序列，而项集内具有无序性，即，项集本身作为一个集合，不考虑项集内包含的各个项的排列顺序，比如，对于在客户端上施行的AB测试来说，{图文场景→搜索场景}与{搜索场景→图文场景}构成了相同的项集，但是两者具有完全不同的业务含义，因此在利用传统的序列模式挖掘算法来进行挖掘频繁模式时，很可能所得的结果忽略了业务含义，这对于场景间的流转顺序至关重要的客户端产品来说，使得挖掘出来的频繁模式准确率下降，在AB测试实际运用中业务含义不明确。

进一步的，传统的序列模式挖掘算法，在生成候选序列时，仅考虑项的包含关系以及项集的相对位置，但在实际业务中，场景的连续性是非常重要的。比如，{图文场景→搜索场景}是{图文场景→主feeds场景→搜索场景}的子序列，但是两者的业务含义是不同的，其中，主feeds是指客户端上提供的信息流、数据流或者视频流，是一种呈现内容给用户并持续更新的方式。由于传统的序列模式挖掘算法，往往是基于项的包含关系来生成候选序列，且有序项集的定义中仅考虑项集的相对位置，因此可能挖掘得到实际业务不存在、或者业务意义不明确的频繁模式。

进一步的，传统的序列模式挖掘算法都仅考虑序列的支持度，在实际业务中，除了考虑支持度之外，通常需要自定义约束，比如还可能需要考虑用户在某一界面的消费时长(即网页的停留时长，或者视频的播放时长等)，或者序列的长度，或者指定频繁模式中必须包含某一界面(即必须包含一个指定场景)，因此传统的序列模式挖掘算法的自定义约束不够灵活，无法满足业务需求。

进一步的，在对AB测试进行分析的过程中，序列挖掘能够帮助业务方理解AB测试的生效流程。然而传统的序列模式挖掘算法无法与AB测试的实验信息有效结合，因此输出的频繁模式往往不能很好地辅助进行实验决策。

有鉴于此，本申请实施例涉及一种基于用户账号的行为数据进行序列模式挖掘的方式，结合AB测试的实验信息，推断AB测试的实验策略生效的主要路径(即挖掘出符合条件的场景序列)，通过拉取和筛选实验指标的显著性检验结果，得到数据驱动的测试生效链路图(即构建场景关系图)。

以下，对本申请实施例的系统架构进行说明。

图1是本申请实施例提供的一种数据处理方法的实施环境示意图。参见图1，该实施环境包括终端101和服务器102，下面进行说明：

终端101安装和运行有业务相关的应用程序即客户端，该应用程序包括但不限于：浏览器应用、直播应用、社交应用、点餐应用、支付应用、打车应用、短视频应用等。其中，该客户端与目标测试(AB测试)所针对的新版本或者新功能相关联。

终端101通过有线或无线通信方式与服务器102进行直接或间接地连接，本申请实施例在此不对连接方式进行限制。

服务器102用于为上述应用程序提供后台服务，服务器102包括一台服务器、多台服务器、云计算平台或者虚拟化中心中的至少一种。可选地，服务器102承担主要计算工作，终端101承担次要计算工作；或者，服务器102承担次要计算工作，终端101承担主要计算工作；或者，服务器102和终端101两者之间采用分布式计算架构进行协同计算。如本申请所公开的数据处理方法，其中测试时间段中采集到的账号的行为数据可保存于区块链上。其中，该测试时间段也称为测试周期。

在一个示例性场景中，在针对优化目标设计了两个或两个以上方案之后，服务器102随机向终端101的客户端(即应用程序)分发其中一个方案，使得终端101能够收集在指定的测试时间段中，登录该客户端的账号所产生的一系列行为数据，接着，将该账号的行为数据上报至服务器102，以便于服务器102进行本申请实施例涉及的数据处理方法。

在一些实施例中，服务器102是独立的物理服务器，或者是多个物理服务器构成的服务器集群或者分布式系统，或者是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN(Content Delivery Network，内容分发网络)、以及大数据和人工智能平台等基础云计算服务的云服务器。

在一些实施例中，终端101包括但不限于：智能手机、平板电脑、笔记本电脑、台式计算机、智能语音交互设备、智能家电、车载终端、智能音箱、智能手表、飞行器、MP3(MovingPicture Experts Group Audio Layer III，动态影像专家压缩标准音频层面3)播放器、MP4(Moving Picture Experts Group Audio Layer IV，动态影像专家压缩标准音频层面4)播放器、电子书阅读器等，但并不局限于此。

本申请实施例可应用于各种场景，包括但不限于云技术、人工智能、智慧交通、辅助驾驶等。

本领域技术人员可以知晓，上述终端101的数量可以更多或更少。比如上述终端101可以仅为一个，或者上述终端101为几十个或几百个，或者更多数量。本申请实施例对终端101的数量和设备类型不加以限定。

图2是本申请实施例提供的一种数据处理方法的流程图。参见图2，该实施例由计算机设备执行，以计算机设备为服务器为例进行说明，该实施例包括：

201、服务器获取目标测试关联的每个账号的多个第一场景序列，该第一场景序列用于表征该账号从客户端的第一界面跳转至的至少一个第二界面以及界面间的跳转顺序。

服务器是计算机设备的一种示例性说明，包括但不限于：独立的物理服务器，或者多个物理服务器构成的服务器集群或者分布式系统，或者提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN以及大数据和人工智能平台等基础云计算服务的云服务器。

目标测试是指在客户端上实行的针对任一客户端版本或当前客户端上任一功能的AB测试。其中，AB测试的测试对象包括但不限于：新的客户端版本、当前客户端版本上线的新增功能、当前客户端版本上某个界面的布局修改、当前客户端版本上某个控件的外观重新设计、当前客户端版本上某一交互流程的修改等，本申请实施例对AB测试的测试对象不进行具体限定。

目标测试关联的账号，是指目标测试施行的客户端上所登录的账号，其中，该客户端包括但不限于：浏览器应用、直播应用、社交应用、点餐应用、支付应用、打车应用、短视频应用等，本申请实施例对客户端类型不进行具体限定。

通常，在目标测试即AB测试中，会划分成一个或多个测试时间段(相当于多个测试周期)，在每个测试时间段内，针对本次的测试对象会设计多个方案，例如，对某个界面涉及两种或两种以上布局，或者对某个控件设计两种或两种以上触发方式等待，接着，随机向安装了客户端的终端投放相关的安装包，比如是一个新的客户端版本的安装包，或者是当前客户端版本的更新包，该更新包可以支持冷更新或者热更新等不同更新方式，以使得用户在使用客户端时能够体验到AB测试的测试对象，并通过触发行为产生相关账号的行为数据，服务器收集登录该客户端的账号的行为数据。

其中，该行为数据是指客户端采集到的一些基于用户对界面跳转的触发行为，在跳转到某一界面后，会在客户端与服务器之间的会话中上报当前界面所对应的场景ID(Identification，标识)，这一场景ID也视为是对界面类型的标识信息，比如，由于个性化推荐模式，服务器会对不同账号在主feeds页中推荐不同的内容，但是客户端会在用户停留在主feeds页进行浏览时，均上报主feeds流对应的场景ID，这是由于不同主feeds页所对应的界面类型是相同的，均属于主feeds流，只是推荐内容存在个体差异。

服务器收集到目标测试关联的各个账号的行为数据之后，解析得到每个行为数据中记录的一串场景ID，这些场景ID能够反映出来客户端的场景流转顺序，以及在每个场景中的消费时长，其中，场景流转顺序是指用户从某一类界面依次跳转到其他界面的先后顺序，在每个场景中消费时长则是指用户在任一界面的停留时长，比如对于图文资讯来说停留时长是指浏览时长，对于短视频或者小视频来说停留时长是指播放时长。对上述每个账号对应的一串场景ID进行预处理，能够得到一个序列数据库，从序列数据库中筛选出每个账号对应的多个第一场景序列，即每个账号均能够从序列数据库中获取到多个第一场景序列。

其中，第一场景序列包括按照跳转顺序有序排列的一个或多个界面，并且第一场景序列是以第一界面为起点的，换言之，第一场景序列的第一个元素一定是第一界面。示意性地，第一场景序列中包括按照跳转顺序有序排列的多个界面ID，或者按照跳转顺序有序排列的多个界面对应的多个场景ID，本申请实施例对第一场景序列的组成结构不进行具体限定。

第一界面是指目标测试的测试生效场景对应的界面类型，第二界面则是指除了第一界面之外的任一界面。本申请实施例涉及的不同界面，是按照界面类型进行区分的，即，界面类型相同的界面，不论界面内容相同还是不同，在本申请实施例中均属于同一界面，只有界面类型不同的界面在本申请实施例中属于不同界面，后面将不做赘述。

可选地，第一界面由技术人员进行指定，或者第一界面由技术人员指定的测试生效场景来确定得到。示意性地，技术人员在服务器中直接输入第一界面，从而服务器在序列数据库中，对每个账号筛选出多个以第一界面为第一个元素的第一场景序列。示意性地，技术人员在服务器中输入测试生效场景，服务器基于场景与界面的映射关系，获取与该测试生效场景对应的界面为第一界面，接着，在序列数据库中，对每个账号筛选出多个以第一界面为第一个元素的第一场景序列，在后续实施例中将详细介绍第一场景序列的获取方式，这里不做赘述。

202、服务器从该多个第一场景序列中，筛选得到每个账号的第二场景序列，该第二场景序列的至少一个业务指标符合第一目标条件。

其中，第一目标条件是指每个账号的最佳场景序列的筛选条件。

可选地，第一目标条件为：在该至少一个业务指标上的指标值具有最高的评分参数，其中评分参数用于表征对场景序列在该至少一个业务指标的指标值的综合评估。

可选地，第一目标条件为：在该至少一个业务指标上的指标值所对应的评分参数大于第一评分阈值，其中第一评分阈值为任一大于0的数值。

可选地，第一目标条件为：在该至少一个业务指标上的指标值所对应的评分参数在从大到小的排序中位于前S位，其中，S为大于或等于1的整数。

其中，业务指标是指对目标测试预先设置的一个或多个类型的业务指标，或者，该业务指标是指在挖掘频繁模式(即分析目标测试收集的行为数据)时最新设置的一个或多个业务指标，或者，该业务指标是上述对目标测试预先设置的业务指标与挖掘频繁模式时最新设置的业务指标之间的交集。

在一些实施例中，服务器对每个账号，确定该账号的多个第一场景序列，对该多个第一场景序列中任一第一场景序列，获取该第一场景序列在该至少一个业务指标上的指标值，接着，基于该第一场景序列在该至少一个业务指标上的指标值，获取该第一场景序列的评分参数(即第一评分参数)，从而选择评分参数符合第一目标条件的第一场景序列为该第二场景序列。

在一些实施例中，当第一目标条件为：在该至少一个业务指标上的指标值具有最高的评分参数时，则对每个账号，选择评分参数最高的第一场景序列为该账号的第二场景序列。

在一些实施例中，当第一目标条件为：在该至少一个业务指标上的指标值所对应的评分参数大于第一评分阈值时，则对每个账号，从评分参数大于第一评分阈值的各个第一场景序列中随机选择一个作为该账号的第二场景序列。

在一些实施例中，当第一目标条件为：在该至少一个业务指标上的指标值所对应的评分参数在从大到小的排序中位于前S位时，则对每个账号，将该账号的各个第一场景序列按照评分参数从大到小的顺序进行排序，从排序位于前S位的第一场景序列中随机选择一个作为该账号的第二场景序列。

203、服务器从多个账号的该第二场景序列中，筛选得到至少一个第三场景序列，该第三场景序列的至少一个业务指标符合第二目标条件。

其中，第二目标条件是指从参与目标测试的所有账号的最佳场景序列中进一步选取最优场景序列的筛选条件。

可选地，第二目标条件为：在该至少一个业务指标上的指标值具有最高的评分参数。

可选地，第二目标条件为：在该至少一个业务指标上的指标值所对应的评分参数大于第二评分阈值，其中第二评分阈值为任一大于0的数值。

可选地，第二目标条件为：在该至少一个业务指标上的指标值所对应的评分参数在从大到小的排序中位于前K位，其中，K为大于或等于1的整数。

需要说明的是，上述步骤202筛选第二场景序列的评分参数所使用的得分函数，和上述步骤203筛选第三场景序列的评分参数所使用的得分函数相同或者不同，本申请实施例对此不进行具体限定。此外，即使上述步骤202和203采取相同的得分函数，但对同一场景序列也有可能计算得到不同的评分参数，比如，当得分函数中包含频率这一项时，在上述步骤202中每个第一场景序列的频率，是指当前第一场景序列在全体账号的所有第一场景序列中出现的频率，而在上述步骤203中每个第二场景序列的频率，是指当前第二场景序列在所有第二场景序列中出现的频率，因此在上述步骤202已经对每个第二场景序列计算了评分参数的情况下，需要在步骤203中再次计算评分参数以选取出第三场景序列，在下一实施例中，将以第一评分参数和第二评分参数来进行区分，这里不做赘述。

需要说明的是，上述步骤202筛选第二场景序列使用的业务指标，和上述步骤203筛选第三场景序列的使用的业务指标相同或者不同，本申请实施例对此不进行具体限定。

在一些实施例中，服务器在通过上述步骤202，对每个账号筛选得到对应的第二场景序列之后，需要通过上述步骤203，进一步从所有账号的第二场景序列中筛选得到一个或多个第三场景序列，并依此来进行数据分析，获取本次目标测试的业务分析数据。

在一些实施例中，对每个第二场景序列，获取该第二场景序列在该至少一个业务指标上的指标值，接着，基于该第二场景序列在该至少一个业务指标上的指标值，获取该第二场景序列的评分参数(即第二评分参数)，从而选择评分参数符合第二目标条件的第二场景序列为该第三场景序列。

可选地，技术人员在开启对目标测试的数据分析时指定本次输出的第三场景序列的数量，该输出的第三场景序列的数量为大于或等于1的整数，当技术人员没有指定本次输出的第三场景序列的数量时，可设置本次输出的第三场景序列的数量为默认值，例如，默认值为1，或者默认值为2等，本申请实施例不对技术人员是否必须指定本次输出的第三场景序列的数量以及默认值的设置进行具体限定。

在一些实施例中，如果技术人员指定本次输出的第三场景序列的数量为1，或者取默认值且默认值为1，那么可将第二目标条件设置为：在该至少一个业务指标上的指标值具有最高的评分参数，此时从所有的第二场景序列中，选择评分参数最高的第二场景序列为第三场景序列，此时输出的第三场景序列仅有一个。

在一些实施例中，如果技术人员指定本次输出的第三场景序列的数量大于1，或者取默认值且默认值大于1，那么可将第二目标条件设置为：在该至少一个业务指标上的指标值所对应的评分参数大于第二评分阈值，此时从评分参数大于第二评分阈值的各个第二场景序列中随机选择符合技术人员指定的数量或者默认值的第三场景序列。

在一些实施例中，如果技术人员指定本次输出的第三场景序列的数量大于1，或者取默认值且默认值大于1，那么可将第二目标条件设置为：在该至少一个业务指标上的指标值所对应的评分参数在从大到小的排序中位于前K位，则将各个第二场景序列按照评分参数从大到小的顺序进行排序，然后将排序位于前K位的K个第二场景序列作为该第三场景序列，其中K是指技术人员指定本次输出的第三场景序列的数量，或者在技术人员没有指定本次输出的第三场景序列的数量时则K取默认值。

204、服务器基于该至少一个第三场景序列，获取该目标测试的业务分析数据，该业务分析数据用于分析该目标测试对该客户端中以该第一界面为起点的场景跳转的业务影响。

在一些实施例中，服务器可直接对每个第三场景序列，获取该第三场景序列在每个业务指标上的指标值，并对每个业务指标的指标值进行假设检验，例如对每个业务指标的指标值进行显著性检验，从而将该至少一个第三场景序列以及每个第三场景序列在每个业务指标上的检验结果作为本次目标测试的业务分析数据，从而对外输出该业务分析数据，辅助对目标测试的测试对象进行一些业务相关的决策，比如从目标测试的多个方案中选择出一个正式上线的方案，或者再次进行方案调优等等。

在下一实施例中，还涉及一种场景关系图，即将该至少一个第三场景序列从序列数据转换成图数据，从而能够对外进行可视化的直观显示，详细请参考下一实施例，这里不做赘述。

上述所有可选技术方案，能够采用任意结合形成本公开的可选实施例，在此不再一一赘述。

本申请实施例提供的方法，通过对目标测试关联的每个账号，均获取以第一界面为起点的第一场景序列，从第一场景序列中对每个账号筛选得到业务指标符合条件的第二场景序列，再对所有账号的第二场景序列再次筛选得到业务指标符合条件的第三场景序列，利用最终的第三场景序列进行数据分析，来预测本次目标测试的业务分析数据，由于第一场景序列都是以第一界面为起点的，从而能够保证最终筛选出的第三场景序列也是以第一界面为起点，即在设定好目标测试对应的第一界面后，最终得到的业务分析数据不会偏离第一界面所在的测试生效场景，从而提高了获取到的业务分析数据的准确度。

图3是本申请实施例提供的一种数据处理方法的流程图。参见图3，该实施例由计算机设备执行，以计算机设备为服务器为例进行说明，该实施例包括：

301、服务器获取目标测试关联的每个账号在测试时间段中产生的行为数据，该行为数据用于表征对应账号在客户端所执行的界面跳转的触发行为。

目标测试是指在客户端上实行的针对任一客户端版本或当前客户端上任一功能的AB测试。通常对一次目标测试，会划分为一个或多个测试时间段，在每个测试时间段内，针对本次的测试对象会设计多个方案，随机向安装了客户端的终端投放相关的安装包，比如是一个新的客户端版本的安装包，或者是当前客户端版本的更新包，该更新包可以支持冷更新或者热更新等不同更新方式，以使得用户在使用客户端时能够参与目标测试。

在一些实施例中，在向终端投放客户端相关的安装包之后，在用户使用客户端的过程中，会产生一些对客户端中界面跳转的触发行为，从而服务器收集登录该客户端的账号的行为数据。可选地，用户在客户端中通过触发行为跳转到任一界面后，客户端在与服务器之间的会话中上报当前界面所对应的场景ID，这一场景ID也视为是对界面类型的标识信息，跳转到每个界面均执行上述操作以上报对应的场景ID。这样，从用户开启客户端到关闭客户端，服务器侧会在会话中收集到一系列按照跳转顺序先后上报的场景ID，由于在测试时间段内，用户通常存在多次开启客户端到关闭客户端的过程，因此统计测试时间段内会话中收集到的所有场景ID(场景ID按照上报顺序有序排列并存储，因此能够反映出客户端的场景流转顺序)，即可构成每个账号在该测试时间段中产生的行为数据。

在一些实施例中，除了场景ID之后，客户端还在测试时间段中统计账号在每个界面中的停留时长，比如对于图文资讯来说停留时长是指浏览时长，对于短视频或者小视频来说停留时长是指播放时长，上述停留时长能够反映出来用户在每个场景中的消费时长。可选地，客户端在会话中上报账号在每个界面中的停留时长，即上报界面对应的场景ID和停留时长，或者，服务器每当接收到一个新的场景ID时，将新的场景ID与上一个场景ID之间的间隔时长确定为在上一个场景ID对应界面的停留时长，本申请实施例对此不进行具体限定。这一停留时长可投入到下述步骤304和307中，作为业务特征的一个维度来衡量对应的评分参数。当然，服务器也可以不收集上述停留时长，以简化数据处理流程，本申请实施例对此不进行具体限定。

302、服务器对每个账号，基于该账号的行为数据，获取该账号的原始场景序列，该原始场景序列用于表征基于该触发行为跳转至的各个界面以及界面间的跳转顺序。

在一些实施例中，对每个账号的行为数据，将账号在测试时间段中上报的各个场景ID，按照上报时间从先到后的顺序进行排列，比如，在测试时间段的第一天，收集到了[场景ID₁，场景ID₂，…，场景ID_n]，其中n≥1，在测试时间段的第二天，收集到了[场景ID’₁，场景ID’₂，…，场景ID’_m]，其中m≥1，以此类推，按照时间先后顺序，将测试时间段的各天的场景ID排列成一个原始场景序列[场景ID₁，场景ID₂，…，场景ID_n，场景ID’₁，场景ID’₂，…，场景ID’_m，…]。

在一些实施例中，还可以将上述序列中的每个场景ID，转换成与该场景ID对应的界面ID，将界面ID形成的序列作为本账号的原始场景序列，即，以[界面ID₁，界面ID₂，…，界面ID_n，界面ID’₁，界面ID’₂，…，界面ID’_m，…]作为原始场景序列，本申请实施例不对原始场景序列中的原始取场景ID还是界面ID进行具体限定。

需要说明的是，本申请实施例涉及的不同界面，是按照界面类型进行区分的，即，界面类型相同的界面，不论界面内容相同还是不同，在本申请实施例中均属于同一界面，只有界面类型不同的界面在本申请实施例中属于不同界面，后面将不做赘述。

上述目标测试关联的所有账号的原始场景序列，可构成一个序列数据库D，该序列数据库D由目标测试的测试时间段内用户的账号的行为数据预处理得到。可选地，序列数据库D除了包含原始场景序列之外，还包括账号在每个场景的消费时长(即账号在每个界面的停留时长)。如表1所示，示出了一种可能的序列数据库。

表1

其中，实验层号(layer_id)是指目标测试所属实验分层的分层ID，通过分层ID能够唯一标识AB测试所属实验分层，由于对不同产品会进行不同的AB测试，同一产品也会进行不同的AB测试，因此为了确保测试之间的正交性，对AB测试提出实验分层的概念，保证每个实验层中的各个实验桶是互斥的，即各个实验桶互相独立、互不干扰。通常，同一类型的AB测试会分配到同一个实验分层中进行，比如，测试1是将控件字体修改成蓝色，测试2是将控件背景修改成蓝色，如果同一账号同时命中了测试1和测试2，那么将无法看清控件上的文字，造成糟糕的使用体验，通过将测试1和测试2(同类型的测试，均修改UI布局设计)分配相同的层ID即添加到同一实验分层中，再选取不同的实验桶号进行实验，能够使得测试1和测试2相互独立、互不影响，从而能够避免同类型的测试产生干扰。

其中，实验桶号(experiment_id)是指目标测试所划分成的多个实验桶的桶ID，对同一个目标测试通常会将全量参与测试的账号划分至多个实验桶中，即将账号进行归类便于进行统计，因此对每个实验桶会分配唯一标识的桶ID。

其中，账号ID(guid)是指登录每个客户端的账号的账号ID，能够唯一标识一个终端，从而唯一标识该终端对应的用户，该账号ID可以是指账号的标识，或者是终端的标识，或者是用户的标识，本申请实施例对此不进行具体限定。

其中，各session即会话内的场景上报id(scene_no_seq)是指每个账号在客户端与服务器之间的会话中上报的一连串按照时间先后顺序排列的场景ID。

其中，用户的场景流转序列(scene_seq)则是指本申请实施例涉及的每个账号的原始场景序列，在表1中以原始场景序列中的每个元素都是场景名称为例，在一些实施例中，原始场景序列中的每个元素还可以是场景ID，或者场景对应的界面ID等，只要能够标识出跳转到的不同界面以及界面间的跳转顺序即可，这里不做具体限定。

其中，用户在各个场景内的消费时长(use_time_seq)是指每个账号在其场景流转序列中的每个场景的消费时长，即每个账号在其原始场景序列中每个元素所指示界面的停留时长。

303、服务器基于测试生效场景关联的第一界面，对该账号的原始场景序列进行划分，得到该账号的多个第一场景序列，其中，该第一场景序列的第一个元素为该第一界面。

其中，第一场景序列用于表征该账号从客户端的第一界面跳转至的至少一个第二界面以及界面间的跳转顺序。

其中，第一界面是指目标测试的测试生效场景scene_t对应的界面类型。

其中，第二界面则是指除了第一界面之外的任一界面。

可选地，第一界面由技术人员进行指定，示意性地，技术人员在服务器中直接输入第一界面。

可选地，第一界面由技术人员指定的测试生效场景scene_t来确定得到，示意性地，技术人员在服务器中输入测试生效场景scene_t，服务器基于场景与界面的映射关系，获取与该测试生效场景scene_t对应的界面为第一界面。

在一些实施例中，对每个账号的原始场景序列，如果该原始场景序列中的每个元素均为场景名称，在给定测试生效场景scene_t的情况下，或者给定第一界面，根据场景与界面的映射关系获取到第一界面对应的测试生效场景scene_t的情况下，以测试生效场景scene_t作为截断点，将原始场景序列切分成多个以测试生效场景scene_t为起点的子序列，这些切分得到的子序列也即该账号的多个第一场景序列。

在一个示例性场景中，对于序列数据库D，获取技术人员输入的测试生效场景scene_t。对每个账号的原始场景序列α，在进行数据分析时，总是从测试生效场景scene_t开始，到测试生效场景scene_t结束，因此，对每个账号的原始场景序列α在测试生效场景scene_t处截断，形成若干子序列S，这些截断形成的子序列S就是每个账号的多个第一场景序列。

假设S_i表示账号j的第i条第一场景序列，s₀表示测试生效场景scene_t，那么账号j的第i条第一场景序列S_i的表达式如下：

S_i＝s₀→s₁→…→s_pi，其中，i＝1,…,n_j

该第一场景序列S_i的长度为p_i+1，n_j表示账号j所对应的第一场景序列的数量，即n_j代表账号j的原始场景序列能够截断得到了几个第一场景序列。

在一些实施例中，对每个账号的原始场景序列，如果该原始场景序列中的每个元素均为场景ID，在给定测试生效场景scene_t的情况下，或者给定第一界面，根据场景与界面的映射关系获取到第一界面对应的测试生效场景scene_t的情况下，以测试生效场景scene_t对应的场景ID＝s₀作为截断点，将原始场景序列切分成多个以s₀为起点的子序列，这些切分得到的子序列也即该账号的多个第一场景序列。

在一些实施例中，对每个账号的原始场景序列，如果该原始场景序列中的每个元素均为界面ID，在给定测试生效场景scene_t的情况下，或者给定第一界面，根据场景与界面的映射关系获取到第一界面对应的测试生效场景scene_t的情况下，以测试生效场景scene_t对应的界面ID＝I₀作为截断点，将原始场景序列切分成多个以I₀为起点的子序列，这些切分得到的子序列也即该账号的多个第一场景序列。

在上述步骤301-303中，服务器获取到了目标测试关联的每个账号的多个第一场景序列，可选地，除了测试生效场景scene_t对原始场景序列进行截断之外，还可以直接从客户端在会话中上报的一系列场景ID中，查找到所有与测试生效场景scene_t对应的场景ID＝s₀，将从每个s₀开始(包含当前s₀)到下一个s₀之前(不包含下一个s₀)的所有场景ID确定为当前账号的一个第一场景序列，以此类推，能够直接从行为数据中获取到每个账号的多个第一场景序列，本申请实施例不对第一场景序列的获取方式进行具体限定。

304、服务器对每个账号，基于至少一个业务指标，获取该账号的每个第一场景序列的第一评分参数，该第一评分参数用于表征该第一场景序列在该至少一个业务指标上的综合评分情况。

在一些实施例中，服务器对每个账号，获取该账号的每个第一场景序列在该至少一个业务指标上评估得到的指标值。针对每个账号的所有第一场景序列，进行账号粒度的场景序列评分。

可选地，该业务指标是指对目标测试预先设置的一个或多个类型的业务指标，即，该业务指标是在目标测试开始之前测试人员指定的测试指标。

可选地，该业务指标是指在挖掘频繁模式(即分析目标测试收集的行为数据)时最新设置的一个或多个业务指标，即，该业务指标是由技术人员在开启对目标测试的数据分析时指定的用户粒度的评分指标。

可选地，该业务指标是上述对目标测试预先设置的业务指标与挖掘频繁模式时最新设置的业务指标之间的交集，本申请实施例对使用的业务指标不进行具体限定。

在进行账号粒度的场景序列评分时，可选地，对每个账号的每个第一场景序列，基于该第一场景序列在该至少一个业务指标上评估得到的指标值，获取该第一场景序列的业务特征，换言之，服务器基于该至少一个业务指标，获取该第一场景序列的业务特征，其中，该业务特征用于表征该第一场景序列在每个业务指标上评估得到的指标值。

在一个示例性场景中，将该第一场景序列在该至少一个业务指标上评估得到的指标值，合成一个业务特征向量，业务特征向量中的每个元素为该第一场景序列在一个业务指标上评估得到的指标值。

示意性地，用户粒度评分所采用的业务指标包括：长度、频率和时长占比，其中，长度是指第一场景序列的序列长度，长度等于第一场景序列所包含的元素个数，频率是指第一场景序列在所有账号的所有第一场景序列中出现的频率，频率等于第一场景序列出现的频次除以所有账号的所有第一场景序列的数量，时长占比是指账号在当前第一场景序列的消费时长占账号在所有第一场景序列的总消费时长的比值，其中，账号在当前第一场景序列的消费时长是指账号在当前第一场景序列中每个场景上的消费时长之间的和值。在上述基础上，对每个账号的每个第一场景序列，可合成一个尺寸为3×1的业务特征向量，该业务特征向量可表示为[长度，频率，时长占比]。

进一步的，服务器获取上述至少一个业务指标的第一权重向量，该第一权重向量用于表征每个业务指标所对应的第一权重，示意性地，将该至少一个业务指标中每个业务指标对应的第一权重合成该第一权重向量，例如，在业务指标包括：长度、频率和时长占比时，获取的第一权重向量包括：长度的第一权重、频率的第一权重、时长占比的第一权重，上述3个业务指标对应的3个第一权重能够合成一个尺寸为3×1的第一权重向量，该第一权重向量可表示为[长度的第一权重，频率的第一权重，时长占比的第一权重]。

进一步的，服务器基于该第一权重向量，对该第一场景序列的业务特征进行加权，得到该第一场景序列的第一评分参数。由于业务特征并不一定以向量形式表示，因此下面将对不同情况分别进行讨论。

可选地，当该业务特征是业务特征向量的形式时，服务器将该第一权重向量与该业务特征向量进行向量点乘，得到该第一场景序列的第一评分参数。由于在向量点乘的过程中自然会将每个业务指标的指标值与第一权重相乘之后再求和，因此可将两向量的点积直接作为第一评分参数。

可选地，当该业务特征不是业务特征向量的形式时，此时可认为业务特征是该第一场景序列在该至少一个业务指标上评估得到的指标值所构成的数组(或者集合、元组等数据结构)，此时，对数组中的每个元素，将该元素与该元素对应业务指标的第一权重相乘，得到一个加权分量，将数组中所有元素的加权分量相加，得到该第一场景序列的第一评分参数。

在一个示例中，以W表示第一权重向量，在进行账号粒度的场景序列评分时，对每个账号的每个第一场景序列均使用相同的第一权重向量W，则针对账号j的第i条第一场景序列S_i，获取上述第一评分参数的得分函数P可表示为：

其中，表示第一场景序列S_i的业务特征向量，/>表示求第一权重向量W和业务特征向量/>的向量点积，W^T表示第一权重向量的转置向量。

305、服务器将第一评分参数最高的第一场景序列确定为该账号的第二场景序列，该第二场景序列的至少一个业务指标符合第一目标条件。

在本申请实施例中，以第一目标条件为：在该至少一个业务指标上的指标值具有最高的第一评分参数为例进行说明，其中第一评分参数用于表征对场景序列在该至少一个业务指标的指标值的综合评估。

在一些实施例中，服务器对每个账号的多个第一场景序列计算得到各自的第一评分参数之后，确定第一评分参数最高的第一场景序列，将该第一评分参数最高的第一场景序列确定为当前账号的第二场景序列，对每个账号重复执行上述操作，可得到每个账号的第二场景序列。

在一些实施例中，服务器对每个账号的多个第一场景序列计算得到各自的第一评分参数之后，将该多个第一场景序列按照第一评分参数从大到小的顺序进行排序，将排序位于首位的第一场景序列确定为当前账号的第二场景序列，对每个账号重复执行上述操作，可得到每个账号的第二场景序列。

在一个示例中，对目标测试关联的任一账号j，对上述步骤304所得的账号j的各个第一场景序列的第一评分参数进行倒排(即按照第一评分参数从大到小的顺序进行排序)，并确定倒排中首个第一场景序列为第二场景序列S_j*，该第二场景序列S_j*可视为账号j在测试生效场景scene_t下的最佳场景序列，第二场景序列S_j*需要满足如下条件：

/>

其中，S_i表示账号j的第i条第一场景序列，n_j表示账号j所对应的第一场景序列的数量，P(S_i)表示第一场景序列S_i的第一评分参数，j*表示账号j的所有第一场景序列的第一评分参数中的最大值。

在上述步骤304-305中，介绍了针对一种可能采用的第一目标条件，如何从该多个第一场景序列中，筛选得到每个账号的第二场景序列。但除了上述步骤305示出的第一目标条件之外，还可采用其他的第一目标条件，下面将介绍另外两种可能的第一目标条件，以及对应情况下服务器筛选第二场景序列的方式。

在一些实施例中，第一目标条件还可以为：在该至少一个业务指标上的指标值所对应的第一评分参数大于第一评分阈值，其中第一评分阈值为任一大于0的数值。此时，服务器对每个账号的多个第一场景序列计算得到各自的第一评分参数之后，从第一评分参数大于第一评分阈值的各个第一场景序列中随机选择一个作为该账号的第二场景序列。

在另一些实施例中，第一目标条件还可以为：在该至少一个业务指标上的指标值所对应的第一评分参数在从大到小的排序中位于前S位，其中，S为大于或等于1的整数。此时，服务器对每个账号的多个第一场景序列计算得到各自的第一评分参数之后，将该账号的各个第一场景序列按照第一评分参数从大到小的顺序进行排序，从排序位于前S位的第一场景序列中随机选择一个作为该账号的第二场景序列。

306、服务器对多个账号的该第二场景序列进行去重，得到去重后的多个第二场景序列。

在一些实施例中，服务器对每个账号均通过上述步骤305获取到一个第二场景序列，而目标测试关联于多个账号，最终遍历所有账号能够得到该多个账号各自的第二场景序列，每个第二场景序列均代表了一个账号关于测试生效场景scene_t的最佳场景序列，实现了账号粒度最佳场景序列的过滤。接下来，需要从所有账号关于测试生效场景scene_t的最佳场景序列(即该多个账号各自的第二场景序列)中，进一步筛选出全量样本下的最佳场景序列。

在一些实施例中，为了方便统计每个第二场景序列的业务特征，对该多个账号各自的第二场景序列进行去重，即，对于完全相同的多个第二场景序列，仅保留一个，去除其余重复的序列，这些重复的序列不会参与下述步骤307中计算第二评分参数，换言之，对于完全相同的多个第二场景序列进行聚合处理，从而仅计算一次第二评分参数，能够节约计算资源。

需要说明的是，由于在进行去重的过程中，会对每个第二场景序列统计其是否存在完全相同即重复的序列，因此这个过程中能够自然而然的得到每个第二场景序列出现的频次，如果下述步骤307中在计算第二评分参数时，所需要获取的业务特征中涉及频率这一业务指标，那么本步骤306中去重操作统计得到的该频次可用于计算业务特征中的频率。

307、服务器对去重后的每个第二场景序列，基于该至少一个业务指标，获取该第二场景序列的第二评分参数，该第二评分参数用于表征该第二场景序列在该至少一个业务指标上的综合评分情况。

在一些实施例中，服务器对去重后的每个第二场景序列，获取该第二场景序列在该至少一个业务指标上评估得到的指标值。针对所有账号的第二场景序列，进行全体账号的场景序列评分。

需要说明的是，上述步骤304计算第一评分参数使用的业务指标，和上述步骤307计算第二评分参数使用的业务指标相同或者不同，本申请实施例对此不进行具体限定。

可选地，第一评分参数对应的得分函数和第二评分参数对应的得分函数相同或者不同，本申请实施例对此不进行具体限定。

可选地，即使对第一评分参数和第二评分参数使用相同的得分函数和相同的业务指标，但对同一场景序列在计算第一评分参数和第二评分参数时也可能得出不同的取值，比如，当得分函数涉及的业务特征中包含频率这一项时，在计算第一评分参数时，频率的含义是指当前第一场景序列在全体账号的所有第一场景序列中出现的频率，而在在计算第二评分参数时，频率的含义是指当前第二场景序列在所有第二场景序列(是指未经去重时的全体第二场景序列)中出现的频率。因此在上述步骤304已经对每个第二场景序列计算了第一评分参数的情况下，需要在本步骤307中再次计算每个第二场景序列的第二评分参数。

可选地，对去重后的每个第二场景序列，基于该第二场景序列在该至少一个业务指标上评估得到的指标值，获取该第二场景序列的业务特征，换言之，服务器基于该至少一个业务指标，获取该第二场景序列的业务特征，其中，该业务特征用于表征该第二场景序列在每个业务指标上评估得到的指标值。

在一个示例性场景中，将该第二场景序列在该至少一个业务指标上评估得到的指标值，合成一个业务特征向量，业务特征向量中的每个元素为该第二场景序列在一个业务指标上评估得到的指标值。

示意性地，采用与上述步骤304相同的业务指标：长度、频率和时长占比，其中，长度是指第二场景序列的序列长度，长度等于第二场景序列所包含的元素个数，频率是指第二场景序列在未经去重的所有账号的第二场景序列中出现的频率，频率等于第二场景序列出现的频次(该频次可在去重过程中获取并缓存)除以所有账号的第二场景序列的数量，时长占比是指账号在当前第二场景序列的消费时长占账号在所有第二场景序列的总消费时长的比值，其中，账号在当前第二场景序列的消费时长是指账号在当前第二场景序列中每个场景上的消费时长之间的和值，如果当前第二场景序列重复出现多次，当前第二场景序列的消费时长需要将重复的序列的消费时长进行叠加累计。在上述基础上，对每个第二场景序列，可合成一个尺寸为3×1的业务特征向量，该业务特征向量可表示为[长度，频率，时长占比]。

在一个示例中，目标测试涉及5个账号，这5个账号的第二场景序列分别为{S₁，S₁，S₂，S₂和S₃}，并且这5个账号各自在第二场景序列上的消费时长分别为{1小时，2小时，8小时，4小时，0.5小时}，在对所有第二场景序列进行去重后得到了3个序列{S₁，S₂和S₃}。下面分别获取序列S₁～S₃的长度、频率和时长占比。假设序列S₁的长度为5，序列S₂的长度为4，序列S₁的长度为6。接着，由于序列S₁和S₂均出现了两次，因此序列S₁和S₂的频率均为2/5，序列S₃仅出现了一次，因此序列S₃的频率为1/5。接着，5个账号的总消费时长一共为(1+2+8+4+0.5)＝15.5小时，对于序列S₁由于出现了两次，因此序列S₁的消费时长共计(1+2)＝3小时，序列S₁的时长占比为3/15.5＝19.4％，同理，可获取到序列S₂的时长占比为(8+4)/15.5＝77.4％，序列S₃的时长占比为0.5/15.5＝3.2％。

进一步的，服务器获取上述至少一个业务指标的第二权重向量，该第二权重向量用于表征每个业务指标所对应的第二权重，示意性地，将该至少一个业务指标中每个业务指标对应的第二权重合成该第二权重向量，例如，在业务指标包括：长度、频率和时长占比时，获取的第二权重向量包括：长度的第二权重、频率的第二权重、时长占比的第二权重，上述3个业务指标对应的3个第二权重能够合成一个尺寸为3×1的第二权重向量，该第二权重向量可表示为[长度的第二权重，频率的第二权重，时长占比的第二权重]。每个业务指标所对应的第一权重和第二权重可以相同或者不同，本申请实施例对此不进行具体限定。

进一步的，服务器基于该第二权重向量，对该第二场景序列的业务特征进行加权，得到该第二场景序列的第二评分参数。由于业务特征并不一定以向量形式表示，因此下面将对不同情况分别进行讨论。

可选地，当该业务特征是业务特征向量的形式时，服务器将该第二权重向量与该业务特征向量进行向量点乘，得到该第二场景序列的第二评分参数。由于在向量点乘的过程中自然会将每个业务指标的指标值与第二权重相乘之后再求和，因此可将两向量的点积直接作为第二评分参数。

可选地，当该业务特征不是业务特征向量的形式时，此时可认为业务特征是该第二场景序列在该至少一个业务指标上评估得到的指标值所构成的数组(或者集合、元组等数据结构)，此时，对数组中的每个元素，将该元素与该元素对应业务指标的第二权重相乘，得到一个加权分量，将数组中所有元素的加权分量相加，得到该第二场景序列的第二评分参数。

308、服务器按照第二评分参数从大到小的顺序对去重后的各个第二场景序列进行排序，将在该排序中位于前目标数量的第二场景序列确定为至少一个第三场景序列，该第三场景序列的至少一个业务指标符合第二目标条件。

在本申请实施例中，以第二目标条件为：在该至少一个业务指标上的指标值所对应的第二评分参数在从大到小的排序中位于前K位为例进行说明，其中，K是指目标数量，目标数量K为大于或等于1的整数。

在一些实施例中，服务器对每个第二场景序列计算得到各自的第二评分参数之后，将该各个第二场景序列按照第二评分参数从大到小的顺序进行排序，将排序位于前K位(即top K)的第二场景序列确定为至少一个(即K个)第三场景序列。

可选地，目标数量K由技术人员在开启对目标测试的数据分析时人工指定，即技术人员向服务器输入目标数量K，此外，当技术人员没有指定目标数量K时，服务器可将目标数量K设置为默认值(默认值为大于或等于1的整数)，例如，默认值为1，或者默认值为2等，本申请实施例不对技术人员是否必须指定目标数量K进行具体限定，也不对默认值进行具体限定。

在一些实施例中，如果技术人员指定目标数量K＝1，或者目标数量K取默认值且默认值为1，此时第二目标条件等同于：在该至少一个业务指标上的指标值具有最高的第二评分参数，此时从所有的第二场景序列中，选择第二评分参数最高的第二场景序列为第三场景序列，此时输出的第三场景序列仅有一个。

在一些实施例中，如果技术人员指定目标数量K＞1，或者目标数量K取默认值且默认值大于1，在第二目标条件为：在该至少一个业务指标上的指标值所对应的第二评分参数在从大到小的排序中位于前K位的情况下，则将各个第二场景序列按照第二评分参数从大到小的顺序进行排序，然后将排序位于前K位的K个第二场景序列作为至少一个(共K个)第三场景序列。

在一个示例中，在给定目标数量K的情况下，对上述步骤307所得的各个第二场景序列的第二评分参数进行倒排(即按照第二评分参数从大到小的顺序进行排序)，并确定倒排中位于前K个的第二场景序列为最终的K个第三场景序列{S*₍₁₎，...，S*_(k)}，其中K≥1。上述K个第三场景序列满足如下条件：

P(S*₍₁₎)≥P(S*₍₂₎)≥...≥P(S*_(k))

其中，S*表示第二场景序列，S*的角标(i)表示序列S*在倒排中所处的序号，i为大于或等于1且小于或等于K的整数，P(S*_(i))表示在倒排中处于第i位的第二场景序列S*的第二评分参数。

在上述步骤307-308中，介绍了针对一种可能采用的第二目标条件，如何从该去重后的多个第二场景序列中，基于该至少一个业务指标，筛选得到至少一个第三场景序列。但除了上述步骤308示出的第二目标条件之外，还可采用其他的第二目标条件，下面将介绍另外一种可能的第二目标条件以及对应情况下筛选第二场景序列的方式。

在一些实施例中，第二目标条件还可以为：在该至少一个业务指标上的指标值所对应的第二评分参数大于第二评分阈值，其中第二评分阈值为任一大于0的数值。此时，服务器对每个第二场景序列计算得到各自的第二评分参数之后，从第二评分参数大于第二评分阈值的各个第二场景序列中随机选择K个第二场景序列作为最终的K个第三场景序列。

在上述过程中，服务器能够从多个账号的该第二场景序列中，筛选得到至少一个第三场景序列，并且由于第三场景序列是从第二场景序列中筛选得到的，第二场景序列是从第一场景序列中筛选得到的，而第一场景序列在从原始场景序列中划分时，是以测试生效场景scene_t为基准进行截断的，因此能够保证最终输出的每个第三场景序列都是以测试生效场景scene_t或测试生效场景scene_t对应的第一界面为第一个元素的，从而保证了挖掘到的频繁模式即第三场景序列具有明确的业务含义。

309、服务器基于该至少一个第三场景序列，获取场景集合和关系集合，该场景集合用于表征各个该第三场景序列中不同界面所形成的集合，该关系集合用于表征该场景集合中不同界面之间的跳转顺序。

在一些实施例中，对该至少一个第三场景序列，获取各个第三场景序列中的所有元素，对所有元素进行去重后得到一个场景集合。

进一步的，对该至少一个第三场景序列，每个第三场景序列中任意两个相邻元素之间存在从前一个元素跳转到后一个元素的顺序，因此对每个第三场景序列中任意两个相邻的元素均生成一个表征跳转顺序的二元组，所有的二元组即可构成一个关系集合。例如，对于如下相邻元素：场景1和场景2，可使用二元组(场景1，场景2)表示其场景流转顺序是从场景1到场景2，又例如，对于如下相邻元素：界面1和界面2，可使用二元组(界面1，界面2)表示其界面跳转顺序是从界面1到界面2，本申请实施例对此不进行具体限定。

310、服务器基于该场景集合和该关系集合，构建该目标测试的场景关系图，该场景关系图用于表征该客户端中在该目标测试的作用下所影响的场景跳转链路。

在一些实施例中，该场景集合可视为场景关系图的顶点(Vertices)集合，该关系集合可视为场景关系图中节点间连接关系的有向边(Directed Edges)集合，在给定顶点集合V和有向边集合E的情况下，能够将原本序列形式的数据转换成图数据，即能够构建出一张场景关系图G(V,E)。

在一些实施例中，对该场景集合中的每个界面(或场景)，在该场景关系图中生成该界面对应的节点，遍历场景集合中的所有界面(或场景)，能够在场景关系图中绘制出K个第三场景序列中涉及的所有界面(或场景)。

可选地，该场景集合中每个元素均为一个界面对应的场景(可以是场景ID或者场景名称)，此时以每个场景作为场景关系图中的一个节点，或者，以每个场景对应的界面作为场景关系图中的一个节点。

可选地，该场景集合中的每个元素均为一个界面，此时以每个界面作为场景关系图中的一个节点，或者，以每个界面对应的场景作为场景关系图中的一个界面，本申请实施例对此不进行具体限定。

在一些实施例中，对该关系集合中任意两个界面间的跳转顺序，在该场景关系图中生成该两个界面所对应的两个节点之间的有向边。示意性地，该关系集合中的每个元素均是一个二元组，二元组中包括一对场景或者一对界面，二元组中的第一个元素对应的节点则是有向边的起点，二元组中第二个元素对应的节点则是有向边的终点，遍历关系集合中的所有二元组，能够在场景关系图中绘制出所有具有跳转顺序的有向边。

在一个示例性场景中，针对场景关系图G(V,E)，其中，V代表K个第三场景序列中涉及的所有场景构成的顶点集合，E代表K个第三场景序列中所有场景间流转关系构成的有向边集合，下面将以一种可能的顶点集合V和有向边集合E，介绍如何构建场景关系图G。

图4是本申请实施例提供的一种场景关系图的示意图，如图4所示，假设顶点集合V＝{主feeds，图文，小视频浮层}，即顶点集合中涉及3个场景：主feeds、图文和小视频浮层，则在场景关系图中绘制出3个场景分别对应的3个顶点401～403，进一步的，假设有向边集合E＝{(主feeds，图文)，(主feeds，小视频浮层)}，即有向边集合中涉及从主feeds场景到图文场景的跳转，以及从主feeds场景到小视频浮层的跳转，因此在场景关系图中绘制出从主feeds场景的顶点401指向图文场景的顶点402的一条有向边411，并且，还绘制出从主feeds场景的顶点401指向小视频浮层的顶点403的另一条有向边412。

在上述过程中，该场景关系图相当于直观展示了目标测试的测试生效链路，这一测试生效链路是以给定的测试生效场景scene_t为起点的，具有明确的业务含义。在本申请实施例中，通过将构造测试生效链路的问题，转换为识别满足自定义约束(第一目标条件和第二目标条件)下的最优序列的问题，并结合图论的相关概念，将挖掘得到的最优序列转换为场景关系图这一图结构，以此作为测试生效链路的基本框架，上述从序列数据库D出发，给定测试生效场景scene_t和目标数量K之后，最终预测顶点集合V和有向边集合E的过程，构成了本申请实施例的CSG(Causal Scene Graph，因果场景图)算法，CSG算法不同于任何传统的序列模式挖掘算法，能够针对给定的测试生效场景scene_t，输出K个具有明确业务含义的频繁模式。

下面，将对CSG算法进行进一步说明，CSG算法必要的输入包括：由测试时间段内各个账号的行为数据预处理得到的序列数据库D，技术人员输入的测试生效场景scene_t和目标数量K，如果技术人员没有输入测试生效场景scene_t，则配置为预先设置的默认生效场景，如果技术人员没有输入目标数量K，则将K配置为默认值。基于上述序列数据库D、测试生效场景scene_t和目标数量K，CSG算法会返回前端绘制场景关系图G(V,E)所需的场景集合即顶点集合V和关系集合即有向边集合E。上述CSG算法的伪代码如下：

Input:A sequence database D,treatment scene scene_t,K

//输入：序列数据库D，测试生效场景scene_t，目标数量K

Output:A causal scene graph G(V,E)with top K sequences

//输出：基于top K序列(K个第三场景序列)生成的场景关系图G(V,E)

Method:CSG(D,scene_t,K)

//方法：CSG(D,scene_t,K)算法

Subroutine:score_function(α,l_α,f_α,t_α,W)

//子例程：得分函数score_function(α,l_α,f_α,t_α,W)

Parameters:α:a sequential pattern；l_α:the length of α；f_α:the frequencyof α；t_α:the time spent of α；W:a 3×1 weight matrix

//参数：α为序列模式；l_α为序列模式α的长度；f_α为序列模式α的频率；t_α为序列模式α的停留时长(或称消费时长)

Step 1:

for all raw sequence α_j of user j in D,α_j∈D do

split raw sequenceα_j into multiple subsequences by scene_t

return a set of n_j subsequences{S}_j of user j

//步骤1:对序列数据库D中账号j的任一原始场景序列α_j，以测试生效场景scene_t为截断点将α_j分割成多个子序列(即第一场景序列)，返回由账号j的n_j条子序列所构成的集合{S}_j

Step 2:

for all S_i in subsequences set{S}_j,S_i∈{S}_j do

score_function(S_i,l_Si,f_Si,t_Si,W)

return the score of S_i,P(S_i)

//步骤2:对集合{S}_j中任一第一场景序列S_i，调用得分函数score_function获取S_i的第一评分参数P(S_i)

Step 3:

given the score of each subsequence in subsequence set{S}_j

return the best subsequence S_j*of user j with the highest score

//步骤3:对集合{S}_j中每个第一场景序列均计算第一评分参数，返回账号j对应的第一评分参数最高的第二场景序列S_j*

Step 4:

for all S_j*in the best subsequence set{S*},S_j*∈{S*}do

score_function(S_j*,l_Sj*,f_Sj*,t_Sj*,W)

return the score of S_j*,P(S_j*)

//步骤4:对集合{S*}中任一第二场景序列S_j*，调用得分函数score_function获取S_j*的第二评分参数P(S_j*)

Step 5:

given a set of the best subsequence score{P(S*)}do

sort score set{P(S*)}

get a set of subsequence with top K scores,P(S*₍₁₎)≥P(S*₍₂₎)≥···≥P(S*_(k))

return a causal scene graph G(V,E)

//步骤5:对第二评分参数构成的集合{P(S*)}，获取位于top K的第三场景序列，返回场景关系图G(V,E)

需要说明的是，上述CSG算法计算第一评分参数或第二评分参数时，所使用的得分函数可由技术人员自定义，以灵活满足各种特殊的业务需求。在场景关系图中，能够直观体现出目标测试的实验策略直接作用在第一个场景即测试生效场景scene_t(同时也是所有第三场景序列的起点)，随后的场景流转链路则直观呈现用户在受到实验策略影响后的行为路径。

在本申请实施例中，通过在CSG算法中引入测试生效场景scene_t的概念，能够将序列挖掘与测试信息有效结合，此外，由于基于测试生效场景scene_t切分原始场景序列，使得能够对每个账号生成具备业务含义的子序列集(即多个第一场景序列)。进一步的，基于自定义的得分函数来对候选序列进行排序和筛选，使得筛选得到第二场景序列、筛选得到第三场景序列的两步筛选过程，能够灵活地满足各类约束条件，可满足任何业务需求，具有可移植性和高可用性。

在一些实施例中，在本步骤310中构造出场景关系图之后，将场景关系图作为目标测试的业务分析数据，在服务器侧的前端绘制出场景关系图，进行可视化展示，并退出流程，能够节约服务器的计算资源。

可选地，在本步骤310中构造出场景关系图之后，还执行下述步骤311以获取每个场景下各个业务指标的显著性检验结果，能够辅助技术人员进行更好的实验策略决策，再将场景关系图和各个显著性检验结果一起作为目标测试的业务分析数据，在服务器侧前端绘制出场景关系图的情况下，对每个场景即节点还直观标注出对应的一系列显著性检验结果，从而提高业务分析数据的丰富性，提高对目标测试的测试结果的解释能力。

311、服务器获取该场景关系图中每个节点在业务指标上的显著性检验结果。

在一些实施例中，由于场景关系图中的每个节点都唯一对应于一个场景，换言之，鉴于场景和界面之间也存在一一对应的映射关系，因此场景关系图中的每个节点都唯一对应于一个界面，而不同场景下通常具有不同的业务指标，比如，在小视频浮层这一场景下，通常比较关心小视频的秒拨率、次均时长、播放次数(Video View，VV)等指标，而在主feeds这一场景下，通常比较关心feeds刷新量、feeds曝光量和feeds点击量。

其中，秒拨率是指消费时长小于5秒的视频播放次数占全部小视频播放次数的比例，秒拨率也可视为秒划率，通常秒拨率越高代表小视频推荐不太符合用户心意导致用户很快划走，次均时长是指测试时间段内当前小视频每次的平均播放时长，播放次数是指测试时间段内当前小视频的累计播放次数。

其中，feeds刷新量是指用户总共刷新了多少feeds流，曝光量是指feeds流中有多少内容被用户浏览即曝光，feeds点击量是指feeds流中有多少内容被用户点击。

在上述基础上，可知业务指标与场景之间存在映射关系，因此测试人员可在服务器侧预先配置好业务指标与界面的映射关系(即业务指标与场景的映射关系)，同时，由于在进行目标测试的时候，为了便于统计客户端上报的各种测试数据，通常测试人员还会预先配置一个测试时间段需要使用的业务指标集合，上述业务指标与界面的映射关系以及业务指标集合都是在进行目标测试时测试人员在服务器侧预先配置的，服务器缓存业务指标与界面的映射关系以及业务指标集合，因此，在对目标测试进行数据分析时，服务器只需要获取预先配置的业务指标集合和业务指标与界面的映射关系即可。

进一步的，由于该场景关系图中仅涉及到场景集合中场景对应的界面，因此对每个界面也不需要计算业务指标集合中全部的指标，也即，服务器可基于该映射关系，从该业务指标集合中，确定与该场景集合中每个界面关联的第一业务指标，该第一业务指标是指需要参与到显著性检验的业务指标，也即需要在场景关系图中标注的业务指标。接着，服务器对该场景关系图中的每个节点，对该节点所对应界面关联的第一业务指标的指标值进行显著性检验，得到该节点的显著性检验结果。

在一些实施例中，在获取第一业务指标时，服务器获取用户输入的对该场景关系图的分析指标集合，这一分析指标集合是指技术人员在开启对目标测试的数据分析时，指定在本次数据分析中所使用的指标构成的集合。接着，对该业务指标集合和该分析指标集合做交集，换言之，获取该分析指标集合与该业务指标集合的交集，即，参与显著性检验的指标既要属于开启目标测试时预先配置的业务指标集合，也要属于开启数据分析时技术人员指定的分析指标集合。接着，对该场景集合中的每个界面，基于该映射关系，从该交集中查询得到该界面对应的第一业务指标。

在一些实施例中，在对每个第一业务指标进行显著性检验时，可基于第一业务指标的指标类型，确定显著性检验的检验方式，比如，指标类型为COUNT(计数)类时采取的检验方式为卡方检验，指标类型为UV(Unique Visitor，独立访问者数量)均值类时采取的检验方式为t检验，指标类型为PV(Page View，页面浏览量)均值类时采取的检验方式为deltamethod t检验(delta方法)，指标类型为SUM(求和)类时采用UV均值类的检验结果，指标类型为UV比例类时采用比例检验等，本申请实施例不对每类指标采用何种检验方式进行具体限定。

在上述过程中，对场景关系图中涉及的每个场景，通过拉取预先配置的业务指标集合，将该业务指标集合与技术人员设定的分析指标集合做交集，从而对交集中与场景关系图中每个场景关联的第一业务指标进行显著性检验，最终得到每个场景在各个第一业务指标上的显著性检验结果，从而能够通过下述步骤312，在前端展示场景关系图时，不仅通过场景关系图自身表征场景流转顺序，而且在场景关系图中标注每个场景对应的各个显著性检验结果，能够更加直观展示目标测试对用户行为产生了哪些影响。

312、服务器输出该场景关系图和该显著性检验结果为该目标测试的业务分析数据，该业务分析数据用于分析该目标测试对该客户端中以该第一界面为起点的场景跳转的业务影响。

在一些实施例中，在构建完毕该场景关系图，以及获取到每个场景在各个第一业务指标上的显著性检验结果之后，可对该场景关系图和各个显著性检验结果进行前端可视化展示，为了简便起见，将标注有显著性检验结果的场景关系图称为实验生效链路图(即业务分析数据)。示意性地，在对实验生效链路图进行可视化展示时，在对每个节点即场景标注显著性检验结果时，对于不同的显著性检验结果采取不同的显示方式，比如，显著性检验结果的类型包括：显著上升、显著下降、无显著差异，那么可对显著上升的第一业务指标用红色标注，对显著下降的第一业务指标用绿色标注，对无显著差异的第一业务指标用黑色标注，从而能够一目了然的区分出哪些指标上升，哪些指标下降，哪些指标基本不变。

在一些实施例中，在同一节点所对应场景下，各种业务指标之间本身也可能存在一些关联关系，比如，以主feeds场景为例，由于主feeds流中包含两种类型的内容：视频内容和图文内容，因此，feeds曝光量是由feeds视频曝光量和feeds图文曝光量两者综合计算得到，同理，feeds点击量是由feeds视频点击量和feeds图文点击量两者综合计算得到，并且，由于feeds视频又能够进一步划分为小视频和短视频，因此feeds视频点击量又是由主feeds小视频点击量和主feeds短视频点击量两者综合计算得到。因此，针对同一场景下涉及到的多个第一业务指标互相之间存在关联关系的情况，可在标注当前场景的各个第一业务指标的显著性检验结果时，显示出不同第一业务指标之间的影响链路，比如，在上述示例的基础上，绘制从主feeds小视频点击量和主feeds短视频点击量指向feeds视频点击量的有向边，同理，绘制feeds视频点击量和feeds图文点击量指向feeds点击量的有向边，同理，绘制feeds视频曝光量和feeds图文曝光量指向feeds曝光量的有向边。

在上述过程中，服务器输出的实验生效链路图对于在客户端进行的目标测试具有重大意义，能够辅助业务方在设计和评估AB测试时进行实验策略的决策，在传统的AB测试数据分析过程中，通常都需要离线手工绘制实验生效链路图，这一方式计算效率低、人力成本高，且绘制的实验生效链路图缺乏规范性，无法进行规模化和流程化。

图5是本申请实施例提供的一种实验生效链路图的示意图，如图5所示，以目标测试的实验策略为：每当进入小视频浮层的第一个视频的播放进度超过80％时，插入“同类型”视频的推荐信息为例进行说明。同时，技术人员在开启数据分析时，指定的测试生效场景scene_t为小视频浮层。

假设目标数量K＝1，此时仅筛选出一条第三场景序列：小视频浮层→主feeds场景→短视频浮层，则此时场景关系图的场景集合即顶点集合V＝{小视频浮层，主feeds场景，短视频浮层}，关系集合即有向边集合E＝{(小视频浮层，主feeds场景)，(主feeds场景，短视频浮层)}。因此，在实验生效链路图中绘制有3个场景501～503，场景501对应于小视频浮层，场景502对应于主feeds浮层，场景503对应于短视频浮层，同时，还绘制有场景501指向场景502的有向边，以及场景502指向场景503的有向边。可选地，在场景501指向场景502的有向边上添加注释信息“直接影响”，代表小视频浮层上的实验策略能够直接影响主feeds场景，在场景502指向场景503的有向边上添加注释信息“间接影响”，代表主feeds场景发生的变化能够间接影响到短视频浮层。

示意性地，在实验生效链路图中，对任一场景的任一第一业务指标，其数值表示显著性检验结果，加粗显示的数值表示显著上升，下划线显示的数值表示显著下降，常规显示的数值表示不显著。

对于小视频浮层关联的场景501，涉及4项第一业务指标：小视频秒拨率、小视频次均时长、小视频VV(即播放次数)和小视频播放时长，其中，小视频播放时长基于小视频VV和小视频次均时长相乘得到，因此存在从小视频VV和小视频次均时长指向小视频播放时长的有向边，此外，只有在播放小视频之后才能够统计次均时长，因此存在从小视频秒拨率指向小视频次均时长的有向边。此时，可知小视频VV和小视频播放时长显著上升，小视频秒拨率和小视频次均时长显著下降。

对于主feeds关联的场景502，涉及的第一业务指标包括：feeds刷新量、feeds曝光量和feeds点击量，其中，feeds曝光量包括feeds视频曝光量和feeds图文曝光量，feeds点击量包括feeds视频点击量和feeds图文点击量，feeds视频点击量包括主feeds小视频点击量和主feeds短视频点击量，即一种涉及到9项第一业务指标。基于上述业务指标之间的关联关系，由于feeds刷新量影响其对应曝光量，因此，存在从feeds刷新量分别指向feeds视频曝光量和feeds图文曝光量的有向边，由于feeds视频曝光量和feeds图文曝光量决定了feeds曝光量，因此存在从feeds视频曝光量和feeds图文曝光量两者指向feeds曝光量的有向边，进一步的，由于feeds曝光量影响其对应点击量，因此存在从feeds视频曝光量指向feeds视频点击量的有向边、从feeds图文曝光量指向feeds图文点击量的有向边以及从feeds曝光量指向feeds点击量的有向边，并且，由于feeds视频点击量和feeds图文点击量决定了feeds点击量，因此存在从feeds视频点击量和feeds图文点击量指向feeds点击量的有向边，此外，由于主feeds小视频点击量和主feeds短视频点击量决定了feeds视频点击量，因此存在从主feeds小视频点击量和主feeds短视频点击量指向feeds视频点击量的有向边。此时，可知上述9项第一业务指标均显著下降。在一些实施例中，技术人员在主feeds场景502添加备注信息“跷跷板效应”，以解释为何主feeds场景502的各项第一业务指标均显著下降。

对于短视频浮层关联的场景503，涉及3项第一业务指标：短视频VV、短视频次均时长和短视频播放时长，其中，短视频播放时长基于短视频VV和短视频次均时长相乘得到，因此存在从短视频VV和短视频次均时长指向短视频播放时长的有向边。此时，可知短视频VV和短视频播放时长均无显著变化，但短视频次均时长显著上升。可选地，技术人员在短视频浮层的场景503中添加备注信息“连带效应”，以解释相关第一业务指标的变化原因。

进一步的，结合场景501～503各自的第一业务指标，获取全场景504的业务指标变化情况。一方面，在全场景504中，小视频VV显著上升，短视频VV显著下降，两者综合计算得到视频VV显著上升，结合显著上升的视频VV和显著下降的图文PV(Page View，图文页面浏览量)，两者综合计算得到总分发显著上升。另一方面，在全场景504中，小视频播放时长显著上升，短视频播放时长无显著变化，两者综合计算得到视频消费总时长显著上升，结合显著上升的视频消费总时长和显著下降的图片总浏览时长，两者综合计算得到消费总时长显著上升。全场景504相当于是对整条测试生效链路的大盘总览。

在上述过程中，实验生效链路图既能够反映出场景间的流转链路，也能够反映出场景内的指标影响链路，在图5所示的实验生效链路图出发进行分析，可知这一目标测试的实验策略，能够显著降低小视频秒拨率，但显著提升小视频播放时长和小视频VV，使得用户在小视频浮层的消费增加，但是由于跷跷板效应的作用，会导致用户在主feeds场景的消费减少，最终从大盘来看，虽然使得图文和短视频在曝光、点击和时长上均由一定程度的下降，但由于对小视频的各项指标提升显著，因此总分发和总消费时长均显著上升，在全量标准看来这一实验策略符合应用条件。

在上述步骤309-312中，服务器基于该至少一个第三场景序列，获取该目标测试的业务分析数据，这里仅以业务分析数据包括场景关系图和各个第一业务指标的显著性检验结果为例进行说明，在一些实施例中，该业务分析数据也可以仅包含场景关系图，本申请实施例对此不进行具体限定。

在上述实施例中，详细介绍了CSG算法如何生成场景关系图的顶点集合和有向边集合，以及服务器如何基于顶点集合、有向边集合，对场景关系图及其各个场景的显著性检验结果进行前端可视化展示。

在本申请实施例中，CSG算法还支持用户输入一个自定义的目标界面，在用户输入了目标界面的情况下，CSG算法除了按照上述实施例的方法预测出K个第三场景序列之外，还需要额外预测出一条包含该目标界面的目标场景序列，并，将目标场景序列和第三场景序列一起投入到场景关系图的场景集合和关系集合的获取步骤中，从而能够将目标场景序列也绘制在场景关系图中。

在一些实施例中，响应于用户对目标界面的输入操作，服务器获取输入的目标界面，可选地，CSG算法可支持用户输入的目标界面的数量为一个或者多个，本申请实施例对此不进行具体限定，例如，CSG算法支持用户最多输入2个目标界面，但用户也可以不输入目标界面，比如，最多允许用户输入的2个界面分别称为直接影响产品和间接影响产品，直接影响产品对应的目标界面是指用户预先配置的该目标测试能够直接作用的场景，而间接影响产品对应的目标界面则是指用户预先配置的该目标测试能够间接作用的场景。

图6是本申请实施例提供的一种CSG算法的输入参数配置界面的界面示意图，如图6所示，在CSG算法的输入参数配置界面600中，包括测试生效场景的配置区域601、直接影响产品的配置区域602、间接影响产品的配置区域603以及目标数量K的配置区域604，由于直接影响产品和间接影响产品两者统称目标界面，因此直接影响产品的配置区域602和间接影响产品的配置区域603均用于配置目标界面，其中，测试生效场景和目标数量K是CSG算法必须配置的参数，而直接影响产品和间接影响产品则可基于业务需求进行配置或者不配置。

在一些实施例中，服务器在获取到目标界面之后，确定上述步骤308中获取到的至少一个第三场景序列中是否存在任一第三场景序列包含该目标界面，在该至少一个第三场景序列中任一第三场景序列包含该目标界面的情况下，输出包含该目标界面的第三场景序列为目标场景序列；在该至少一个第三场景序列均不包含该目标界面的情况下，输出从多个账号的第二场景序列中筛选得到的目标场景序列，该目标场景序列包含该目标界面，且该目标场景序列的至少一个业务指标符合第三目标条件。

在一些实施例中，在筛选目标场景序列的过程中，与筛选第三场景序列的过程类似，也即是说：服务器对多个账号的该第二场景序列进行去重，得到去重后的多个第二场景序列，去重过程与上述步骤306类似，这里不做赘述，此时也可直接调用上述步骤306中去重后的多个第二场景序列，而无需重复进行去重；接着，从该去重后的多个第二场景序列中，筛选得到包含该目标界面的各个第二场景序列，也即仅从包含该目标界面的各个第二场景序列中来实现对目标场景序列的筛选；接着，从包含该目标界面的各个第二场景序列中，筛选得到业务指标符合该第三目标条件的目标场景序列，输出该目标场景序列，筛选过程与上述步骤307类似，两者仅仅是筛选使用的样本集不同，上述步骤307使用的样本集是去重后的各个第二场景序列，这里使用的样本集是去重后且包含目标界面的第二场景序列，这里对筛选过程不做赘述。

进一步的，在图6的基础上，在用户完成对CSG算法的各项输入参数的配置操作之后，可点击执行按钮605，以触发服务器进行序列频繁模式的挖掘，生成实验生效链路图，其中，第三场景序列和目标场景序列是由测试时间段内账号的行为数据挖掘得到的，而指标的影响链路则是基于指标类型和指标间关联关系生成的。

基于上述可配置的输入参数，可知实验生效链路图涉及三类场景流转路径：常规路径(即第三场景序列)、直接影响路径(对应于直接影响产品)和间接影响路径(对应于间接影响产品)，其中直接影响路径和间接影响路径统称为目标场景序列。常规路径体现的是用户的日常使用习惯，而直接影响路径体现用户使用直接影响产品的主要方式，间接影响路径则体现用户使用间接影响产品的主要方式。

在本申请实施例涉及的基于场景序列挖掘CSG算法构造实验生效链路图的方式，具有广泛的适用性和可移植性，能够服务于各种类型的客户端上进行的AB测试，尤其是浏览器应用、短视频应用、社交应用等各类涉及feeds流的应用，且构造出的实验生效链路图能够进行前端可视化展示，具有直观的显示效果，能够辅助AB测试的实验策略决策，满足各种不同的自定义约束。

以下，将结合图7介绍目标测试从开启实验到完成分析这一整体流程。图7是本申请实施例提供的一种目标测试的原理性流程图，如图7所示，目标测试主要涉及如下几个阶段：用户配置阶段701、实验指标检验数据准备阶段702、实验指标假设检验阶段703、行为路径挖掘数据准备阶段704、CSG算法阶段705以及前端展示阶段706。

在用户配置阶段701中，主要对3个部分的内容进行配置：实验信息配置、实验观测指标(即业务指标集合)配置和CSG算法的输入参数配置。其中，实验信息配置和实验观测指标配置需要在目标测试创建之前完成，因此不需要额外开发，例如，实验信息配置中需要配置日期分区、实验层号、实验桶号、其他筛选条件等，例如，实验观测指标配置需要配置业务指标集合。而CSG算法的输入参数配置，输入参数中必选项是测试生效场景和目标数量K，非必选项包括直接影响产品和间接影响产品。最终CSG算法会输出常规路径(即第三场景序列)，如果用户配置了直接影响产品，那么CSG算法还会输出一条直接影响路径，如果用户配置了间接影响产品，那么CSG算法还会输出一条间接影响路径，可选地，在对CSG算法进行配置时，还可配置开启数据分析时所使用的的分析指标集合，以便于将业务指标集合和分析指标集合求交集以计算第一业务指标。

在实验指标检验数据准备阶段702中，服务器采集到的账号的行为数据(源数据)通常都是用户粒度的实验指标源表，服务器基于用户粒度的实验指标源表，构造出用户粒度的实验指标天级表(即以每天为单位对各个账号的实验指标源表进行整理)，接着，将实验匹配用户表与用户粒度的实验指标天级表进行关联，能够对指标进行用户粒度的去重聚合，得到实验期的实验用户指标大宽表(即对每个账号将多天的天级表聚合到一张大表上)，最终对各指标进行桶粒度聚合，即将属于同一实验桶的各个账号的指标大宽表进行集合，以实验桶为单位计算各指标的假设检验所需的统计量，得到桶粒度实验指标结果表。可选地，上述实验指标检验数据准备过程可通过SQL(Structured Query Language，结构化查询语言)语句调起Hive(数据仓库工具)计算来实现。

在实验指标假设检验阶段703中，服务器可基于指标类型映射表(用于表征指标类型与显著性检验的检验方式的映射关系)，对不同类型的指标采用对应的显著性检验方式，得到实验指标检验结果表。比如，COUNT类指标采用卡方检验、UV均值类指标采用t检验、PV均值类指标采用delta method t检验、SUM类指标采用UV均值类的检验结果、UV比例类指标采用比例检验等。可选地，上述实验指标假设检验过程通过生成Spark(一种计算引擎)任务来实现，并直接拉取上述实验指标检验结果表。

在行为路径挖掘数据准备阶段704中，服务器基于各个客户端在会话中上报的数据，以及场景映射关系表(即场景与界面的映射表)，对按照上报时间先后顺序的时长上报日志流水表进行场景映射，比如进行日志排序、会话切分、连续场景去重聚合等预处理操作，得到时长上报场景映射表，接着关联实验匹配用户表进行用户粒度聚合，得到实验匹配用户的用户粒度行为路径结果表(即每个账号的原始场景序列)。可选地，上述行为路径挖掘数据准备通过生成SQL语句调起Hive计算来实现，需要业务方梳理出时长上报场景与业务场景的映射表。

在CSG算法阶段705中，服务器主要执行上述实施例中涉及的CSG算法的程序代码，用户在配置好CSG算法的输入参数之后，能够对实验期用户粒度的行为路径按照测试生效场景作截断处理，生成每个账号的候选子序列(即第一场景序列)，并对候选子序列进行评分和排序，得到用户粒度最佳路径(即第二场景序列)。通过对用户粒度最佳路径(即第二场景序列)进行评分和排序，得到用户整体前K条最佳路径(即第三场景序列)。最后，拉取指标检验结果表，得到场景流转关系以及指标的显著性检验结果，两者作为最终的业务分析数据，输入到前端展示阶段706中，构建实验生效链路图。可选地，上述CSG算法通过调用CSG算法生成Spark任务来实现。

在前端展示阶段706中，服务器基于CSG算法的输出(顶点集合即场景集合、有向边集合即关系集合)，通过拉取预设的指标关系表，生成包含场景间的流转链路以及场景内指标的影响链路的实验生效链路图。该图实验生效链路作为实验发布模块的一部分，辅助实验决策。

在本申请实施例中，相较于传统的序列模式挖掘算法来说，CSG算法能够很好地结合实验信息和用户的业务理解，从测试生效场景出发，挖掘出若干条实验生效路径(即第三场景序列)，此外，根据挖掘得到的路径所包含的场景进行指标筛选，能够过滤掉很多不需要计算的指标，仅对第一业务指标进行显著性检验，能够帮助理清AB测试的整体生效流程。

此外，CSG算法还能够显著降低AB测试的一类错误率和二类错误率，同时提高AB测试的解释能力，且能够处理CACE(Complier Average Causal Effect，依从者平均因果作用)问题。以下，将对上述作用分别进行分析和介绍。

一、降低一类错误率

一类错误代表当指标实际不存在显著性差异时，通过显著性检验检测出显著性差异(即显著性检验结果呈现假阳性)。由于实验生效链路图实际是对业务指标集合和分析指标集合两者交集中与场景相关的第一业务指标进行了显著性检验，因此相当于帮助进行了指标筛选，减少实验对无关指标的观测，从而降低一类错误率。

假设用α表示显著性水平，即α表示当原假设为真时拒绝原假设的概率，换言之α表征了犯一类错误的概率，当实验观测指标数从n+k降低至n(n≥1，k＞0)时，实验整体的最大一类错误率(即至少犯一次一类错误的概率)能够得到有效降低，在指标筛选前后两者的最大一类错误率的数学表达分别如下：

1-(1-α)ⁿ≤1-(1-α)^n+k，k＞0，α∈(0，1)

在离线测试中，以针对浏览器应用上某个小视频的UI(User Interface，用户界面)改版的AB测试作为目标测试为例，该目标测试在实验平台上观测的信息流指标就达到232个(即测试时间段中需要观测的业务指标集合中包含232个指标)，在业务指标集合中包含许多与目标测试的实验策略无关的指标，使得实验整体一类错误率上升，影响业务决策。在应用本申请实施例的CSG算法后，假设识别出实验生效链路图即场景关系图G(V，E)，其中场景集合即顶点集合V＝{主feeds，小视频浮层，短视频浮层}，关系集合即有向边集合E＝{(主feeds，小视频浮层)，(主feeds，短视频浮层)}。

基于场景集合V所包含各个场景的分析指标集合与业务指标集合的交集作筛选，最终得到实验真正需要关注的指标数(即第一业务指标的指标数)仅为25个。相当于将数据分析时需要关注的指标数从232降低至25，过滤掉了很多与本次目标测试无关的指标。假设显著性水平α为0.05，则该实验整体的最大一类错误率从1-0.95²³²降低至1-0.95²⁵，降幅达27.74％。可见，基于CSG结果的场景集合对指标进行筛选，能够有效降低实验整体的一类错误率。

二、降低二类错误率

二类错误代表当指标实际存在显著性差异时，通过显著性检验未能检测出显著性差异(即显著性检验结果呈现假阴性)。假设用α表示犯一类错误的概率，β表示犯二类错误的概率，indexl表示指标ID，θ表示当前指标的指标均值，σ表示当前指标的指标标准差，MDE表示检测差异，n表示最小样本量，则上述参量之间满足如下关系：

其中，z代表标准正态分布，z_1-α/2表示标准正态分布z的(1-α/2)分位点，z_1-β表示标准正态分布z的(1-β)分位点，例如，z_0.95＝1.96表示在标准正态分布中随机选取一个数，这个数小于1.96的概率是95％。

由于经过CSG算法筛选后的第一业务指标往往与目标测试的实验策略的相关性更高，因此这些第一业务指标在数据分析中的灵敏度更强。指标灵敏度更高则体现在MDE更大，因此在相同样本量下得到的统计功效1-β更高，即犯二类错误的概率更小。

进一步的，由于观测的指标个数减少，指标集中最大的指标方差往往会减小。因此，当实验观测指标数从n+k降低至n时，最大的指标方差往往会降低，即存在如下关系式：

其中X_j表示第j个指标，var表示方差，var(X_j)表示第j个指标的方差。

综合所有指标，目标测试整体所需的最小样本量为：

max{n_index1，n_index2，n_index3，...}

因此，随着观测指标个数减少，指标集的最大方差下降，因此实验整体所需的最小样本量更小，即在相同样本量的条件下，犯二类错误的概率降低。

三、提高目标测试的解释能力

目前，实验效果评估仅仅是多个指标的简单罗列，缺乏对实验生效过程和指标关系的梳理。CSG算法能够将目标测试的实验策略对用户行为的影响路径，以场景关系图的方式进行可视化展示，进而帮助业务方更好地理解实验生效过程，使得实验决策更清晰。

示意性地，以浏览器应用中某个小视频的UI改版AB测试为例，CSG算法输出的场景关系图中，揭示了该AB测试使得小视频主feeds场景的点击率大幅下降，进而减少了用户在小视频浮层内的消费，从而导致后续小视频的分发减少，而间接影响使得短视频的分发增加，但由于短视频的点击率不变，最终大盘的总点击显著下降。基于此，可使得业务方明确后续的迭代方向，重新设计小视频UI，着重提升小视频主feeds点击率。

四、处理CACE问题

CACE也被称为局部平均处理作用(Local Average Treatment Effect，LATE)。表2示出了一种对参与目标测试的所有用户的人群分类情况，如表2所示：

表2

其中，W_i(0)代表用户i如果分在AB测试的对照组时最终接受处理与否，W_i(1)代表用户i如果分在AB测试的实验组时最终接受处理与否。

此时能够把人群(即全量的参与AB测试的账号)分为四类：Never-taker(即不管是否被分在实验组，始终不接受处理)，Defier(即被分在对照组则接受处理，被分在实验组则不接受处理)，Complier(即依从者，被分在对照组就不接受处理，被分在实验组就接受处理)，Always-taker(即不管是否被分在实验组，始终接受处理)。

依从者Complier代表用户接受处理与否与随机分组一致，从业务理解上讲，依从者更易管理和运营，因此CACE就是研究AB测试的实验策略对依从者的效应。

由于CSG算法会对用户对应账号在实验期内的行为数据进行挖掘，因此能够准确识别出用户是否进入过测试生效场景，以及该用户接触AB测试的实验策略后的操作路径。基于此，CSG算法能够帮助业务方识别出依从者，进而帮助解决CACE的相关问题。

图8是本申请实施例提供的一种数据处理装置的结构示意图，请参考图8，该装置包括：

第一获取模块801，用于获取目标测试关联的每个账号的多个第一场景序列，该第一场景序列用于表征该账号从客户端的第一界面跳转至的至少一个第二界面以及界面间的跳转顺序；

第一筛选模块802，用于从该多个第一场景序列中，筛选得到每个账号的第二场景序列，该第二场景序列的至少一个业务指标符合第一目标条件；

第二筛选模块803，用于从多个账号的该第二场景序列中，筛选得到至少一个第三场景序列，该第三场景序列的至少一个业务指标符合第二目标条件；

第二获取模块804，用于基于该至少一个第三场景序列，获取该目标测试的业务分析数据，该业务分析数据用于分析该目标测试对该客户端中以该第一界面为起点的场景跳转的业务影响。

本申请实施例提供的装置，通过对目标测试关联的每个账号，均获取以第一界面为起点的第一场景序列，从第一场景序列中对每个账号筛选得到业务指标符合条件的第二场景序列，再对所有账号的第二场景序列再次筛选得到业务指标符合条件的第三场景序列，利用最终的第三场景序列进行数据分析，来预测本次目标测试的业务分析数据，由于第一场景序列都是以第一界面为起点的，从而能够保证最终筛选出的第三场景序列也是以第一界面为起点，即在设定好目标测试对应的第一界面后，最终得到的业务分析数据不会偏离第一界面所在的测试生效场景，从而提高了获取到的业务分析数据的准确度。

在一种可能实施方式中，该第一获取模块801用于：

获取该账号在该目标测试的测试时间段中产生的行为数据，该行为数据用于表征该账号在该客户端所执行的界面跳转的触发行为；

基于该行为数据，获取该账号的原始场景序列，该原始场景序列用于表征基于该触发行为跳转至的各个界面以及界面间的跳转顺序；

基于该第一界面，对该原始场景序列进行划分，得到该账号的多个第一场景序列，其中，该第一场景序列的第一个元素为该第一界面。

在一种可能实施方式中，基于图8的装置组成，该第一筛选模块802包括：

第一获取单元，用于对任一账号的任一第一场景序列，基于该至少一个业务指标，获取该第一场景序列的第一评分参数，该第一评分参数用于表征该第一场景序列在该至少一个业务指标上的综合评分情况；

确定单元，用于将第一评分参数最高的第一场景序列确定为该账号的第二场景序列。

在一种可能实施方式中，该第一获取单元用于：

基于该至少一个业务指标，获取该第一场景序列的业务特征，该业务特征用于表征该第一场景序列在每个业务指标上评估得到的指标值；

基于第一权重向量，对该第一场景序列的业务特征进行加权，得到该第一评分参数，该第一权重向量用于表征每个业务指标所对应的第一权重。

在一种可能实施方式中，基于图8的装置组成，该第二筛选模块803包括：

去重单元，用于对多个账号的该第二场景序列进行去重，得到去重后的多个第二场景序列；

筛选单元，用于从该去重后的多个第二场景序列中，基于该至少一个业务指标，筛选得到该至少一个第三场景序列。

在一种可能实施方式中，基于图8的装置组成，该筛选单元包括：

获取子单元，用于对去重后的每个第二场景序列，基于该至少一个业务指标，获取该第二场景序列的第二评分参数，该第二评分参数用于表征该第二场景序列在该至少一个业务指标上的综合评分情况；

排序确定子单元，用于按照第二评分参数从大到小的顺序对去重后的各个第二场景序列进行排序，将在该排序中位于前目标数量的第二场景序列确定为该至少一个第三场景序列。

在一种可能实施方式中，该获取子单元用于：

基于该至少一个业务指标，获取该第二场景序列的业务特征，该业务特征用于表征该第二场景序列在每个业务指标上评估得到的指标值；

基于第二权重向量，对该第二场景序列的业务特征进行加权，得到该第二评分参数，该第二权重向量用于表征每个业务指标所对应的第二权重。

在一种可能实施方式中，该业务分析数据包括场景关系图，该场景关系图用于表征该客户端中在该目标测试的作用下所影响的场景跳转链路；

基于图8的装置组成，该第二获取模块804包括：

第二获取单元，用于基于该至少一个第三场景序列，获取场景集合和关系集合，该场景集合用于表征各个该第三场景序列中不同界面所形成的集合，该关系集合用于表征该场景集合中不同界面之间的跳转顺序；

构建单元，用于基于该场景集合和该关系集合，构建该场景关系图。

在一种可能实施方式中，该构建单元用于：

对该场景集合中每个界面，在该场景关系图中生成该界面对应的节点；

对该关系集合中任意两个界面间的跳转顺序，在该场景关系图中生成该两个界面所对应的两个节点之间的有向边。

在一种可能实施方式中，该业务分析数据还包括该场景关系图中每个节点在业务指标上的显著性检验结果；

基于图8的装置组成，该装置还包括：

确定模块，用于基于该映射关系，从该业务指标集合中，确定与该场景集合中每个界面关联的第一业务指标；

检验模块，用于对该场景关系图中的每个节点，对该节点所对应界面关联的第一业务指标的指标值进行显著性检验，得到该节点的显著性检验结果。

在一种可能实施方式中，该确定模块用于：

获取输入的对该场景关系图的分析指标集合；

获取该分析指标集合与该业务指标集合的交集；

对该场景集合中的每个界面，基于该映射关系，从该交集中查询得到该界面对应的第一业务指标。

在一种可能实施方式中，基于图8的装置组成，该装置还包括：

第四获取模块，用于获取输入的目标界面；

输出模块，用于在该至少一个第三场景序列中任一第三场景序列包含该目标界面的情况下，输出包含该目标界面的第三场景序列为目标场景序列；

该输出模块，还用于在该至少一个第三场景序列均不包含该目标界面的情况下，输出从多个账号的第二场景序列中筛选得到的目标场景序列，该目标场景序列包含该目标界面，且该目标场景序列的至少一个业务指标符合第三目标条件。

在一种可能实施方式中，该输出模块还用于：

对多个账号的该第二场景序列进行去重，得到去重后的多个第二场景序列；

从该去重后的多个第二场景序列中，筛选得到包含该目标界面的各个第二场景序列；

从包含该目标界面的各个第二场景序列中，筛选得到业务指标符合该第三目标条件的目标场景序列，输出该目标场景序列。

需要说明的是：上述实施例提供的数据处理装置在处理数据时，仅以上述各功能模块的划分进行举例说明，实际应用中，能够根据需要而将上述功能分配由不同的功能模块完成，即将计算机设备的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的数据处理装置与数据处理方法实施例属于同一构思，其具体实现过程详见数据处理方法实施例，这里不再赘述。

图9是本申请实施例提供的一种计算机设备的结构示意图。可选地，该终端900的设备类型包括：智能手机、平板电脑、MP3播放器(Moving Picture Experts Group AudioLayer III，动态影像专家压缩标准音频层面3)、MP4(Moving Picture Experts GroupAudio Layer IV，动态影像专家压缩标准音频层面4)播放器、笔记本电脑或台式电脑。终端900还可能被称为用户设备、便携式终端、膝上型终端、台式终端等其他名称。

通常，终端900包括有：处理器901和存储器902。

可选地，处理器901包括一个或多个处理核心，比如4核心处理器、8核心处理器等。可选地，处理器901采用DSP(Digital Signal Processing，数字信号处理)、FPGA(Field－Programmable Gate Array，现场可编程门阵列)、PLA(Programmable Logic Array，可编程逻辑阵列)中的至少一种硬件形式来实现。在一些实施例中，处理器901包括主处理器和协处理器，主处理器是用于对在唤醒状态下的数据进行处理的处理器，也称CPU(CentralProcessing Unit，中央处理器)；协处理器是用于对在待机状态下的数据进行处理的低功耗处理器。在一些实施例中，处理器901集成有GPU(Graphics Processing Unit，图像处理器)，GPU用于负责显示屏所需要显示的内容的渲染和绘制。一些实施例中，处理器901还包括AI(Artificial Intelligence，人工智能)处理器，该AI处理器用于处理有关机器学习的计算操作。

在一些实施例中，存储器902包括一个或多个计算机可读存储介质，可选地，该计算机可读存储介质是非暂态的。可选地，存储器902还包括高速随机存取存储器，以及非易失性存储器，比如一个或多个磁盘存储设备、闪存存储设备。在一些实施例中，存储器902中的非暂态的计算机可读存储介质用于存储至少一个程序代码，该至少一个程序代码用于被处理器901所执行以实现本申请中各个实施例提供的数据处理方法。

在一些实施例中，终端900还可选包括有：外围设备接口903和至少一个外围设备。处理器901、存储器902和外围设备接口903之间能够通过总线或信号线相连。各个外围设备能够通过总线、信号线或电路板与外围设备接口903相连。具体地，外围设备包括：射频电路904、显示屏905、摄像头组件906、音频电路907和电源908中的至少一种。

外围设备接口903可被用于将I/O(Input/Output，输入/输出)相关的至少一个外围设备连接到处理器901和存储器902。在一些实施例中，处理器901、存储器902和外围设备接口903被集成在同一芯片或电路板上；在一些其他实施例中，处理器901、存储器902和外围设备接口903中的任意一个或两个在单独的芯片或电路板上实现，本实施例对此不加以限定。

射频电路904用于接收和发射RF(Radio Frequency，射频)信号，也称电磁信号。射频电路904通过电磁信号与通信网络以及其他通信设备进行通信。射频电路904将电信号转换为电磁信号进行发送，或者，将接收到的电磁信号转换为电信号。可选地，射频电路904包括：天线系统、RF收发器、一个或多个放大器、调谐器、振荡器、数字信号处理器、编解码芯片组、用户身份模块卡等等。可选地，射频电路904通过至少一种无线通信协议来与其它终端进行通信。该无线通信协议包括但不限于：城域网、各代移动通信网络(2G、3G、4G及5G)、无线局域网和/或WiFi(Wireless Fidelity，无线保真)网络。在一些实施例中，射频电路904还包括NFC(Near Field Communication，近距离无线通信)有关的电路，本申请对此不加以限定。

显示屏905用于显示UI(User Interface，用户界面)。可选地，该UI包括图形、文本、图标、视频及其它们的任意组合。当显示屏905是触摸显示屏时，显示屏905还具有采集在显示屏905的表面或表面上方的触摸信号的能力。该触摸信号能够作为控制信号输入至处理器901进行处理。可选地，显示屏905还用于提供虚拟按钮和/或虚拟键盘，也称软按钮和/或软键盘。在一些实施例中，显示屏905为一个，设置终端900的前面板；在另一些实施例中，显示屏905为至少两个，分别设置在终端900的不同表面或呈折叠设计；在再一些实施例中，显示屏905是柔性显示屏，设置在终端900的弯曲表面上或折叠面上。甚至，可选地，显示屏905设置成非矩形的不规则图形，也即异形屏。可选地，显示屏905采用LCD(LiquidCrystal Display，液晶显示屏)、OLED(Organic Light-Emitting Diode，有机发光二极管)等材质制备。

摄像头组件906用于采集图像或视频。可选地，摄像头组件906包括前置摄像头和后置摄像头。通常，前置摄像头设置在终端的前面板，后置摄像头设置在终端的背面。在一些实施例中，后置摄像头为至少两个，分别为主摄像头、景深摄像头、广角摄像头、长焦摄像头中的任意一种，以实现主摄像头和景深摄像头融合实现背景虚化功能、主摄像头和广角摄像头融合实现全景拍摄以及VR(Virtual Reality，虚拟现实)拍摄功能或者其它融合拍摄功能。在一些实施例中，摄像头组件906还包括闪光灯。可选地，闪光灯是单色温闪光灯，或者是双色温闪光灯。双色温闪光灯是指暖光闪光灯和冷光闪光灯的组合，用于不同色温下的光线补偿。

在一些实施例中，音频电路907包括麦克风和扬声器。麦克风用于采集用户及环境的声波，并将声波转换为电信号输入至处理器901进行处理，或者输入至射频电路904以实现语音通信。出于立体声采集或降噪的目的，麦克风为多个，分别设置在终端900的不同部位。可选地，麦克风是阵列麦克风或全向采集型麦克风。扬声器则用于将来自处理器901或射频电路904的电信号转换为声波。可选地，扬声器是传统的薄膜扬声器，或者是压电陶瓷扬声器。当扬声器是压电陶瓷扬声器时，不仅能够将电信号转换为人类可听见的声波，也能够将电信号转换为人类听不见的声波以进行测距等用途。在一些实施例中，音频电路907还包括耳机插孔。

电源908用于为终端900中的各个组件进行供电。可选地，电源908是交流电、直流电、一次性电池或可充电电池。当电源908包括可充电电池时，该可充电电池支持有线充电或无线充电。该可充电电池还用于支持快充技术。

在一些实施例中，终端900还包括有一个或多个传感器910。该一个或多个传感器910包括但不限于：加速度传感器911、陀螺仪传感器912、压力传感器913、光学传感器914以及接近传感器915。

在一些实施例中，加速度传感器911检测以终端900建立的坐标系的三个坐标轴上的加速度大小。比如，加速度传感器911用于检测重力加速度在三个坐标轴上的分量。可选地，处理器901根据加速度传感器911采集的重力加速度信号，控制显示屏905以横向视图或纵向视图进行用户界面的显示。加速度传感器911还用于游戏或者用户的运动数据的采集。

在一些实施例中，陀螺仪传感器912检测终端900的机体方向及转动角度，陀螺仪传感器912与加速度传感器911协同采集用户对终端900的3D动作。处理器901根据陀螺仪传感器912采集的数据，实现如下功能：动作感应(比如根据用户的倾斜操作来改变UI)、拍摄时的图像稳定、游戏控制以及惯性导航。

可选地，压力传感器913设置在终端900的侧边框和/或显示屏905的下层。当压力传感器913设置在终端900的侧边框时，能够检测用户对终端900的握持信号，由处理器901根据压力传感器913采集的握持信号进行左右手识别或快捷操作。当压力传感器913设置在显示屏905的下层时，由处理器901根据用户对显示屏905的压力操作，实现对UI界面上的可操作性控件进行控制。可操作性控件包括按钮控件、滚动条控件、图标控件、菜单控件中的至少一种。

光学传感器914用于采集环境光强度。在一个实施例中，处理器901根据光学传感器914采集的环境光强度，控制显示屏905的显示亮度。具体地，当环境光强度较高时，调高显示屏905的显示亮度；当环境光强度较低时，调低显示屏905的显示亮度。在另一个实施例中，处理器901还根据光学传感器914采集的环境光强度，动态调整摄像头组件906的拍摄参数。

接近传感器915，也称距离传感器，通常设置在终端900的前面板。接近传感器915用于采集用户与终端900的正面之间的距离。在一个实施例中，当接近传感器915检测到用户与终端900的正面之间的距离逐渐变小时，由处理器901控制显示屏905从亮屏状态切换为息屏状态；当接近传感器915检测到用户与终端900的正面之间的距离逐渐变大时，由处理器901控制显示屏905从息屏状态切换为亮屏状态。

本领域技术人员能够理解，图9中示出的结构并不构成对终端900的限定，能够包括比图示更多或更少的组件，或者组合某些组件，或者采用不同的组件布置。

图10是本申请实施例提供的一种计算机设备的结构示意图，该计算机设备1000可因配置或性能不同而产生比较大的差异，该计算机设备1000包括一个或一个以上处理器(Central Processing Units，CPU)1001和一个或一个以上的存储器1002，其中，该存储器1002中存储有至少一条计算机程序，该至少一条计算机程序由该一个或一个以上处理器1001加载并执行以实现上述各个实施例提供的数据处理方法。可选地，该计算机设备1000还具有有线或无线网络接口、键盘以及输入输出接口等部件，以便进行输入输出，该计算机设备1000还包括其他用于实现设备功能的部件，在此不做赘述。

在示例性实施例中，还提供了一种计算机可读存储介质，例如包括至少一条计算机程序的存储器，上述至少一条计算机程序可由终端中的处理器执行以完成上述各个实施例中的数据处理方法。例如，该计算机可读存储介质包括ROM(Read-Only Memory，只读存储器)、RAM(Random-Access Memory，随机存取存储器)、CD-ROM(Compact Disc Read-OnlyMemory，只读光盘)、磁带、软盘和光数据存储设备等。

在示例性实施例中，还提供了一种计算机程序产品或计算机程序，包括一条或多条程序代码，该一条或多条程序代码存储在计算机可读存储介质中。计算机设备的一个或多个处理器能够从计算机可读存储介质中读取该一条或多条程序代码，该一个或多个处理器执行该一条或多条程序代码，使得计算机设备能够执行以完成上述实施例中的数据处理方法。

本领域普通技术人员能够理解实现上述实施例的全部或部分步骤能够通过硬件来完成，也能够通过程序来指令相关的硬件完成，可选地，该程序存储于一种计算机可读存储介质中，可选地，上述提到的存储介质是只读存储器、磁盘或光盘等。

以上所述仅为本申请的可选实施例，并不用以限制本申请，凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims

1.一种数据处理方法，其特征在于，所述方法包括：

2.根据权利要求1所述的方法，其特征在于，所述获取目标测试关联的每个账号的多个第一场景序列包括：

3.根据权利要求1所述的方法，其特征在于，所述从所述多个第一场景序列中，筛选得到每个账号的第二场景序列包括：

对任一账号的任一第一场景序列，基于所述至少一个业务指标，获取所述第一场景序列的第一评分参数，所述第一评分参数用于表征所述第一场景序列在所述至少一个业务指标上的综合评分情况；

将第一评分参数最高的第一场景序列确定为所述账号的第二场景序列。

4.根据权利要求3所述的方法，其特征在于，所述基于所述至少一个业务指标，获取所述第一场景序列的第一评分参数包括：

5.根据权利要求1所述的方法，其特征在于，所述从多个账号的所述第二场景序列中，筛选得到至少一个第三场景序列包括：

从所述去重后的多个第二场景序列中，基于所述至少一个业务指标，筛选得到所述至少一个第三场景序列。

6.根据权利要求5所述的方法，其特征在于，所述从所述去重后的多个第二场景序列中，基于所述至少一个业务指标，筛选得到所述至少一个第三场景序列包括：

对去重后的每个第二场景序列，基于所述至少一个业务指标，获取所述第二场景序列的第二评分参数，所述第二评分参数用于表征所述第二场景序列在所述至少一个业务指标上的综合评分情况；

按照第二评分参数从大到小的顺序对去重后的各个第二场景序列进行排序，将在所述排序中位于前目标数量的第二场景序列确定为所述至少一个第三场景序列。

7.根据权利要求6所述的方法，其特征在于，所述基于所述至少一个业务指标，获取所述第二场景序列的第二评分参数包括：

8.根据权利要求1所述的方法，其特征在于，所述业务分析数据包括场景关系图，所述场景关系图用于表征所述客户端中在所述目标测试的作用下所影响的场景跳转链路；

所述基于所述至少一个第三场景序列，获取所述目标测试的业务分析数据包括：

基于所述至少一个第三场景序列，获取场景集合和关系集合，所述场景集合用于表征各个所述第三场景序列中不同界面所形成的集合，所述关系集合用于表征所述场景集合中不同界面之间的跳转顺序；

基于所述场景集合和所述关系集合，构建所述场景关系图。

9.根据权利要求8所述的方法，其特征在于，所述基于所述场景集合和所述关系集合，构建所述场景关系图包括：

10.根据权利要求8或9所述的方法，其特征在于，所述业务分析数据还包括所述场景关系图中每个节点在业务指标上的显著性检验结果；

在构建所述场景关系图之后，所述方法还包括：

获取预先配置的业务指标集合和业务指标与界面的映射关系；

基于所述映射关系，从所述业务指标集合中，确定与所述场景集合中每个界面关联的第一业务指标；

对所述场景关系图中的每个节点，对所述节点所对应界面关联的第一业务指标的指标值进行显著性检验，得到所述节点的显著性检验结果。

11.根据权利要求10所述的方法，其特征在于，所述基于所述映射关系，从所述业务指标集合中，确定与所述场景集合中每个界面关联的第一业务指标包括：

获取输入的对所述场景关系图的分析指标集合；

获取所述分析指标集合与所述业务指标集合的交集；

12.根据权利要求1所述的方法，其特征在于，所述方法还包括：

获取输入的目标界面；

在所述至少一个第三场景序列中任一第三场景序列包含所述目标界面的情况下，输出包含所述目标界面的第三场景序列为目标场景序列；

在所述至少一个第三场景序列均不包含所述目标界面的情况下，输出从多个账号的第二场景序列中筛选得到的目标场景序列，所述目标场景序列包含所述目标界面，且所述目标场景序列的至少一个业务指标符合第三目标条件。

13.根据权利要求12所述的方法，其特征在于，所述输出从多个账号的第二场景序列中筛选得到的目标场景序列包括：

14.一种数据处理装置，其特征在于，所述装置包括：

15.一种计算机设备，其特征在于，所述计算机设备包括一个或多个处理器和一个或多个存储器，所述一个或多个存储器中存储有至少一条计算机程序，所述至少一条计算机程序由所述一个或多个处理器加载并执行以实现如权利要求1至权利要求13任一项所述的数据处理方法。

16.一种存储介质，其特征在于，所述存储介质中存储有至少一条计算机程序，所述至少一条计算机程序由处理器加载并执行以实现如权利要求1至权利要求13任一项所述的数据处理方法。

17.一种计算机程序产品，其特征在于，所述计算机程序产品包括至少一条计算机程序，所述至少一条计算机程序由处理器加载并执行以实现如权利要求1至权利要求13任一项所述的数据处理方法。