CN112328485A - 用户行为的分流测试方法与系统 - Google Patents

Abstract

本申请涉及一种用户行为的分流测试方法与系统，通过将用户端数据和不同层的唯一标识key进行打散，这样命中一个实验层分流的用户，到另一个实验层之后完全被打散，这样就能实现流量正交分流的的效果，当不同用户行为之间的测试在不同实验层同时进行时，测试结果不会互相影响。此外，流量的正交、分流还可以实现数据监控和数据回收的自动完成，避免劳动力浪费。

Description

用户行为的分流测试方法与系统

技术领域

本申请涉及广告测试技术领域，特别是涉及一种用户行为的分流测试方法与系统。

背景技术

移动互联网广告行业，在广告投放之前，针对流量和广告的投放会进行大量的AB测试，以达到效果最优的投放策略，完成链路效能的优化和算法的结构升级。从流量侧开始到广告结果投放，涉及链路上的用户行为1,2,3等多个用户行为，针对单独的行为会进行大量的测试，且针对单个用户行为的多个不同步骤也要进行测试。然而，并非所有的流量都能用于测试，单独划分流量给某个行为进行测试，会导致测试流量匮乏或者测试量级不达标，无法形成置信的测试结果。

传统的针对用户行为的分流测试方法，针对于每个用户行为的每一个步骤都开发一套AB分流测试代码，这样很浪费开发资源。更为严重的是，不同行为之间的测试在同时进行时，测试结果会互相影响，导致测试结果不准确。

发明内容

基于此，有必要针对传统用户行为的测试方法的测试结果会互相影响，导致测试结果不准确的问题，提供一种用户行为的分流测试方法。

本申请提供一种用户行为的分流测试方法，包括：

管理端创建多个实验层，为每一个实验层配置一个唯一标识key；

管理端依据预设测试配置，为每一个实验层配置至少一个value值；每一个value值与一个测试方案对应；

当用户端的应用程序中的广告位被触发时，应用程序通过用户端获取用户端数据，生成用户行为订单，并将用户端数据和用户行为订单发送至引擎服务器；

引擎服务器依据所述用户行为订单确定用户行为的唯一标识orderID，并判断是否存在触发已配置唯一标识key的实验层的用户行为；

若存在触发已配置唯一标识key的实验层的用户行为，则引擎服务器基于所述用户端数据和唯一标识key对所述用户行为进行分流判定，判断所述用户行为是否命中某一测试方案；

若所述用户行为命中某一测试方案，则引擎服务器调取该用户行为命中的测试方案，并依据该测试方案进行测试。

本申请还提供一种用户行为的分流测试系统，其应用前述内容提及的用户行为的分流测试方法。所述用户行为的分流测试系统包括：

管理端，包括Hbase数据库；

引擎服务器，与所述管理端通信连接；

用户端，与所述引擎服务器通信连接。

本申请涉及一种用户行为的分流测试方法与系统，通过将用户端数据和不同层的唯一标识key进行打散，这样命中一个实验层分流的用户，到另一个实验层之后完全被打散，这样就能实现流量正交分流的的效果，当不同用户行为之间的测试在不同实验层同时进行时，测试结果不会互相影响。此外，流量的正交、分流还可以实现数据监控和数据回收的自动完成，避免劳动力浪费。

附图说明

图1为本申请一实施例提供的用户行为的分流测试方法的流程示意图；

图2为本申请一实施例提供的用户行为的分流测试系统的结构示意图；

图3为本申请另一实施例提供的用户行为的分流测试系统的结构示意图。

附图标记：

10-管理端；110-层创建模块；120-第一配置模块；130-第二配置模块；140-Hbase数据库；20-引擎服务器；210-分流判定模块；220-测试模块；30-用户端

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。

本申请提供一种用户行为的分流测试方法。需要说明的是，本申请提供的用户行为的分流测试方法的应用于在广告投放之前的针对于任何用户行为的AB测试。

此外，本申请提供的用户行为的分流测试方法不限制其执行主体。可选地，本申请提供的用户行为的分流测试方法的执行主体的可以为一种用户行为的分流测试系统。

如图1所示，在本申请的一实施例中，所述用户行为的分流测试方法包括如下步骤S100至步骤S700：

