技术领域
[0001] 本申请涉及数据处理技术领域，特别是涉及一种基于直播的虚拟奖励元素的显示方法、装置及电子设备。
相关背景技术
[0002] 网络直播是一种网络交互模型，主播用户可以通过主播客户端创建直播间，并通过该直播间进行在线直播，观众用户可以通过观众客户端进入该直播间观看主播用户直播的内容。在直播中，为了能够增加与观众用户的互动，主播可以设置虚拟奖励元素(例如，福袋等)，并将虚拟奖励元素展示在直播间对应的视频画面中。观众用户可以参与对应虚拟奖励元素的抢夺，以增加直播间的互动性。
[0003] 但是，随着越来越多的互联网非法用户(例如，使用虚假或者非法取得的身份信息的黑产用户)的参与，他们模拟正常用户点击虚拟奖励元素来获取丰富的奖励，对直播平台造成很大的资金损失。为了解决这一问题，直播平台一般会通过对用户的设备进行黑白名单的人工标记，这些需要人力成本较高，并且在识别非法用户时效率低、准确性低，无法解决直播间的虚拟奖励元素的下发的合理性和公平性的问题。
具体实施方式
[0047] 下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
[0048] 本申请中的术语“第一”和“第二”等是用于区别不同的对象，而不是用于描述特定的顺序。此外术语“包括”和“具有”以及他们任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有设定于已列出的步骤或单元，而是可包括没有列出的步骤或单元。
[0049] 为了便于对本申请提供的基于直播的虚拟奖励元素的显示方法进行说明，现将本申请中实施例以及应用场景中的相关术语进行说明。
[0050] 黑产：也称为黑色产业链，其不以正常使用为目的，使用虚假的或者非法取得的身份信息，以人工和自动工具结合方式绕过平台风险管控实施网络账号批量注册的行为。黑产团伙可以利用这些网络账号开展网络诈骗、抢票囤号、恶意抢券、虚假流量营销等活动。
[0051] 福袋：应用程序(APP)中直播间通常出现在两边的弹窗交表，用户点击角标可以进入活动页面参与活动。
[0052] 设备：在本申请实施例中的设备包括但不限于能够观看直播间的终端设备、提供接口能力的服务器的电脑、服务器设备，以及黑产所拥有的非法修改的设备等。
[0053] 设备标识(设备ID)：即设备的唯一标识，本申请实施例中的设备ID可以包括：MEI(International Mobile Equipment Identity，国际移动设备识别码)OAID(IOS设备的唯一识别码)，ANDROIDID：(安卓设备的唯一识别码)，其中，不同的设备对应的设备ID不一样。
[0054] 长链接：服务器与手机客户端APP的点对点通信模式，用于操作频繁场景。
[0055] MQTT：是一个基于客户端‑服务器的消息发布/订阅传输协议。MQTT协议是轻量、简单、开放和易于实现的，这些特点使它适用范围非常广泛。在很多情况下，包括受限的环境中，如。机器与机器(M2M)通信和物联网(IoT)。其在，通过卫星链路通信传感器、偶尔拨号的医疗设备、智能家居、及一些小型化设备中已广泛使用。
[0056] 参见图1，为黑产参与直播间抽奖的一种实现手段的流程示意图。该实现过程包括以下步骤：
[0057] S101、黑产注册大量账号，并通过控制的应用程序来登录，模拟用户正常登录行为，并保持登录状态。
[0058] S102、逆向执行应用程序，通过抓包获取参与抽奖的接口请求。
[0059] S103、自动监测屏幕的变化，以确定福袋出现的位置。
[0060] 其中，黑产判断福袋出现的方法包括截屏判断和接口抓取判断等。
[0061] S104、当福袋角标出现后，快速模拟点击角标参与活动。
[0062] 如果有验证码则进行验证码破解校验。
[0063] S105、控制大量账号直接模拟接口请求。
[0064] 实现大量黑产账号参与抽奖，只要其中有一个抽中奖品，黑产就有收益，直播平台就会损失。
[0065] 为了解决上述黑产的非法参与直播间的正常活动的问题，在本申请实施例中提供了一种基于直播的虚拟奖励元素的显示方法，该方法可以在终端上执行，也可以是在服务器上执行，还可以由终端和服务器共同执行。在一种应用场景中，终端可以包括主播终端和用户终端，主播终端用于采集主播直播时的直播画面，用户终端用于展示直播间的画面以及相关的直播信息，服务器可以接收主播终端传输的直播画面，还可以接收用户终端产生的针对直播画面的反馈信息，然后对这些信息进行处理，实时输出对应的目标直播画面至主播终端和用户终端，例如该目标直播画面可以包括主播实时的直播画面以及主播和用户交互的文字信息、用户的留言信息、商品的链接信息等。其中，终端可以包括手机、智能电视、平板电脑、笔记本电脑或个人计算机等。终端上用于展示直播画面的可以是直播平台的客户端，也可以是该应用程序客户端或者浏览器客户端等。服务器可以是单台服务器，也可以是由多态服务器组成的服务器集群或者云服务器等。参见图2，该方法可以包括以下步骤：
[0066] S201、响应于在直播间显示虚拟奖励元素的第一触发操作，获得直播间用户对应的用户分组信息。
[0067] 直播是通过一定设备采集开播方(也称为主播方)数据，经过一系列处理如视频编码压缩成可观看可传输的视频流，输出至观看用户端的技术。直播间是指主播与观看直播的用户组成的可互动的网络空间。虚拟奖励元素可以是主播端下发给直播间用户的可抽取的奖励资源，该虚拟奖励元素代表实体的物品奖励。例如，当用户抽中该虚拟奖励元素后，可以免费获得该虚拟奖励元素对应的实际商品。通常虚拟奖励元素可以是福袋、红包或者专属道具等，本申请实施例对此不进行限制，为了便于描述在本申请实施例中虚拟奖励元素主要以福袋为例进行说明。
[0068] 第一触发操作为在直播间显示虚拟奖励元素的触发操作，可以是主播通过添加待显示的虚拟奖励元素时产生的操作，例如主播下发福袋的触发操作。当检测到第一触发操作时，获得直播间用户对应的用户分组信息。直播间用户可以是当前直播间内的所有用户，也可以是具有特定标识的用户，如直播间内非白名单内的用户，而白名单中的用户对应的虚拟奖励元素可以按照默认的显示模式进行显示。以对直播间的全部用户为例，可以预先对这些用户进行分组，得到对应的用户分组信息，该用户分组信息中包括至少一个用户组，每一用户组中包括至少一个用户，每一用户组的用户对应一类的用户属性特征。该用户属性特征可以表征该用户组的用户类型，如白名单用户、风险用户、黑名单用户等。
[0069] 在本申请实施例中对直播间用户进行分组时，可以将用户分为风险用户和非风险用户，风险用户可能是非法用户，如通过黑产模式产生的用户；非风险用户可以是正常的用户，如主播的粉丝等。进一步地，还可以根据风险等级对风险用户进行分组；根据随机分组方式对非风险用户进行分组。通过对直播间用户进行分组的处理模式，能够更准确地获得每一用户组的用户特点，为后续更精准的处理模式提供了参考信息。
[0070] S202、基于所述用户分组信息，确定与每一用户组对应的虚拟奖励元素的显示模式。
[0071] S203、基于与目标用户对应的显示模式，在目标用户的直播显示界面中显示虚拟奖励元素的目标显示信息。
[0072] 由于每一用户组的用户对应一类的用户属性特征，从而可以为每一用户组匹配对应的虚拟奖励元素的显示模式。该显示模式与用户属性特征相匹配，如当前用户组的用户为正常用户，其虚拟奖励元素的显示模式可以是直播平台默认的显示模式，以福袋为例，可以将福袋显示在直播画面的左上角。如果该用户组对应的用户为风险用户，可以确定显示信息更加复杂或者显示方式更加多变的显示模式，从而进行虚拟奖励元素的显示，如通过变换不同的显示位置进行显示，或者通过变化不同的显示图标进行显示等。这样可以避免非法用户对相同的展示模式的虚拟奖励元素的点击模拟，获得对应的奖励造成其他真实正常用户无法获得奖励的问题。在本申请实施例中，用户组属于风险用户的等级越高，其对应的虚拟奖励元素的显示模式越复杂，越多变。
[0073] 在确定了每一用户组对应的虚拟奖励元素的显示模式后，会根据该显示模式对虚拟奖励元素进行显示。其中，在步骤S203中，目标用户为当前直播间中的所有用户，也可以是当前直播间中满足参与本次虚拟奖励元素抽奖的用户，确定与目标用户所在用户组对应的虚拟奖励元素的显示模式，然后基于该显示模式显示对应的虚拟奖励元素。这样可以解决黑产用户对虚拟奖励元素的抽奖过程的模拟，并获得奖励的问题，并且自动对直播间用户进行分组，无需人工标注各个用户的相关信息，提升了数据处理的效率及精准度。同时自动匹配与用户组对应的虚拟奖励元素的显示模式，能够提高直播间奖励抽奖的真实用户中奖概率，提高真实用户留存率，保证了直播间互动的公平性。
[0074] 下面结合具体的应用场景对本申请实施例的相关内容进行说明。
[0075] 在本申请实施例中可以根据用户的网络地址信息、用户的账户信息等对直播间用户进行分组。进一步为了能够实现对直播间用户的精准分组，以及识别到直播间的风险用户，在本申请实施例的一种实施方式中，获得直播间用户对应的分组信息，包括：
[0076] 获得直播间用户的用户设备信息以及用户身份信息；基于用户设备信息和用户身份信息，对直播间用户进行分组，得到用户分组信息。
[0077] 可以是在产生虚拟奖励元素显示需求的时候，再对直播间的用户进行分组，也可以是根据直播间当前的用户进行分组，例如，直播间中每增加一个用户就获取该用户的设备信息和身份信息，然后对其进行分组，这样可以在需要用户分许信息的时候，可以快速调用对应的分组信息。
[0078] 用户设备信息可以包括设备标识(Device ID)、操作系统信息、网络信息、浏览器信息、应用信息、地理位置信息等。具体的，设备标识可以包括IMEI、MAC地址等唯一标识符。操作系统信息可以包括操作系统类型和版本信息等，如Android、iOS的版本。网络信息可以包括设备的IP地址、Wi‑Fi信息、网络运营商等信息。浏览器信息可以包括浏览器类型和版本。应用信息可以包括应用版本号、设备安装的应用列表、应用初始化时会生成一个应用级别的32位唯一设备ID。地理位置信息可以包括设备的当前位置和常用登陆位置的信息等。
通过对用户设备信息的采集可以用于评估该设备是否为当前用户常用设备以及评估设备的风险等级、检测是否存在设备异常等问题。需要说明的是，在本申请实施例中获得的用户设备信息和用户身份信息均是用户授权的相关信息。
[0079] 用户身份信息可以包括用户账号信息，如用户登录直播平台的账号、手机号、邮箱等信息；还可以包括用户历史行为数据，具体可以看登录历史、设备使用历史、常用IP地址等。用户身份信息还可以包括登录账户后的操作信息，如用户最近的购买记录，是否属于正常购买、是否存在刷单行为或者是否存在大量退货行为等。通过对用户身份信息的分析，可以确定该用户是否为正常的使用用户。
[0080] 然后根据用户设备信息和用户身份信息进行用户分组，在一些应用场景中也可以将该过程称为“分桶”，即根据用户设备信息和用户身份信息对用户进行分析，并按照一定的规则进行不同的分类。之所以对用户进行分组，是为了将用户进行归类，不同分组下发不同的数据，便于对不同的用户执行不同的处理，以满足当前应用场景的需求。
[0081] 具体的，在本申请实施例中对直播间用户进行分组时，主要包括了常规用户即非风险用户的分组和风险用户的分组，这样能够更细化地进行用户，实现精准处理，以保证了直播间用户互动的多样性。
[0082] 在一种实施方式中，基于用户设备信息和用户身份信息，对直播间用户进行分组，得到用户分组信息，包括：
[0083] 基于用户身份信息，对用户进行身份验证，若验证通过，获取用户的参与直播间的互动数据；基于互动数据，确定用户是否为风险用户；如果用户为风险用户，基于用户对应的风险等级对各个风险用户进行分组，得到风险用户的第一分组信息；如果用户为非风险用户，基于用户设备信息对各个非风险用户进行分组，得到非风险用户的第二分组信息。其中，第一分组信息包括至少一个风险用户组，各个风险用户组对应的风险等级不同；第二分组信息包括至少一个非风险用户组。
[0084] 用户设备进入直播间与服务器建立链接，在建立了链接后，会基于用户身份信息对用户进行校验，如基于用户的账号信息对用户账号登录权限校验，通过校验后，确定该用户能够接收后续的虚拟奖励元素等消息的推送。具体的，登录校验包括但不局限于手机号校验、滑动校验等，本申请实施例对此不进行限定。在用户身份验证通过后，服务端可以进一步获取用户的相关信息，如获取用户参与直播间的互动数据等，具体可以包括用户在直播间历史抽奖记录、历史违规记录、账号活跃程度、与其他账号的设备信息的相似信息、用户的交易信息等，然后根据这些信息确定用户是否为风险用户，并确定其对应的风险等，如用户的账号经常违规并总抽中直播间福利或者IP地址变换频繁，无固定登录地点等，可以将该用户识别为高风险用户。对应的，若用户为风险用户时，可以基于风险等级确定第一分组信息，第一分组信息包括高风险用户组、中风险用户组和低风险用户组，也可以根据其他的风险量化参数，确定第一分组信息中的风险用户组的数量和类别等。
[0085] 如果用户为非风险用户，基于用户设备信息对各个非风险用户进行分许，得到非风险用户的第二分组信息，第二分组信息包括至少一个非风险用户组。如可以根据用户设备信息中的用户设备ID进行计算并分组。
[0086] 举例说明，对直播间用户进行常规分组和风险分组，其中，常规分组针对非风险用户，风险分组针对风险用户。
[0087] 常规分组(也称为常规分桶)：将用户设备信息进行分类，为了将用户随机打散并分类平均，直接将请求参数中的设备ID进行一个32位的md5算法(其中，md5算法是不可逆字符串摘要算法，结果是16进制的32位字母加数字)，然后取第一位，例如，设备ID是abc123的设备进行md5后的值是e99a18c428cb38d5f260853678922e03，取第一位则是e，这样情况一共有16种，因为是16进制的结果，即(0‑9a‑f)，同时还会有一个白名单分桶，优质用户、白名单用户、测试用户等正常用户可以进入y桶。
[0088] 风险分组(也称为风险分桶)：直接将有风险的用户，如黑产用户设备、伪造接口请求或者批量刷单的用户等进入x桶，因此，在该举例中，分桶共有18种(16种常规桶，0‑9，a‑f，以及白名单桶y，风险桶x)，然后可以根据直播间的配置进行分桶缩小或者再规则化，例如0‑3是A桶，4‑7是B桶，以此类推。
[0089] 在对直播间用户进行分组后，可以进一步确定与每一用户组对应的虚拟奖励元素的显示模式。在一种实施方式中，基于用户分组信息，确定与每一用户组对应的虚拟奖励元素的显示模式，包括：
[0090] 基于用户分组信息，获得每一用户组对应的用户属性特征；根据用户属性特征，确定虚拟奖励元素的展示位置信息以及虚拟奖励元素的元素特征信息；基于虚拟奖励元素的展示位置信息以及元素特征信息，确定每一用户组对应的虚拟奖励元素的显示模式。
[0091] 在获得了分组信息后，根据每一用户组对应的用户属性特征，可以确定该用户组的类型，如属于风险用户组还是常规用户组。进一步确定显示模式，可以包括虚拟奖励元素的展示位置、元素特征信息以及展示时间和验证方式等等。如虚拟奖励元素为福袋时，展示位置可以是指福袋呈现在直播画面中的位置，具体可以是左上角、右上角、左下角、右下角等；元素特征信息可以包括福袋的大小、颜色、形状等。展示时间可以是指福袋在直播画面中的呈现时长，若用户为常规用户，则福袋在其终端显示的直播画面中呈现的时长为正常时长，若用户为风险用户，则福袋的展示时间较短，避免风险用户通过模拟点击快速击中福袋的问题。验证方式可以是指用户点击福袋后的验证模式。通过不同的显示模式的设置，可以避免非法用户通过模拟福袋的领取方式来获取直播间福袋的问题，保证直播间正常用户福袋获取的公平性。
[0092] 进一步地，虚拟奖励元素的显示模式还包括对虚拟奖励元素的触发后的验证模式，该方法还包括：基于每一用户组对应的用户风险等级，确定对虚拟奖励元素的触发后的验证模式，若基于验证模式对当前用户验证通过后，将当前用户确定为虚拟奖励元素对应的奖励待发放用户。
[0093] 以虚拟奖励元素为福袋为例，正常用户点击福袋后会进入候选中奖池，然后通过随机算法进行前N名的福袋抽奖，并公布福袋中奖名单。若风向用户点击福袋后，需要通过验证才能进入候选中奖池，即成为奖励待发放用户。其中，可以通过问题的验证方式，或者发送与当前直播内容相关的信息、验证码等方式进行验证。这样可以避免直接取消风险用户参与福袋抽奖时，造成的风险用户误判断的问题，通过加验的方式可以排除风险用户误判到导致用户无法参与福袋抽奖的问题，进一步提升了用户识别的准确性。
[0094] 进一步地，基于每一用户组对应的用户风险等级，确定虚拟奖励元素的触发后的验证模式，包括：若当前用户组的风险等级为高风险等级，确定与用户组对应的至少一种验证信息以及用户对应的用户的信息验证触发模式；基于至少一种验证信息以及用户对应的用户信息验证触发模式，确定虚拟奖励元素的触发后的验证模式。
[0095] 其中，若同为高风险分组的用户，其对应的验证模式是不同的，避免非法用户对验证信息的模拟。例如，同一高风险分组的用户的验证题目是不同的，同时对信息验证触发模式也进行了限制，如高风险用户在进行验证题目的答复的时候仅用户文本信息输入，不允许截屏或者录屏等操作，以避免非法用户对验证题目的复制等，从而导致验证的不准确。
[0096] 对应的，在本申请实施例中还包括：
[0097] 响应于接收目标用户对虚拟奖励元素的第二触发操作，基于所述目标用户对应的用户属性特征，对所述目标用户进行验证；验证通过，将所述目标用户确定为所述虚拟奖励元素对应的奖励待发放用户。
[0098] 具体的，若是常规正常用户，在其对虚拟奖励元素进行第二触发操作(如点击操作等)后，可以直接进入候选中奖池。风险等级较低的用户可以通过滑动验证等进行验证，风险等级较高的用户可以通过回答问题进行验证，验证通过的用户进入候选中奖池，即成为奖励待发放用户。然后通过随机算法进行前N名的福袋抽奖，并公布名单。
[0099] 在本申请实施例中，进一步为了避免非法用户对直播间的奖励的非法占有，该方法还包括：基于目标用户对应的用户属性特征，生成与第二触发操作对应的反馈信息。
[0100] 例如，可以是对所有的用户均反馈参与成功的信息。也可以根据用户分组的不同反馈的信息不同，具体的，若目标用户为常规的正常用户，在其对虚拟奖励元素进行第二触发后，如对福袋图标进行点击后，则生成的对应反馈信息可以是“参与成功，等待开奖”，或者是“发送结束，请您下次参与”等。若对于风险用户，则直接反馈为其成功的消息，这样若风险用户为黑产用户时，其无法预知自己是否提交成功，只有服务器会进行判断。在这种情况下，会使得黑产用户认为自己被验证成功，复制对应的验证题目等，并发送给其它黑产用户，服务器也可以基于上述黑产用户的这种行为快速识别出风险用户。
[0101] 下面结合具体的应用场景，对本申请实施例的基于直播的虚拟奖励元素的显示方法进行说明。
[0102] 以虚拟奖励元素为直播间中的福袋为例。参见图3，为本申请实施例提供的一种福袋抽奖方法的流程图。该福袋抽奖方法可以包括：
[0103] S301、用户设备进入直播间与服务器建立链接。
[0104] 建立链接之后，会进行用户账号的登录权限校验，通过校验后，用户能够接收后续的福袋等消息的推送。具体的登录校验包括不限于手机号验证、滑动验证等。
[0105] S302、服务端获取用户信息，并根据用户信息确定用户是否为风险用户。
[0106] 用户信息包括历史抽奖记录，历史违规记录，账号是否属于风险账号，若属于异常行为的用户，则记录为单独的风险设备分组。
[0107] S303、对非风险用户根据用户设备ID进行分组，创建不同福袋配置。
[0108] 每一个分组配置不同的福袋信息。
[0109] S304、通过MQTT长链接，向所有设备推送福袋角标，展示不同福袋信息。
[0110] S305、用户点击福袋抽奖，并进行其他验证。
[0111] 用户点击福袋，根据福袋提示参与抽奖，可以参与抽奖的方式不限于发送弹幕参与抽奖，点击福袋即抽奖以及点击福袋后进行答题校验等方式。
[0112] S306、服务器接收用户参与抽奖的请求后，进行参数校验。
[0113] 若校验成功则进入抽奖池，到时间后随机出符合抽奖要求的用户，并发送奖励。
[0114] 具体的，在为不同分组生成福袋的不同展示信息可以包括：
[0115] 用户登录认证后，服务器服务可以获取用户的历史日志，是否属于风险用户(频繁切换账号，多个设备登录参与抽奖)，当判断为风险用户，则将设备分组(也可以称为分桶)单独定义为risk01。
[0116] 其他直播间用户根据设备id进行分组，分组方法采用将设备的唯一id(oaid，androidid)进行转换，本申请实施用例采用md5方法，将用户的设备id，其中OAID属于IOS的设备唯一id，androidid属于安卓设备的唯一id，将设备id，md5之后取第一位字符，md5后的字符为16进制，由0‑9，a‑f字符表示，因此有16种分组区间。此处若想缩小分桶为4个，可以将A(0‑3)，B(4‑8)，C(9‑c),D(d‑f)，以此类推，从概率上来说，分组的区间是基本相等的，因此不会出现某一个组的人数设备较多而产生其他问题。
[0117] 用户设备分组完成之后，下面按照4个分桶的实施用例进行说明，如图4所示，为直播间福袋展示界面，可以福袋展示区间有4个区域，因此，将ABCD四个分桶的福袋配置，可以对应4个区域，设备A组用户弹出的区域是S401，设备B用户的区域是S402，设备C和D分别是S403和S404。用户分组完成后，当需要进行福袋推送时，后端服务器根据不同的设备分组发送福袋展示信息，客户端APP接收到福袋展示信息后，进行展示。
[0118] 客户端接收的福袋信息包括有：(1)福袋的位置(从图4可见，福袋可以出现的位置有6个位置)，这一点提高了客户端的模拟点击位置的试错次数。(2)福袋静态配置如福袋图片，图片大小。(3)角标点击后的后续操作指令，如点击跳转到其他活动页面的跳转地址、为了更严格还有加验的题目配置如图5所示。
[0119] 如图5中加验题目属于可选抽奖的配置，能提升安全性和公平性质，题目同由福袋推送信息推送，根据不同的设备ID，下发不同的题干和选项。在本示例中，题目先由服务端配置，根据本直播间的主要目标观众设置多组题库。本申请实施例实施用例中，4个分组，则至少设置4个题目，当黑产设备取得题目A后，使用大量账号批量模拟参与抽奖的请求时，因为不同设备题目和答案不一样，这些账号的模拟请求大多会失败。
[0120] 在本申请实施例中，客户端APP启动时需要初始化安全配置，主要包括：
[0121] IOS通过拦截所有使用NSURLSession类创建对象的方法，避免代理抓包的方式进行放抓包初始化，同时为了禁止直播间内截屏，通过设置UIApplication.shared.isProhibitedScreenCapture属性为true可以禁用整个应用程序的截屏功能。安卓设备使用Proxy.NO_PROXY防止代理请求的方式初始化APP。同时为了禁止直播间内截屏，需要使用FLAG_SECURE这个window flag。这个flag可以在Activity的onCreate()方法中设置。当前Activity的内容就不会被截屏或者捕捉。
[0122] 具体的，用户参与福袋抽奖的流程可以包括：
[0123] 客户端请求参与抽奖时，需要携带必要参数，这些参数包括用户设备ID、分组ID、点击福袋位置坐标、加验题目以及答案参数。后端服务器对设备ID进行分组，与提交的分组参数进行匹配验证，并根据点击的坐标查看是否是预期的点击坐标，并且判断是否是风险用户组。根据分组信息，确定用户的题干与答案，是否与提交上来的题目和答案参数能够匹配。如果任一参数不匹配，则无法进入直播抽奖用户持。在本申请实施例中可以是对速搜有提交的返回都给用户返回参与成功。客户端包括黑产用户无法预知自己的参数是否提交正确，只有服务器会进行判断。当福袋到期，进行随机数排序，取前N位，即为中奖用户。此随机方式不限(hash、时间戳种子等均可)。再通过MQTT对客户端进行推送，中奖名单。同时记录用户中奖历史记录。
[0124] 在本申请的另一实施例还提供了一种基于直播的虚拟奖励元素的显示装置，参见图6，所述装置包括：
[0125] 获取单元601，用于响应于在直播间显示虚拟奖励元素的第一触发操作，获得直播间用户对应的用户分组信息，其中，所述用户分组信息中包括至少一个用户组，每一用户组的用户对应一类的用户属性特征；
[0126] 确定单元602，用于基于所述用户分组信息，确定与每一用户组对应的所述虚拟奖励元素的显示模式；
[0127] 显示单元603，用于基于与目标用户对应的所述显示模式，在所述目标用户的直播显示界面中显示所述虚拟奖励元素的目标显示信息。
[0128] 可选地，所述获取单元包括：
[0129] 第一获取子单元，用于获得直播间用户的用户设备信息以及用户身份信息；
[0130] 第一分组子单元，用于基于所述用户设备信息和所述用户身份信息，对所述直播间用户进行用户分组，得到用户分组信息。
[0131] 可选地，所述第一分组子单元被配置为：
[0132] 基于所述用户身份信息，对所述用户进行身份验证，若验证通过，获取所述用户的参与直播间的互动数据；
[0133] 基于所述互动数据，确定所述用户是否为风险用户；
[0134] 如果所述用户为风险用户，基于用户对应的风险等级对各个所述风险用户进行分组，得到风险用户的第一分组信息，所述第一分组信息包括至少一个风险用户组，各个风险用户组对应的风险等级不同；
[0135] 如果所述用户为非风险用户，基于所述用户设备信息对各个所述非风险用户进行分组，得到非风险用户的第二分组信息，所述第二分组信息包括至少一个非风险用户组。
[0136] 可选地，所述确定单元包括：
[0137] 第二获取子单元，用于基于所述用户分组信息，获得每一用户组对应的用户属性特征；
[0138] 第一确定子单元，用于根据所述用户属性特征，确定所述虚拟奖励元素的展示位置信息以及所述虚拟奖励元素的元素特征信息；
[0139] 第二确定子单元，用于基于所述虚拟奖励元素的展示位置信息以及所述元素特征信息，确定每一用户组对应的所述虚拟奖励元素的显示模式。
[0140] 可选地，所述虚拟奖励元素的显示模式还包括对所述虚拟奖励元素的触发后的验证模式，所述装置还包括：
[0141] 验证模式确定单元，用于基于每一用户组对应的用户风险等级，确定对所述虚拟奖励元素的触发后的验证模式；
[0142] 待发放用户确定单元，用于若基于所述验证模式对当前用户验证通过后，将所述当前用户确定为所述虚拟奖励元素对应的奖励待发放用户。
[0143] 可选地，所述验证模式确定单元包括：
[0144] 第三确定子单元，用于若当前用户组的风险等级为高风险等级，确定与所述用户组对应的至少一种验证信息以及所述用户对应的用户的信息验证触发模式；
[0145] 第四确定子单元，用于基于所述至少一种验证信息以及所述用户对应的用户的信息验证触发模式，确定对所述虚拟奖励元素的触发后的验证模式。
[0146] 可选地，所述装置还包括：
[0147] 验证单元，用于响应于接收所述目标用户对所述虚拟奖励元素的第二触发操作，基于所述目标用户对应的用户属性特征，对所述目标用户进行验证；若验证通过，将所述目标用户确定为所述虚拟奖励元素对应的奖励待发放用户。
[0148] 可选地，所述装置还包括：
[0149] 生成单元，用于基于所述目标用户对应的用户属性特征，生成与所述第二触发操作对应的反馈信息。
[0150] 需要说明的是，本实施例中各个单元以及子单元的具体实现可以参考前文中的相应内容，此处不再详述。
[0151] 在本申请的另一实施例中，还提供了一种存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时，实现如上任一项所述的基于直播的虚拟奖励元素的显示方法。
[0152] 在本申请的另一实施例中，还提供了一种电子设备，所述电子设备可以包括：
[0153] 存储器，用于存储应用程序和所述应用程序运行所产生的数据；
[0154] 处理器，用于执行所述应用程序，以实现如上述中任一项所述基于直播的虚拟奖励元素的显示方法。
[0155] 需要说明的是，本实施例中处理器的具体实现可以参考前文中的相应内容，此处不再详述。
[0156] 本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。
[0157] 专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
[0158] 结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD‑ROM、或技术领域内所公知的任意其它形式的存储介质中。
[0159] 对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。