S100，管理端创建多个实验层，为每一个实验层配置一个唯一标识key。

具体地，用户行为是链路化的，例如用户行为1，用户行为2，用户行为3等等。为了区别不同用户行为之间的测试，本步骤创建了多个实验层，并为每一个实验层配置一个唯一标识key。每一个实验层代表一个用户行为，与一个用户行为绑定。

唯一标识key可以为一串字符，例如，algo.sck.slot.list。可以理解，这个过程相当于在测试流程中进行了打槽位操作，每一个唯一标识key被认定为一个槽位。

S200，管理端依据预设测试配置，为每一个实验层配置至少一个value值。每一个value值与一个测试方案对应。

具体地，每一个用户行为可以在不同的广告位上测试，且可以分配不同的流量进行测试，因此，测试方式有很多种。为了区别不同的测试方式，在每一个实验层配置至少一个value值，每一个value值代表一个测试方案。

每一个测试方案的具体测试内容和测试流程由测试人员预设。

S400，当用户端的应用程序中的广告位被触发时，应用程序通过用户端获取用户端数据，生成用户行为订单。进一步的，应用程序将用户端数据和用户行为订单发送至引擎服务器。

具体地，当用户浏览用户端的应用程序，并触发广告位时，此时应用程序通过用户端获取用户端数据，并同步生成用户行为订单。用户行为订单可以记录用户的一系列的用户行为，例如，从点击广告素材，到跳转到广告落地页，再到跳转到下单页面进行下单，以及跳转到支付页面支付等等，都可以通过用户行为订单进行记录。

S500，引擎服务器依据所述用户行为订单确定用户行为的唯一标识orderID。进一步地，引擎服务器判断是否存在触发已配置唯一标识key的实验层的用户行为。

具体地，每一个用户行为订单均具有一个与其对应的唯一标识orderID。通过orderID和用户行为订单的对应关系，在后续需要调取用户行为订单时，可以直接通过orderID调取。

S600，若存在触发已配置唯一标识key的实验层的用户行为，则引擎服务器基于所述用户端数据和唯一标识key对所述用户行为进行分流判定，判断所述用户行为是否命中某一测试方案。

具体地，步骤S100至步骤S200，管理端已经预先配置了槽位，每个槽位设置了唯一标识key，且设置了多个value值对应不同的测试方案。因此，当用户触发广告位时，自然会产生一系列的用户行为，那么自然会触发设置了已配置唯一标识key的实验层。需要说明的是，没有设置唯一标识key的实验层不会被触发，也不会进行分流判定以及后续的分流测试。

因此，进一步地，本步骤可以通过用户端数据和唯一标识key对用户行为订单进行分流判定，判断用户行为订单是否命中某一测试方案。

S700，若所述用户行为命中某一测试方案，则引擎服务器调取该用户行为命中的测试方案，并依据该测试方案进行测试。

具体地，若用户行为订单命中某一测试方案，则直接调取该测试方案进行测试。例如命中了素材投放这个用户行为的测试方案1，测试方案1的内容是10％流量用于测试投放小兔子素材的投放效果，10％流量用于测试投放小狗素材的投放效果，观察测试效果，那么就执行这套测试方案。

本实施例中，通过将用户端数据和不同层的唯一标识key进行打散，这样命中一个实验层分流的用户，到另一个实验层之后完全被打散，这样就能实现流量正交分流的的效果，当不同用户行为之间的测试在不同实验层同时进行时，测试结果不会互相影响。此外，流量的正交、分流还可以实现数据监控和数据回收的自动完成，避免劳动力浪费。

在本申请的一实施例中，所述value值为一个字符串，所述value值包括广告位信息、测试流量百分比K、测试流量百分比的流量分配份额数n和测试时间t中的一种或多种测试信息。管理端在为每一个实验层配置至少一个value值时，在同一个实验层下，一个广告位只配置唯一一个value值。

具体地，value值可以包括广告位信息、测试流量百分比K、测试流量百分比的流量分配份额数n和测试时间t。例如，value值为7001,20,1,10。那么可以获知，测试的广告位为7001广告位。测试流量百分比为20％，测试流量百分比的流量分配份额数n为1。测试时间t为10分钟。value值本身并不展示测试的具体内容，只展示测试的这些关键的测试信息。

配置后的value值存放于管理端的Hbase数据库中，每一个value值和一个测试方案进行关联。在后续引擎服务器调取value值时，可以同步调取与value值相关的测试方案进行测试。

承接上面的实例，value值为7001,20,1,10，测试内容是测试投放脑白金广告的效果，那么通过value值可以知晓这个测试方案为在7001广告位投放脑白金广告，且分配总测试流量的20％用户测试，测试时间为10分钟。

为了控制变量，以便不同的测试方案进行测试结果比对，管理端在为每一个实验层配置至少一个value值时，在同一个实验层下，一个广告位只配置唯一一个value值。例如在素材投放这个实验层，针对7001广告位只会配置唯一一个value值。当然，在其他实验层，比如广告投放的实验层，可以针对7001广告位再配置一个value值，形成实验层之间的测试效果对比。在同一实验层，不同广告位的测试效果也会产生对比，比如7001广告位和70002广告位的测试，控制其他测试数据一致，仅广告位不同。

本实施例中，通过设置value值包含一种或多种测试信息，使得同一行为在不同广告位上的不同测试方案可以用唯一的一个关键字符串进行区分，便于测试流量分配的正交分流，测试方案彼此之间可以做出区别，不会产生冲突。

在本申请的一实施例中，在所述步骤S200之后，所述用户行为的分流测试方法还包括如下步骤S310至步骤S350：

S310，管理端选取一个测试方案，获取该测试方案对应的value值。

具体地，本实施例中涉及的所有步骤S310至步骤S350的意义在于，将测试方案和具体的流量百分比范围形成对应关系。首先，选取一个测试方案，获取该测试方案对应的value值。

S320，管理端读取value值中的测试流量百分比K，以及测试流量百分比的流量分配份额数n。n为正整数。

具体地，本步骤中的测试流量百分比K，以及测试流量百分比的流量分配份额数n已经在前述的步骤S300中预先配置过，此处不再赘述。

S330，管理端依据测试流量百分比的流量分配份额数n，将测试流量百分比K平均分配为至少一个流量百分比范围，分别

具体地，然而，一个测试方案可以有多个测试分支选项，当流量分配份额数n大于1时，表明这个测试方案有多个测试分支选项。下面举两个例子。

例子1，value值为7001,20,1,10，具体是测试在7001广告位投放茉莉绿茶广告，由于K等于20％，n等于1，那么分配总测试流量的20％测试即可，这20％流量无须拆分，测试时间为10分钟。那么在7001广告位投放茉莉绿茶广告的测试方案对应的流量百分比范围就是0-20％。

例子2，value值为7001,20,2,10，表明也是测试在7001广告位投放广告，由于K等于20％，n等于2，那么分配总测试流量的20％需要平均拆分为两份，每一份10％，测试时间为10分钟。那么测试方案就变成了包括两个测试子方案：在7001广告位投放茉莉绿茶广告，分配总测试流量的10％测试，测试时间为10分钟，对应的流量百分比范围为0-10％。在7001广告位投放冰红茶广告，分配总测试流量的10％测试，，测试时间为10分钟，对应的流量百分比范围为10-20％。

例子3，value值为7001,30,3,10，由于K等于30％，n等于3，那么分配总测试流量的30％需要平均拆分为三份，每一份10％，测试时间为10分钟。测试方案就变成了包括三个测试分支选项：在7001广告位投放茉莉绿茶广告，分配总测试流量的10％测试，测试时间为10分钟，对应的流量百分比范围为0-10％。在7001广告位投放冰红茶广告，分配总测试流量的10％测试，，测试时间为10分钟，对应的流量百分比范围为10-20％。在7001广告位投放酸梅汤广告，分配总测试流量的10％测试，，测试时间为10分钟，对应的流量百分比范围为20-30％。

S340，管理端将该测试方案、该测试方案对应的value值和上述步骤计算得到的至少一个流量百分比范围相对应的存储。每一个流量百分比代表该测试方案下的一个测试分支选项。

具体地，本步骤的目的是防止测试子方案彼此之间产生混淆，所以将value值，至少一个流量百分比范围相对应的存储。例如，value值为7001,30,3,10，那么要将0-10％,流量百分比范围及其对应的测试分支选项，10-20％流量百分比范围及其对应的测试分支选项，20-30％流量百分比范围及其对应的测试分支选项，三个部分进行关联，与value值7001,30,3,10再进行关联存储。

S350，反复执行所述步骤S310至步骤S340，直至所有测试方案均进行了流量百分比范围的划分。

本实施例实现了不但可以将不同的测试方案与具体的流量百分比范围形成对应关系，还可以将不同的测试分支选项与具体的流量百分比范围形成对应关系，避免不同测试方案之间混淆，以及相同测试方案之间的不同测试分支选项之间的流量分配原则混淆。

在本申请的一实施例中，所述步骤S600包括如下步骤S610至步骤S660：

S610，引擎服务器进一步判断触发已配置唯一标识key的实验层的用户行为的数量是否为1。

具体地，配置过唯一标识key的实验层的数量是不确定的，有可能只有1个，也可能是多个，因此本步骤需要对触发已配置唯一标识key的实验层的用户行为的数量进行判定。

S620，若触发已配置唯一标识key的实验层的用户行为的数量为1，则引擎服务器调取该用户行为触发的实验层对应的唯一标识key，并从用户端数据中提取用户端设备号deviceID。

具体地，用户端数据包括用户端设备号deviceID。若触发已配置唯一标识key的实验层的用户行为的数量为1，则表明触发已配置唯一标识key的实验层的用户行为的数量不同的用户行为是唯一的。因此，通过用户行为触发的实验层，直接调取实验层中的唯一标识key。本步骤还需要从用户端数据中提取用户端设备号deviceID。

S630，引擎服务器对唯一标识key和用户端设备号deviceID进行hash处理，得到hash值。

具体地，引擎服务器对唯一标识key、用户设备号deviceID进行杂糅，输出另一段固定长度的数据，即hash值。

S640，引擎服务器将所述hash值对100进行取余运算，得到余数。

可选地，hash值可以为一个数字，对这个数字对100进行取余运算，得到余数。例如，hash值为120，那么最终计算得到的余数就为20。

S650，引擎服务器分析所述余数落入流量百分比范围的情况，判断所述用户行为是否命中某一测试方案。

具体地，前述内容步骤S310至步骤S350已经建立了流量百分比范围及其对应的测试分支选项的关系。余数代表了流量百分比具体值。因此，可以依据判断余数是否落在某一个流量百分比范围，从而判断用户行为订单是否命中某一测试分支选项，进而判断用户行为订单是否命中某一测试方案，这是因为一个测试分支选项必然归属于一个测试方案。

S660，若触发已配置唯一标识key的实验层的用户行为的数量不为1，则对每一个触发已配置唯一标识key的实验层的用户行为依次执行步骤S620至步骤S650。

具体地，若触发已配置唯一标识key的实验层的用户行为的数量不为1，表明触发了实验册的用户行为为多个。那么需要对每一个用户行为均执行一次步骤S620至步骤S650。

本实施例中，通过用户Hash划分实验域，基于唯一标识key和用户设备号划分实验层，实现正交分流，不同层的用户全部重新打散，通过打槽位的方式完成业务系统的耦合，自动实现数据监控，数据回收。

在本申请的一实施例中，所述步骤S650包括如下步骤S651至步骤S652：

S651，引擎服务器依据被触发广告位，遍历管理端，从管理端中调取该用户行为触发的实验层下，与被触发广告位相关的所有value值，以及所述value值对应的所有流量百分比范围，判断所述余数是否归属于其中某一个流量百分比范围。

S652，若余数归属于其中某一个流量百分比范围，则确定该用户行为命中某一测试方案。

具体地，举例说明，若触发的广告位为7001，计算出的余数为26，由于之前管理端配置的一个测试方案的value值为7001,30,3,10，其中的一个测试分支选项为，在7001广告位投放酸梅汤广告，分配总测试流量的10％测试，测试时间为10分钟，对应的流量百分比范围为20-30％。

那么，余数26命中了流量百分比范围20-30％，则可以认为命中了“在7001广告位投放酸梅汤广告，分配总测试流量的10％测试，测试时间为10分钟”这个测试分支选项。“在7001广告位投放酸梅汤广告，分配总测试流量的10％测试，测试时间为10分钟”这个测试分支选项归属于“7001,30,3,10”这个测试方案，因此最终引擎服务器调取value值为7001,30,3,10对应的测试方案进行测试。

本实施例中，通过将余数和预先配置的流量百分比范围进行归属判定，实现了命中分流的准确判断，算法简单且判断时间短。

在本申请的一实施例中，所述步骤S700包括如下步骤S710至步骤S720：

S710，引擎服务器提取余数归属的流量百分比范围，从管理端中调取与该流量百分比范围对应的测试分支选项。

S720，引擎服务器采用该测试分支选项进行测试。

具体地，承接上述实施例，引擎服务器不但要调取value值为7001,30,3,10对应的测试方案进行测试，还有按照测试分支选项的配置进行测试，即按照“在7001广告位投放酸梅汤广告，分配总测试流量的10％测试，测试时间为10分钟”这个测试分支选项进行测试。本实施例既可以确认具体的测试方案，还可以确定具体的测试分支选项，

本实施例中，通过这种测试方法，在同一用户行为(即同一实验层)的角度来看，不但可以比对在不同广告位采用相同测试方案的测试效果，而且可以比对在同一广告位采用不同测试方案的测试效果，可以同时针对多个value值的测试方案同步测试，彼此之间测试不会影响。

在不同用户行为(即不同实验层之间)的角度来看，可以比对在相同广告位测试不同用户行为的测试效果，可以同时针对多个层的测试方案同步测试，彼此之间测试结果不会产生冲突，测试之间互相不会影响。

在本申请的一实施例中，在步骤S630之前，所述步骤S600还包括如下步骤S621至步骤S624：

S621，引擎服务器从用户端数据中提取用户信息，并从管理端调取预设用户配置。

具体地，在引擎服务器对唯一标识key和用户端设备号deviceID进行hash处理前，本实施例还分析用户群体范围是否与预设流量配置符合。

S622，引擎服务器将预设用户配置与用户信息进行匹配。进一步地，引擎服务器依据匹配结果判断当前用户是否落在预设用户配置限定的用户群体范围内。

具体地，预设用户配置限定了用户群体范围。预设用户配置代表了广告主的需求或其他硬性规定或特殊限制。

S623，若当前用户落在预设用户配置限定的用户群体范围内，则执行后续步骤S630。

具体地，例如预设用户配置限定了北京用户这个用户群体范围内，若依据用户信息确定当前用户为北京用户，则表明当前用户落在预设用户配置限定的用户群体范围内，可以执行后续步骤S630。

S624，若当前用户未落在预设用户配置限定的用户群体范围内，则终止后续步骤。

具体地，如我们投放的广告是游戏广告，面向成年用户，预设用户配置限定了成年用户这个用户群体范围内，若依据用户信息或者当前用户为14岁的孩童，则表明当前用户未落在预设用户配置限定的用户群体范围内，引擎服务器判断广告都不可能投放，再进行用户行为测试没有任何意义，终止后续步骤。在这个例子中，由于防止未成年人沉迷网络游戏，因此通过本实施例可以有效过滤掉不在用户群体范围内的用户。

在本申请的一实施例中，在步骤S700之后，所述用户行为的分流测试方法还包括如下步骤S810至步骤S820：

S810，在测试过程中，引擎服务器记录测试数据。

S820，在测试结束后，引擎服务器从管理端调取与唯一标识orderID对应的用户日志，将测试数据更新于所述用户日志中。所述用户日志存储于管理端的Hbase数据库。

具体地，用户日志以一行一行的字符显示，用于表达任何与用户相关的信息。

本实施例中，将测试数据更新于所述用户日志中，可以实现对测试数据的有效存储。

在本申请的一实施例中，在步骤S700之后，所述用户行为的分流测试方法还包括如下步骤：

S910，引擎服务器将所有用户行为的分流命中状况数据打印于Map区块中。所述Map区块设置于所述用户行为订单中。

S920，依据所述Map区块进行测试数据回收与分析。

具体地，Map区块是在用户行为订单中相对其他区域独立的一个展示测试信息的区块。Map区块可以显示所有用户行为的分流命中状况。后续引擎服务器或者第三方终端可以通过Map区块中不同的关键词生成不同的测试数据分析报表，这就是实现了测试数据的自动回收。

本申请还提供一种用户行为的分流测试方法，本方法的执行主体是分流测试系统中的引擎服务器。

所述用户行为的分流测试方法包括：

A100，当用户端的应用程序中的广告位被触发时，获取用户端发送的用户端数据和用户行为订单。

A200，引擎服务器依据所述用户行为订单确定用户行为的唯一标识orderID，并判断是否存在触发已配置唯一标识key的实验层的用户行为。

A300，若存在触发已配置唯一标识key的实验层的用户行为，则基于所述用户端数据和唯一标识key对所述用户行为进行分流判定，判断所述用户行为是否命中某一测试方案。

A400，若所述用户行为命中某一测试方案，则调取该用户行为命中的测试方案，并依据该测试方案进行测试。

具体地，步骤A100至步骤A400与前述实施例中的步骤S400至步骤S700的逻辑一致，此处不再赘述。

如图2所示，本申请还提供一种用户行为的分流测试系统。所述用户行为的分类测试系统应用前述内容提及的用户行为的分流测试方法。

在本申请的一实施例中，所述用户行为的分流测试系统包括管理端10、引擎服务器20和用户端30。所述管理端10包括Hbase数据库140。所述引擎服务器20与所述管理端10通信连接。所述用户端30与所述引擎服务器20通信连接。

具体地，Hbase数据库140具有分布式存储系统，存储可靠性高，不易丢失。此外，本申请提及的用户行为的分类测试系统应用前述内容提及的用户行为的分流测试方法，为了行文简洁，只在用户行为的分类测试系统的部分对结构模块进行了标号，在方法部分对结构模块没有进行标号。

如图3所示，在本申请的一实施例中，所述管理端10包括层创建模块110、第一配置模块120、第二配置模块130和Hbase数据库140。

所述层创建模块110用于创建多个实验层。所述第一配置模块120与所述层创建模块110通信连接。所述第一配置模块120用于为每一个实验层配置一个唯一标识key。所述第二配置模块130与所述层创建模块110通信连接。所述第二配置模块130用于为每一个实验层配置至少一个value值。每一个value值与一个测试方案对应。所述Hbase数据库140，与第一配置模块120和第二配置模块130分别通信连接。所述Hbase数据库140用于唯一标识key和value值的存储。

在本申请的一实施例中，所述引擎服务器20包括分类判定模块和测试模块220。所述分流判定模块210与Hbase数据库140通信连接。所述测试模块220，与分流判定模块210和Hbase数据库140分别通信连接。

所述分流判定模块210用于依据用户行为订单确定用户行为的唯一标识orderID，并判断是否存在触发已配置唯一标识key的实验层的用户行为。若存在触发已配置唯一标识key的实验层的用户行为，则基于用户端数据和唯一标识key对所述用户行为进行分流判定，判断所述用户行为是否命中某一测试方案。所述测试模块220用于调取该用户行为命中的测试方案，并依据该测试方案进行测试。

以上所述实施例的各技术特征可以进行任意的组合，各方法步骤也并不做执行顺序的限制，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对本申请专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请的保护范围应以所附权利要求为准。

Claims (10)

1.一种用户行为的分流测试方法，其特征在于，所述用户行为的分流测试方法包括：

S100，管理端创建多个实验层，为每一个实验层配置一个唯一标识key；

S200，管理端依据预设测试配置，为每一个实验层配置至少一个value值；每一个value值与一个测试方案对应；

S400，当用户端的应用程序中的广告位被触发时，应用程序通过用户端获取用户端数据，生成用户行为订单，并将用户端数据和用户行为订单发送至引擎服务器；

S500，引擎服务器依据所述用户行为订单确定用户行为的唯一标识orderID，并判断是否存在触发已配置唯一标识key的实验层的用户行为；

S600，若存在触发已配置唯一标识key的实验层的用户行为，则引擎服务器基于所述用户端数据和唯一标识key对所述用户行为进行分流判定，判断所述用户行为是否命中某一测试方案；

S700，若所述用户行为命中某一测试方案，则引擎服务器调取该用户行为命中的测试方案，并依据该测试方案进行测试。

2.根据权利要求1所述的用户行为的分流测试方法，其特征在于，所述value值为一个字符串，所述value值包括广告位信息、测试流量百分比K、测试流量百分比的流量分配份额数n和测试时间t中的一种或多种测试信息；

管理端在为每一个实验层配置至少一个value值时，在同一个实验层下，一个广告位只配置唯一一个value值。

3.根据权利要求2所述的用户行为的分流测试方法，其特征在于，在所述步骤S200之后，所述用户行为的分流测试方法还包括：

S310，管理端选取一个测试方案，获取该测试方案对应的value值；

S320，管理端读取所述value值中的测试流量百分比K，以及测试流量百分比的流量分配份额数n；n为正整数；

S330，管理端依据测试流量百分比的流量分配份额数n，将测试流量百分比K平均分配为至少一个流量百分比范围，分别为

S340，管理端将该测试方案、该测试方案对应的value值和上述步骤计算得到的至少一个流量百分比范围相对应的存储；每一个流量百分比代表该测试方案下的一个测试分支选项；

S350，反复执行所述步骤S310至步骤S340，直至所有测试方案均进行了流量百分比范围的划分。

4.根据权利要求3所述的用户行为的分流测试方法，其特征在于，所述步骤S600包括：

S610，引擎服务器进一步判断触发已配置唯一标识key的实验层的用户行为的数量是否为1；

S620，若触发已配置唯一标识key的实验层的用户行为的数量为1，则引擎服务器调取该用户行为触发的实验层对应的唯一标识key，并从用户端数据中提取用户端设备号deviceID；

S630，引擎服务器对唯一标识key和用户端设备号deviceID进行hash处理，得到hash值；

S640，引擎服务器将所述hash值对100进行取余运算，得到余数；

S650，引擎服务器分析所述余数落入流量百分比范围的情况，判断所述用户行为是否命中某一测试方案；

S660，若触发已配置唯一标识key的实验层的用户行为的数量不为1，则对每一个触发已配置唯一标识key的实验层的用户行为依次执行步骤S620至步骤S650。

5.根据权利要求4所述的用户行为的分流测试方法，其特征在于，所述步骤S650包括：

S651，引擎服务器依据被触发广告位，遍历管理端，从管理端中调取该用户行为触发的实验层下，与被触发广告位相关的value值，以及所述value值对应的所有流量百分比范围，判断所述余数是否归属于其中某一个流量百分比范围；

S652，若所述余数归属于其中某一个流量百分比范围，则确定该用户行为命中某一测试方案。

6.根据权利要求5所述的用户行为的分流测试方法，其特征在于，所述步骤S700包括：

S710，引擎服务器提取所述余数归属的流量百分比范围，从管理端中调取与该流量百分比范围对应的测试分支选项；

S720，引擎服务器采用该测试分支选项进行测试。

7.根据权利要求6所述的用户行为的分流测试方法，其特征在于，在步骤S630之前，所述步骤S600还包括：

S621，引擎服务器从用户端数据中提取用户信息，并从管理端调取预设用户配置；

S622，引擎服务器将预设用户配置与当用户信息进行匹配，依据匹配结果判断当前用户是否落在预设用户配置限定的用户群体范围内；

S623，若当前用户落在预设用户配置限定的用户群体范围内，则执行后续步骤S630；

S624，若当前用户未落在预设用户配置限定的用户群体范围内，则终止后续步骤。

8.根据权利要求7所述的用户行为的分流测试方法，其特征在于，在步骤S700之后，所述用户行为的分流测试方法还包括：

S810，在测试过程中，引擎服务器记录测试数据；

S820，在测试结束后，引擎服务器从管理端调取与唯一标识orderID对应的用户日志，将测试数据更新于所述用户日志中；所述用户日志存储于管理端的Hbase数据库。

9.根据权利要求8所述的用户行为的分流测试方法，其特征在于，在步骤S700之后，所述用户行为的分流测试方法还包括：

S910，引擎服务器将所有用户行为的分流命中状况数据打印于Map区块中；所述Map区块设置于所述用户行为订单中；

S920，依据所述Map区块进行测试数据回收与分析。

10.一种用户行为的分流测试系统，其特征在于，其应用权利要求1-9中任意一项所述的用户行为的分流测试方法，所述用户行为的分流测试系统包括：

管理端，包括Hbase数据库；

引擎服务器，与所述管理端通信连接；

用户端，与所述引擎服务器通信连接。

Images