CN114679600A - 数据处理方法及装置 - Google Patents

数据处理方法及装置 Download PDF

Info

Publication number
CN114679600A
CN114679600A CN202210295349.7A CN202210295349A CN114679600A CN 114679600 A CN114679600 A CN 114679600A CN 202210295349 A CN202210295349 A CN 202210295349A CN 114679600 A CN114679600 A CN 114679600A
Authority
CN
China
Prior art keywords
user
verified
score
live broadcast
brush
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202210295349.7A
Other languages
English (en)
Inventor
孙袁袁
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Shanghai Bilibili Technology Co Ltd
Original Assignee
Shanghai Bilibili Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Shanghai Bilibili Technology Co Ltd filed Critical Shanghai Bilibili Technology Co Ltd
Priority to CN202210295349.7A priority Critical patent/CN114679600A/zh
Publication of CN114679600A publication Critical patent/CN114679600A/zh
Priority to PCT/CN2022/143537 priority patent/WO2023179162A1/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/21—Server components or server architectures
    • H04N21/218—Source of audio or video content, e.g. local disk arrays
    • H04N21/2187—Live feed
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/24—Monitoring of processes or resources, e.g. monitoring of server load, available bandwidth, upstream requests
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/442—Monitoring of processes or resources, e.g. detecting the failure of a recording device, monitoring the downstream bandwidth, the number of times a movie has been viewed, the storage space available from the internal hard disk
    • H04N21/44213—Monitoring of end-user related data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/4508—Management of client data or end-user data
    • H04N21/4532—Management of client data or end-user data involving end-user characteristics, e.g. viewer profile, preferences

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Social Psychology (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

本申请实施例提供了数据处理方法及装置，其中，所述数据处理方法应用于心跳服务器，包括：接收历史心跳数据，其中，所述历史心跳数据中包含待验证用户的用户标识，基于所述用户标识获取所述待验证用户的用户画像及直播行为数据，根据所述用户画像确定所述待验证用户的第一刷量分值，并根据所述直播行为数据确定所述待验证用户的第二刷量分值，根据所述第一刷量分值和/或所述第二刷量分值确定所述待验证用户的刷量验证结果。

Description

数据处理方法及装置
技术领域
本申请实施例涉及计算机技术领域，特别涉及一种数据处理方法。本申请一个或者多个实施例同时涉及一种数据处理装置，一种计算设备，以及一种计算机可读存储介质。
背景技术
随着网络通信技术的进步和宽带网络的提速，直播得到了越来越多的发展和应用。在现有直播体系中，人气是用于直播平台各个房间排名的重要指标，一般而言人气越高，排名越靠前，主播越有可能被用户观看。人气计算中直播间实时观看人数是关键一环，而一些主播为了提高人气，会通过非法手段模拟观看直播间，伪造直播间的在线观看人数，即通过刷量提高人气排名。因而，如何精确判断直播间是否存在刷量情况，是维护直播平台生态稳定的重要手段。
目前是根据内容分发网络提供的连接数，或者根据直播平台的心跳数据，确定直播间的观看人数，通过判断直播间的观看人数是否过于虚高，或者是否有用户举报，来判断直播间的观看人数是否异常。然而，上述确定直播间是否刷量的方法过于单一，只局限于内容分发网络提供的连接数或直播平台的心跳数据，导致确定直播间是否刷量的准确性较低，进而导致维护直播平台生态稳定的收效甚微。
发明内容
有鉴于此，本申请实施例提供了一种数据处理方法。本申请一个或者多个实施例同时涉及一种数据处理装置，一种计算设备，以及一种计算机可读存储介质，以解决现有技术中存在的确定直播间是否刷量的准确性较低的技术缺陷。
根据本申请实施例的第一方面，提供了一种数据处理方法，应用于心跳服务器，包括：
接收历史心跳数据，其中，所述历史心跳数据中包含待验证用户的用户标识；
基于所述用户标识获取所述待验证用户的用户画像及直播行为数据；
根据所述用户画像确定所述待验证用户的第一刷量分值，并根据所述直播行为数据确定所述待验证用户的第二刷量分值；
根据所述第一刷量分值和所述第二刷量分值确定所述待验证用户的刷量验证结果。
根据本申请实施例的第二方面，提供了一种数据处理装置，应用于心跳服务器，包括：
接收模块，被配置为接收历史心跳数据，其中，所述历史心跳数据中包含待验证用户的用户标识；
获取模块，被配置为基于所述用户标识获取所述待验证用户的用户画像及直播行为数据；
第一确定模块，被配置为根据所述用户画像确定所述待验证用户的第一刷量分值，并根据所述直播行为数据确定所述待验证用户的第二刷量分值；
第二确定模块，被配置为根据所述第一刷量分值和所述第二刷量分值确定所述待验证用户的刷量验证结果。
根据本申请实施例的第三方面，提供了一种计算设备，包括：
存储器和处理器；
所述存储器用于存储计算机可执行指令，所述处理器用于执行所述计算机可执行指令，其中，所述处理器执行所述计算机可执行指令时实现所述数据处理方法的步骤。
根据本申请实施例的第四方面，提供了一种计算机可读存储介质，其存储有计算机可执行指令，该指令被处理器执行时实现所述数据处理方法的步骤。
本申请一个实施例实现了一种数据处理方法及装置，其中，所述数据处理方法应用于心跳服务器，通过接收历史心跳数据，基于历史心跳数据中包含的用户标识获取待验证用户的用户画像及直播行为数据，根据用户画像确定待验证用户的第一刷量分值，并根据直播行为数据确定待验证用户的第二刷量分值，根据第一刷量分值和第二刷量分值确定待验证用户的刷量验证结果。
本申请实施例通过结合待验证用户的用户画像及其在观看直播过程中生成的直播行为数据，综合判断该待验证用户的刷量验证结果，从而更加精准地确定待验证用户是否为刷量用户，有利于提高判断待验证用户是否刷量的判断结果的准确率，进而有利于维护直播平台生态的稳定性。
附图说明
图1是本申请一个实施例提供的一种数据处理过程的***架构图；
图2是本申请一个实施例提供的一种数据处理方法的流程图；
图3是本申请一个实施例提供的一种数据处理方法应用于直播领域的防刷场景的处理过程流程图；
图4是本申请一个实施例提供的一种数据处理装置的结构示意图；
图5是本申请一个实施例提供的一种计算设备的结构框图。
具体实施方式
在下面的描述中阐述了很多具体细节以便于充分理解本申请。但是本申请能够以很多不同于在此描述的其它方式来实施，本领域技术人员可以在不违背本申请内涵的情况下做类似推广，因此本申请不受下面公开的具体实施的限制。
在本申请一个或多个实施例中使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请一个或多个实施例。在本申请一个或多个实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本申请一个或多个实施例中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。
应当理解，尽管在本申请一个或多个实施例中可能采用术语第一、第二等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请一个或多个实施例范围的情况下，第一也可以被称为第二，类似地，第二也可以被称为第一。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。
首先，对本申请一个或多个实施例涉及的名词术语进行解释。
直播流：直播音视频数据的传输，它能够被作为一个稳定的和连续的流通过网络传输给观众观看。
直播人气：综合在线人数，弹幕数，礼物数等按照一定比例算出的数值，用于在直播平台按照人气的高低进行排名。
直播人数：实时观看直播间的真实人数。
刷量：通过模拟正常用户访问，产生大量虚假观看的情况。
防刷：通过技术手段，识别非法访问的请求，并拒绝非法请求。
刷子：进行刷量的非法用户。
用户画像：用户画像是根据用户社会属性、生活习惯和消费行为等信息而抽象出的一个标签化的用户模型。
UID：用户账号的唯一标识符。
在本申请中，提供了一种数据处理方法。本申请一个或者多个实施例同时涉及一种数据处理装置，一种计算设备，以及一种计算机可读存储介质，在下面的实施例中逐一进行详细说明。
参见图1，图1示出了根据本申请一个实施例提供的一种数据处理过程的***架构图。
目前的直播体系中，人气是用于对直播平台的直播间进行排名的重要指标。一般而言，直播间的人气越高，其排名越靠前，该直播间内的主播越有可能被用户观看。在人气确定过程中，使用的基础数据则是直播间的观看人数，精确判断直播间的观看用户是否存在刷量情况，并对存在刷量的直播间进行一定的惩处措施，对于维护直播平台生态有着重要的意义。
而目前判断直播间是否存在刷量情况，多是通过观看用户的心跳数据来实现，其中，心跳数据是指在客户端与心跳服务器之间定时通知对方自己状态的数据，按照一定的时间间隔发送，类似于心跳，故被称为心跳数据。
心跳服务器是指接收客户端发送的心跳数据的服务器，在直播场景下，心跳服务器可以基于接收的心跳数据统计观看直播间的当前观看人数。生成心跳数据的具体过程可以是：客户端接收用户发送的直播间观看请求；基于直播间观看请求生成直播间播放地址获取请求发送至调度服务器，由调度服务器基于播放地址获取请求返回播放地址至客户端；客户端定时基于播放地址生成心跳数据，并将其上报至心跳服务器；心跳服务器可以通过定时接收到的心跳数据确定客户端与服务器之间是否建立了传输连接，如，客户端是否在播放目标直播间的内容，并且，心跳服务器可以基于接收到的心跳数据统计当前观看目标直播间的用户的数量。
可见，目前直播的人数计算，一般都是播放器(客户端)定时向心跳服务器上报心跳数据，报告当前客户端正在有人观看。上报的心跳数据一般包括：直播间的房间号+播放地址+UID+用户IP+设备指纹+直播分区。心跳服务器接收到心跳数据后，会对直播间下的心跳数量进行汇总，判断在当前时间段下，有多个人上报心跳数据就有多少观看用户。
然而，目前除了上述生成心跳数据的方法外，一些非法用户为了增加直播间的观看人数，进而使直播间可以处于靠前的排名，往往会截取由调度服务器返回至客户端的播放地址，再基于截取的播放地址生成虚拟心跳数据，即采用各种刷量的方式增加直播间的观看人数。非法用户采用上述增加直播间观看人数的刷量方法，影响了直播平台生态，使直播平台无法确定直播间真实的观看人数，进而无法将真正优质的直播间推荐给用户观看，影响了观看直播间用户的体验。
为解决上述问题，许多直播平台设置了在客户端向心跳服务器上报心跳数据时，在心跳数据中增加UID(User Identification)字段，通过判断UID字段是否存在，判断是否为登录用户；若直播间未登录用户在观看用户总数中的比例较高，则确定直播间可能存在刷量行为；然而，此方法仍容易被非法用户破解，即非法用户随机生成UID，再基于UID生成心跳数据即可；若对每个心跳数据中的UID真实性进行验证，则在直播间观看人数较多时，服务器查询压力较大；并且非法用户还可随机破解真实用户的UID生成非真实用户观看对应的心跳数据。
因此，本申请实施例提供的数据处理方法，由心跳服务器接收历史心跳数据，其中，所述历史心跳数据中包含待验证用户的用户标识，基于所述用户标识获取所述待验证用户的用户画像及直播行为数据，根据所述用户画像确定所述待验证用户的第一刷量分值，并根据所述直播行为数据确定所述待验证用户的第二刷量分值，根据所述第一刷量分值和所述第二刷量分值确定所述待验证用户的刷量验证结果。
其中，用户画像包括但不限于用户等级、是否实名认证、账号绑定手机号码、设备指纹等；直播行为数据包括但不限于观看直播分类集中度、直播入口集中度、弹幕/送礼/评论/抽奖操作、单IP观看次数、观看IP区域分布、观看时长统计等。
可见，本申请实施例通过结合待验证用户的用户画像及其在观看直播过程中生成的直播行为数据，综合判断该待验证用户的刷量验证结果，从而更加精准地确定待验证用户是否为刷量用户，有利于提高判断待验证用户是否刷量的判断结果的准确率，进而有利于维护直播平台生态的稳定性。
参见图2，图2示出了根据本申请一个实施例提供的一种数据处理方法的流程图，包括以下步骤：
步骤202，接收历史心跳数据，其中，所述历史心跳数据中包含待验证用户的用户标识。
具体的，直播平台在运营过程中，为了将优质的直播间推荐给用户，提升用户观看体验，通常会基于直播间的观看人数对直播间进行排名；而统计直播间观看人数的方法通常为：客户端定时向心跳服务器上报心跳数据，一般上报的心跳数据中包含用户观看的直播间的直播间标识、直播间的播放地址以及用户标识；心跳服务器接收到心跳数据后，可以基于直播间标识对心跳数据进行汇总，计算当前每个直播间的观看人数，进而可以基于观看人数对直播间进行排序。
其中，心跳数据是指在客户端与心跳服务器之间定时通知对方当前设备状态的数据，通过定时向心跳服务器发送心跳数据可以确定客户端与心跳服务器之间持续建立的传输链接；在本申请实施例中，心跳数据可以用于统计观看目标直播间的观众人数，即心跳服务器在接收到心跳数据后，可以基于心跳数据中的直播间标识统计直播间当前的观看人数。
在实际应用中，心跳数据可以是真实用户观看直播间产生的心跳数据，即目标客户端定时向心跳服务器上报的心跳数据；例如，观众a基于客户端A观看直播，客户端基于用户的直播观看请求获取目标直播间的播放地址，并定时根据播放地址向心跳服务器上报心跳数据，从而使心跳服务器可以确定当前观众a正在观看目标直播间。
或者，心跳数据还可以是非法用户基于真实的播放地址生成的心跳数据或采用其他方式生成的心跳数据，具体的，非法用户截取返回至客户端的播放地址，并基于播放地址生成模拟心跳数据，例如，非法用户截取到观众a在观看目标直播间时，调度服务器返回至观众a所在客户端A的播放地址，基于播放地址生成模拟心跳数据，导致后续基于心跳数据统计直播间人数时得到的统计结果不真实。而为防止上述情况的发生，则需要对用户的真实性进行验证，从而实现防刷。
因此，本申请实施例可通过心跳服务器接收历史心跳数据，该历史心跳数据为当前时间之前一定时长内，心跳服务器接收的心跳数据，该历史心跳数据中包含待验证用户的用户标识，具体可以是待验证用户的用户身份字段，例如，用户身份ID、用户编号等等，从而可以根据该用户标识获取待验证用户的用户画像及直播行为数据，以根据用户画像和直播行为数据，预先对待验证用户的真实性进行综合验证，生成对应的刷量验证结果，便于在实际的直播场景中，可以根据预先生成的待验证用户的刷量验证结果对直播间的观看人数进行统计，以保证统计结果的准确性。
步骤204，基于所述用户标识获取所述待验证用户的用户画像及直播行为数据。
具体的，用户画像，即待验证用户的画像数据，具体为待验证用户的基础属性数据，包括但不限于用户等级、实名认证结果、账号绑定的手机号码、设备指纹等；直播行为数据，即待验证用户在观看直播过程中生成的相关行为数据，包括但不限于观看直播分类集中度、直播入口集中度、弹幕/送礼/评论/抽奖操作、单IP观看次数、观看IP区域分布、观看时长统计等。
其中，用户等级可以是直播平台根据用户的活跃度，对用户进行等级划分生成的结果。例如每天都登录直播平台的用户，会比只在直播平台注册账号而长时间未登录的用户的等级要高，用户等级越高，用户的可信度越高，其刷量的可能性则越低。
关于实名认证结果，由于目前直播平台普遍要求用户进行实名认证，直播平台的很多操作都与实名相绑定，例如，用户如果需要成为主播，则须进行实名认证。而对于刷量用户而言，即使拥有多个账号信息，但是实名认证只能使用一次，所以其他的账号都是处于未实名认证的状态，实名认证通过的用户，比未实名认证或实名认证未通过的用户的可信度高。
关于账号绑定的手机号码，用户申请账号时通常需要绑定手机号，特别是账号处于危险状态下，平台都要求用手机号码来进行验证。因此，账号绑定手机号码的用户，比未绑定手机号码的用户的可信度高。
关于设备指纹，对于直播观看设备，直播平台都可以根据用户的设备信息生成唯一的设备号，且是可以存储的，如果用户上报的设备指纹重复出现多次，则说明多个用户在复用同一个直播观看设备，其刷量概率较高。
关于观看直播分类集中度，在整个直播平台中包含多种直播类型的直播间，如游戏类型、电影类型、电商类型直播间等。对于一个用户而言，其观看的直播间的类型通常是有集中性的，会集中在固定的几种类型。而对于刷量用户而言，他们会承接各种主播的刷量请求，而不同主播的直播间，其直播类型不同，这样就会出现同一个用户，即同一个UID观看了十几个乃至更多类型直播间的现象。
关于直播入口集中度，直播入口是指观看某个直播间时，用于进入直播间的入口。一般会有以下几种直播入口：
(1)推荐页，推荐页用于为用户推荐直播间，推荐页展示的直播间是根据整个直播平台中，直播间的热度以及用户历史观看直播间的记录等信息，计算出来的一批用户可能感兴趣的直播间；
(2)分类排行榜，主播在开播的时候会选择自己的直播类型，在每个直播类型下，都是按照直播间热度进行排序，用户可以在分类排行榜中随机选择每个直播类型下的直播间进入；
(3)关注页，当用户对一个主播感兴趣的时候，会点击关注，因此，用户同样可以从关注页直接进入已关注主播的直播间；
(4)搜索页，用户可以在搜索页直接搜索直播间，然后点击搜索结果，进入直播间；
(5)直接进入，直接点击直播间的地址进入直播间。
关于弹幕/送礼/评论/抽奖操作，一个正常用户观看直播的时候，可能会产生发送弹幕、赠送礼物、发送评论，抽奖等行为，对于刷量用户而言，他们单纯的通过观看直播，产生心跳上报，进而产生人数，因此不需要参与上述行为。即使想参与上述行为，由于操作成本高，操作复杂，也很难模拟出来。
关于单IP观看次数，对于单个账户而言，同一个用户的IP观看的直播间的次数应该是有限的，如果单个用户IP，同一时间内观看了超过正常数量的直播间，则说明存在了刷量的行为。例如一个用户，用户IP为X，在同一时间观看的直播间为10次(直播间不去重，在一个直播间观看10次，即打开10个窗口观看同一个直播间)，这个数量已经远远超出了正常用户的频率。
关于观看IP区域分布，对于正常用户而言，观看直播，用户的IP地址应该是有限的。但是对于刷量用户而言，他们会利用一个账户观看多个直播间，且为了避开单个IP的限制，会购买多个服务器，每个服务器有不同的出口IP。因此，通过定位单个账号的观看IP的地址位置，即可确定其是否存在刷量现象。其中，地址位置定位通过GPS定位到省份-城市-运营商-小区，例如江苏-苏州-电信-XX小区。
关于观看时长统计，我们可以统计单个UID观看的直播间的时长。而对于刷量用户而言，他们会同时观看很多个直播间，将不同的直播间的观看时长进行累加。通过判断观看时长是否符合一个正常UID的行为。例如一个UID，一天观看了10个小时，我们认为是正常的。但是刷量用户会进入多个直播间，时长会累加，可能会观看10个直播间，一个直播间观看即使只有3个小时，也会有30个小时，一天也只有24小时，所以该UID存在刷量情况的概率相对较高。
获取待验证用户的用户画像和直播行为数据后，即可根据用户画像和直播行为数据进一步确定该待验证用户是否为刷量用户。
步骤206，根据所述用户画像确定所述待验证用户的第一刷量分值，并根据所述直播行为数据确定所述待验证用户的第二刷量分值。
具体的，第一刷量分值是根据待验证用户的用户画像确定出的刷量分值，第二刷量分值是根据待验证用户的直播行为数据确定出的刷量分值。
本申请实施例在获取待验证用户的用户画像及直播行为数据后，即可根据用户画像确定待验证用户的第一刷量分值，并根据直播行为数据确定待验证用户的第二刷量分值，以根据第一刷量分值和第二刷量分值综合确定待验证用户是否为刷量用户。
具体实施时，根据所述用户画像确定所述待验证用户的第一刷量分值，包括：
根据所述用户画像中包含的所述待验证用户的至少一个用户属性数据，确定所述待验证用户的至少一个第一刷量子分值；
根据所述第一刷量子分值确定所述待验证用户的第一刷量分值。
进一步的，根据所述第一刷量子分值确定所述待验证用户的第一刷量分值，包括：
对所述至少一个第一刷量子分值进行加和处理，生成所述待验证用户的第一刷量分值。
具体的，由于待验证用户的用户画像包括但不限于用户等级、实名认证结果、账号绑定的手机号码、设备指纹等用户属性数据，因此，可先根据每个用户属性数据确定待验证用户的第一刷量子分值，然后根据多个刷量子分值综合确定待验证用户的第一刷量分值。
其中，对于用户等级这一用户属性，根据用户等级对待验证用户进行分类，用户等级越高，待验证用户的可信度越高。假设有N1个用户等级，用户等级每增加一级，待验证用户的可信度增加m1分，因此，在用户等级这一用户属性下，用户的可信度，即UID可信度1＝N1*m1。
对于实名认证结果这一用户属性，实名认证通过，则待验证用户的可信度为a1分，未实名认证或实名认证未通过，则待验证用户的可信度为a2分，因此，在使命认证结果这一用户属性下，用户的可信度，即则UID可信度2＝a1或者a2。
对于账号绑定的手机号码这一用户属性，账号绑定手机号码，则待验证用户的可信度为b1分，未绑定手机号码，则待验证用户的可信度为b2，因此，在账号绑定的手机号码这一用户属性下，用户的可信度，即则UID可信度3＝b1或者b2。
对于设备指纹这一用户属性，设置预设设备指纹数为X1个，同一个UID在历史时间区间内使用不同设备的设备指纹个数为Y1，如果Y1<X1，则待验证用户的可信度，即则UID可信度4＝100，否则待验证用户的可信度，即则UID可信度4＝100-(Y1-X1)*c1，c1为预设参数。
实际应用中，可将各用户属性对应的UID可信度的相反数作为待验证用户的第一刷量子分值；因此，在计算获得待验证用户的至少一个UID可信度后，可将各UID可信度值的相反数进行加和处理，生成待验证用户的第一刷量分值。
或者，还可为不同用户属性设置不同的权重，以在计算获得不同用户属性分别对应的第一刷量子分值后，可基于各用户属性对应的权重，对各第一刷量子分值进行加权求和，生成待验证用户的第一刷量分值。
具体实施时，根据所述直播行为数据确定所述待验证用户的第二刷量分值，包括：
根据所述直播行为数据中包含的所述待验证用户的至少一个直播行为子数据，确定所述待验证用户的至少一个第二刷量子分值；
根据所述第二刷量子分值确定所述待验证用户的第二刷量分值。
进一步的，根据所述第二刷量子分值确定所述待验证用户的第二刷量分值，包括：
对所述至少一个第二刷量子分值进行加和处理，生成所述待验证用户的第二刷量分值。
具体的，由于待验证用户的直播行为数据包括但不限于观看直播分类集中度、直播入口集中度、弹幕/送礼/评论/抽奖操作、单IP观看次数、观看IP区域分布、观看时长统计等直播行为子数据，因此，可先根据每个直播行为子数据确定待验证用户的第二刷量子分值，然后根据多个刷量子分值综合确定待验证用户的第二刷量分值。
其中，对于观看直播分类集中度这一直播行为子数据，心跳服务器可对待验证用户在预设时间区间内上报的心跳数据进行汇总，获取到该待验证用户观看的各直播间分别对应的直播类型。假设直播类型的预设数量阈值为X2，对待验证用户在预设时间区间内观看的多个直播间所对应的直播类型进行汇总，得到的直播类型的数量为Y2，则若X2<Y2，则待验证用户的可信度，即则UID可信度5＝100，否则待验证用户的可信度，即则UID可信度5＝100-(Y2-X2)*c2，c2为预设参数。
对于直播入口集中度这一直播行为子数据，心跳服务器可对待验证用户在预设时间区间内上报的心跳数据进行汇总，获取到该待验证用户进入各直播间时的入口方式。假设待验证用户在预设时间区间内观看了X3个直播间，以直接进入的方式进入的直播间数量为Y3，则待验证用户的可信度，即则UID可信度6＝100-(Y3/X3)*c3，c3为预设参数。
对于弹幕/送礼/评论/抽奖操作这一直播行为子数据，心跳服务器可查询该待验证用户在预设时间区间内是否产生上述行为，产生的次数越多，可信度越高，每产生一次，待验证用户的可信度增加m2分，假设待验证用户在预设时间区间内产生N2次上述行为，则待验证用户的可信度，即则UID可信度7＝N2*m2。
对于单IP观看次数这一直播行为子数据，心跳服务器可判断待验证用户在预设时间区间内在通过一个IP观看的直播间数量。假设在预设时间区间内观看的预设直播间数量为X4，待验证用户实际观看的直播间数量为Y4，则如果Y4<X4，则待验证用户的可信度，即则UID可信度8＝100，否则待验证用户的可信度，即则UID可信度8＝100-(Y4-X4)*c4，c4为预设参数。
对于观看IP区域分布这一直播行为子数据，心跳服务器可对预设时间区间内待验证用户上报的IP进行解析，以确定IP所在位置。假设在预设时间区间内观看直播所使用不同IP的预设IP数量为X5，待验证用户实际直播所使用的不同IP的数量为Y5，则如果Y5<X5，则待验证用户的可信度，即则UID可信度9＝100，否则待验证用户的可信度，即则UID可信度9＝100-(Y5-X5)*c5，c5为预设参数。
对于观看时长统计这一直播行为子数据，由于待验证用户定时进行心跳数据的上报，因此，可判断单个UID在一个直播间内持续进行心跳数据上报的时间，以根据该时间确定待验证用户的直播观看时长，然后可计算预设时间区间内待验证用户观看不同直播间所对应的整体直播观看时长。若预设时间区间内，预设直播观看时长为X6，待验证用户在该预设时间区间内实际的直播观看时长为Y6，则如果Y6<X6，则待验证用户的可信度，即则UID可信度10＝100，否则待验证用户的可信度，即则UID可信度10＝100-(Y6-X6)*c6，c6为预设参数。
实际应用中，可将各直播行为子数据对应的UID可信度的相反数作为待验证用户的第二刷量子分值；因此，在计算获得待验证用户的至少一个UID可信度后，可将各UID可信度值的相反数进行加和处理，生成待验证用户的第二刷量分值。
或者，还可为不同直播行为子数据设置不同的权重，以在计算获得不同直播行为子数据分别对应的第二刷量子分值后，可基于各直播行为子数据对应的权重，对各第二刷量子分值进行加权求和，生成待验证用户的第二刷量分值。
步骤208，根据所述第一刷量分值和所述第二刷量分值确定所述待验证用户的刷量验证结果。
具体的，确定待验证用户的刷量验证结果，即待验证用户是否为刷量用户，或待验证用户是否存在刷量情况。
实际应用中，刷量验证结果即可以是：是刷量用户(存在刷量情况)或不是刷量用户(不存在刷量情况)。
在确定待验证用户的第一刷量分值和第二刷量分值后，即可基于第一刷量分值和第二刷量分值综合判断待验证用户是否为刷量用户。
具体实施时，根据所述第一刷量分值和所述第二刷量分值确定所述待验证用户的刷量验证结果，包括：
若所述第一刷量分值大于等于第一预设刷量阈值，则确定所述待验证用户的数量验证结果为存在刷量情况；
若所述第一刷量分值小于第二预设刷量阈值，则确定所述待验证用户的数量验证结果为不存在刷量情况；
若所述第一刷量分值小于所述第一预设刷量阈值且大于等于所述第二预设刷量阈值，则根据所述第二刷量分值确定所述待验证用户的刷量验证结果。
进一步的，根据所述第二刷量分值确定所述待验证用户的刷量验证结果，包括：
若所述第二刷量分值大于等于所述第一预设刷量阈值，则确定所述待验证用户的数量验证结果为存在刷量情况。
具体的，在确定待验证用户的第一刷量分值和第二刷量分值后，可先将第一刷量分值与第一预设刷量阈值进行比对，若第一刷量分值大于等于第一预设刷量阈值，则可直接确定待验证用户为刷量用户；若第一刷量分值小于第二预设刷量阈值，则可直接确定待验证用户不是刷量用户。
在第一刷量分值小于第一预设刷量阈值，且大于等于第二预设刷量阈值的情况下，可将待验证用户确定为疑似刷量用户，并且为保证确定的刷量验证结果的准确性，本申请实施例结合第二刷量分值对待验证用户的刷量验证结果进行进一步验证。具体可将第二刷量分值与第一预设刷量阈值进行比对，并在第二刷量分值大于等于第一预设刷量阈值的情况下，将待验证用户确定为刷量用户。
本申请实施例通过结合待验证用户的用户画像及其在观看直播过程中生成的直播行为数据，综合判断该待验证用户的刷量验证结果，从而更加精准地确定待验证用户是否为刷量用户，有利于提高判断待验证用户是否刷量的判断结果的准确率，进而有利于维护直播平台生态的稳定性。
另外，由于本申请实施例是根据用户画像和直播行为数据，预先对待验证用户的真实性进行综合验证，生成对应的刷量验证结果，因此，若确定所述待验证用户的刷量验证结果为存在刷量情况，则将所述待验证用户的用户标识添加至刷量用户列表，即该刷量用户列表用于存储刷量用户的用户标识(UID)，以便于在实际的直播场景中，可以根据预先生成的刷量用户列表，对直播间的观看人数进行统计，以保证统计结果的准确性。
具体实施时，对直播间的观看人数进行统计的过程，具体可通过以下方式实现：
获取目标心跳数据，其中，所述目标心跳数据中包含目标直播间的直播间标识及直播观看用户的用户标识；
基于所述直播观看用户的用户标识及所述刷量用户列表统计所述目标直播间的在线用户数量。
进一步的，基于所述直播观看用户的用户标识及所述刷量用户列表统计所述目标直播间的在线用户数量，包括：
将所述直播观看用户的用户标识与所述刷量用户列表中包含的用户标识进行比对；
在比对不一致的情况下，将所述直播观看用户确定为所述目标直播间的在线用户，以统计所述目标直播间的在线用户数量。
具体的，目标心跳数据，即用户在观看直播过程中实时上报的心跳数据，目标心跳数据中包含房间号+播放地址+UID+用户IP+设备指纹+直播类型等。心跳服务器接收到心跳数据后，可对直播间关联的心跳个数进行汇总，其中，在汇总的过程中，可基于心跳数据包含的UID及刷量用户列表确定该UID是否为刷量用户的UID，从而确定直播间内真实的观看人数。
具体可将心跳数据中包含的UID与刷量用户列表中包含的UID进行比对，以根据比对结果确定该UID对应的用户是否为刷量用户，其中，在比对一致的情况下，即刷量用户列表中包含该UID的情况下，即可确定该UID对应的用户为刷量用户，该用户即可不计算在直播间的观看人数中，否则可将其计算在观看人数中。
实际应用中，可按一定时间周期重复执行根据历史心跳数据确定待验证用户的数量验证结果的过程，以保证持续对刷量用户列表进行更新，从而保证直播间观看人数的统计结果的准确性。
本申请一个实施例实现了一种数据处理方法及装置，其中，所述数据处理方法应用于心跳服务器，通过接收历史心跳数据，基于历史心跳数据中包含的用户标识获取待验证用户的用户画像及直播行为数据，根据用户画像确定待验证用户的第一刷量分值，并根据直播行为数据确定待验证用户的第二刷量分值，根据第一刷量分值和第二刷量分值确定待验证用户的刷量验证结果。
本申请实施例通过结合待验证用户的用户画像及其在观看直播过程中生成的直播行为数据，综合判断该待验证用户的刷量验证结果，从而更加精准地确定待验证用户是否为刷量用户，有利于提高判断待验证用户是否刷量的判断结果的准确率，进而有利于维护直播平台生态的稳定性。
参见图3，以本申请实施例提供的所述数据处理方法在直播领域的防刷场景的应用为例，对所述数据处理方法进行进一步说明。其中，图3示出了本申请一个实施例提供的一种数据处理方法应用于直播领域的防刷场景的处理过程流程图，具体包括以下步骤：
步骤302，接收历史心跳数据，其中，历史心跳数据中包含待验证用户的用户标识。
步骤304，基于用户标识获取待验证用户的用户画像及直播行为数据。
步骤306，根据用户画像中包含的待验证用户的至少一个用户属性数据，确定待验证用户的至少一个第一刷量子分值。
步骤308，对至少一个第一刷量子分值进行加和处理，生成待验证用户的第一刷量分值。
步骤310，根据直播行为数据中包含的待验证用户的至少一个直播行为子数据，确定待验证用户的至少一个第二刷量子分值。
步骤312，对至少一个第二刷量子分值进行加和处理，生成待验证用户的第二刷量分值。
步骤314，判断第一刷量分值是否大于等于第一预设刷量阈值。
若否，执行步骤316；若是，执行步骤320。
步骤316，判断第一刷量分值是否小于第二预设刷量阈值。
若否，则执行步骤318；若是，则不做处理即可。
步骤318，判断第二刷量分值是否大于等于第一预设刷量阈值。
若是，则执行步骤320；若否，则不做处理即可。
步骤320，将待验证用户的用户标识添加至刷量用户列表。
本申请实施例通过结合待验证用户的用户画像及其在观看直播过程中生成的直播行为数据，综合判断该待验证用户的刷量验证结果，从而更加精准地确定待验证用户是否为刷量用户，有利于提高判断待验证用户是否刷量的判断结果的准确率，进而有利于维护直播平台生态的稳定性。
与上述方法实施例相对应，本申请还提供了数据处理装置实施例，图4示出了本申请一个实施例提供的一种数据处理装置的结构示意图。如图4所示，该装置包括：
接收模块402，被配置为接收历史心跳数据，其中，所述历史心跳数据中包含待验证用户的用户标识；
获取模块404，被配置为基于所述用户标识获取所述待验证用户的用户画像及直播行为数据；
第一确定模块406，被配置为根据所述用户画像确定所述待验证用户的第一刷量分值，并根据所述直播行为数据确定所述待验证用户的第二刷量分值；
第二确定模块408，被配置为根据所述第一刷量分值和所述第二刷量分值确定所述待验证用户的刷量验证结果。
可选地，所述第一确定模块406，进一步被配置为：
根据所述用户画像中包含的所述待验证用户的至少一个用户属性数据，确定所述待验证用户的至少一个第一刷量子分值；
根据所述第一刷量子分值确定所述待验证用户的第一刷量分值。
可选地，所述第一确定模块406，进一步被配置为：
对所述至少一个第一刷量子分值进行加和处理，生成所述待验证用户的第一刷量分值。
可选地，所述第一确定模块406，进一步被配置为：
根据所述直播行为数据中包含的所述待验证用户的至少一个直播行为子数据，确定所述待验证用户的至少一个第二刷量子分值；
根据所述第二刷量子分值确定所述待验证用户的第二刷量分值。
可选地，所述第一确定模块406，进一步被配置为：
对所述至少一个第二刷量子分值进行加和处理，生成所述待验证用户的第二刷量分值。
可选地，所述第二确定模块408，进一步被配置为：
若所述第一刷量分值大于等于第一预设刷量阈值，则确定所述待验证用户的数量验证结果为存在刷量情况；
若所述第一刷量分值小于第二预设刷量阈值，则确定所述待验证用户的数量验证结果为不存在刷量情况；
若所述第一刷量分值小于所述第一预设刷量阈值且大于等于所述第二预设刷量阈值，则根据所述第二刷量分值确定所述待验证用户的刷量验证结果。
可选地，所述第二确定模块408，进一步被配置为：
若所述第二刷量分值大于等于所述第一预设刷量阈值，则确定所述待验证用户的数量验证结果为存在刷量情况。
可选地，所述数据处理装置，还包括添加模块，被配置为：
若确定所述待验证用户的刷量验证结果为存在刷量情况，则将所述待验证用户的用户标识添加至刷量用户列表。
可选地，所述数据处理装置，还包括统计模块，被配置为：
获取目标心跳数据，其中，所述目标心跳数据中包含目标直播间的直播间标识及直播观看用户的用户标识；
基于所述直播观看用户的用户标识及所述刷量用户列表统计所述目标直播间的在线用户数量。
可选地，所述统计模块，进一步被配置为：
将所述直播观看用户的用户标识与所述刷量用户列表中包含的用户标识进行比对；
在比对不一致的情况下，将所述直播观看用户确定为所述目标直播间的在线用户，以统计所述目标直播间的在线用户数量。
可选地，所述用户画像为所述待验证用户的基础属性数据，包括用户等级、实名认证结果、账号绑定的手机号码、设备指纹；
所述直播行为数据为所述待验证用户在观看直播过程中生成的行为数据，包括观看直播分类集中度、直播入口集中度、弹幕/送礼/评论/抽奖操作、单IP观看次数、观看IP区域分布、观看时长统计。
上述为本实施例的一种数据处理装置的示意性方案。需要说明的是，该数据处理装置的技术方案与上述的数据处理方法的技术方案属于同一构思，数据处理装置的技术方案未详细描述的细节内容，均可以参见上述数据处理方法的技术方案的描述。
图5示出了根据本申请一个实施例提供的一种计算设备500的结构框图。该计算设备500的部件包括但不限于存储器510和处理器520。处理器520与存储器510通过总线530相连接，数据库550用于保存数据。
计算设备500还包括接入设备540，接入设备540使得计算设备500能够经由一个或多个网络560通信。这些网络的示例包括公用交换电话网(PSTN)、局域网(LAN)、广域网(WAN)、个域网(PAN)或诸如因特网的通信网络的组合。接入设备540可以包括有线或无线的任何类型的网络接口(例如，网络接口卡(NIC))中的一个或多个，诸如IEEE802.11无线局域网(WLAN)无线接口、全球微波互联接入(Wi-MAX)接口、以太网接口、通用串行总线(USB)接口、蜂窝网络接口、蓝牙接口、近场通信(NFC)接口，等等。
在本申请的一个实施例中，计算设备500的上述部件以及图5中未示出的其他部件也可以彼此相连接，例如通过总线。应当理解，图5所示的计算设备结构框图仅仅是出于示例的目的，而不是对本申请范围的限制。本领域技术人员可以根据需要，增添或替换其他部件。
计算设备500可以是任何类型的静止或移动计算设备，包括移动计算机或移动计算设备(例如，平板计算机、个人数字助理、膝上型计算机、笔记本计算机、上网本等)、移动电话(例如，智能手机)、可佩戴的计算设备(例如，智能手表、智能眼镜等)或其他类型的移动设备，或者诸如台式计算机或PC的静止计算设备。计算设备500还可以是移动式或静止式的服务器。
其中，处理器520用于执行如下计算机可执行指令，所述处理器用于执行所述计算机可执行指令，其中，所述处理器执行所述计算机可执行指令时实现所述数据处理方法的步骤。
上述为本实施例的一种计算设备的示意性方案。需要说明的是，该计算设备的技术方案与上述的数据处理方法的技术方案属于同一构思，计算设备的技术方案未详细描述的细节内容，均可以参见上述数据处理方法的技术方案的描述。
本申请一实施例还提供一种计算机可读存储介质，其存储有计算机可执行指令，该指令被处理器执行时实现所述数据处理方法的步骤。
上述为本实施例的一种计算机可读存储介质的示意性方案。需要说明的是，该存储介质的技术方案与上述的数据处理方法的技术方案属于同一构思，存储介质的技术方案未详细描述的细节内容，均可以参见上述数据处理方法的技术方案的描述。
上述对本申请特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。
所述计算机指令包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、电载波信号、电信信号以及软件分发介质等。需要说明的是，所述计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减，例如在某些司法管辖区，根据立法和专利实践，计算机可读介质不包括电载波信号和电信信号。
需要说明的是，对于前述的各方法实施例，为了简便描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请实施例并不受所描述的动作顺序的限制，因为依据本申请实施例，某些步骤可以采用其它顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定都是本申请实施例所必须的。
在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其它实施例的相关描述。
以上公开的本申请优选实施例只是用于帮助阐述本申请。可选实施例并没有详尽叙述所有的细节，也不限制该发明仅为所述的具体实施方式。显然，根据本申请实施例的内容，可作很多的修改和变化。本申请选取并具体描述这些实施例，是为了更好地解释本申请实施例的原理和实际应用，从而使所属技术领域技术人员能很好地理解和利用本申请。本申请仅受权利要求书及其全部范围和等效物的限制。

Claims (14)

1.一种数据处理方法，其特征在于，应用于心跳服务器，包括：
接收历史心跳数据，其中，所述历史心跳数据中包含待验证用户的用户标识；
基于所述用户标识获取所述待验证用户的用户画像及直播行为数据；
根据所述用户画像确定所述待验证用户的第一刷量分值，并根据所述直播行为数据确定所述待验证用户的第二刷量分值；
根据所述第一刷量分值和所述第二刷量分值确定所述待验证用户的刷量验证结果。
2.根据权利要求1所述的数据处理方法，其特征在于，所述根据所述用户画像确定所述待验证用户的第一刷量分值，包括：
根据所述用户画像中包含的所述待验证用户的至少一个用户属性数据，确定所述待验证用户的至少一个第一刷量子分值；
根据所述第一刷量子分值确定所述待验证用户的第一刷量分值。
3.根据权利要求2所述的数据处理方法，其特征在于，所述根据所述第一刷量子分值确定所述待验证用户的第一刷量分值，包括：
对所述至少一个第一刷量子分值进行加和处理，生成所述待验证用户的第一刷量分值。
4.根据权利要求1所述的数据处理方法，其特征在于，所述根据所述直播行为数据确定所述待验证用户的第二刷量分值，包括：
根据所述直播行为数据中包含的所述待验证用户的至少一个直播行为子数据，确定所述待验证用户的至少一个第二刷量子分值；
根据所述第二刷量子分值确定所述待验证用户的第二刷量分值。
5.根据权利要求4所述的数据处理方法，其特征在于，所述根据所述第二刷量子分值确定所述待验证用户的第二刷量分值，包括：
对所述至少一个第二刷量子分值进行加和处理，生成所述待验证用户的第二刷量分值。
6.根据权利要求1所述的数据处理方法，其特征在于，所述根据所述第一刷量分值和所述第二刷量分值确定所述待验证用户的刷量验证结果，包括：
若所述第一刷量分值大于等于第一预设刷量阈值，则确定所述待验证用户的数量验证结果为存在刷量情况；
若所述第一刷量分值小于第二预设刷量阈值，则确定所述待验证用户的数量验证结果为不存在刷量情况；
若所述第一刷量分值小于所述第一预设刷量阈值且大于等于所述第二预设刷量阈值，则根据所述第二刷量分值确定所述待验证用户的刷量验证结果。
7.根据权利要求6所述的数据处理方法，其特征在于，所述根据所述第二刷量分值确定所述待验证用户的刷量验证结果，包括：
若所述第二刷量分值大于等于所述第一预设刷量阈值，则确定所述待验证用户的数量验证结果为存在刷量情况。
8.根据权利要求1所述的数据处理方法，其特征在于，还包括：
若确定所述待验证用户的刷量验证结果为存在刷量情况，则将所述待验证用户的用户标识添加至刷量用户列表。
9.根据权利要求8所述的数据处理方法，其特征在于，还包括：
获取目标心跳数据，其中，所述目标心跳数据中包含目标直播间的直播间标识及直播观看用户的用户标识；
基于所述直播观看用户的用户标识及所述刷量用户列表统计所述目标直播间的在线用户数量。
10.根据权利要求9所述的数据处理方法，其特征在于，所述基于所述直播观看用户的用户标识及所述刷量用户列表统计所述目标直播间的在线用户数量，包括：
将所述直播观看用户的用户标识与所述刷量用户列表中包含的用户标识进行比对；
在比对不一致的情况下，将所述直播观看用户确定为所述目标直播间的在线用户，以统计所述目标直播间的在线用户数量。
11.根据权利要求1所述的数据处理方法，其特征在于，所述用户画像为所述待验证用户的基础属性数据，包括用户等级、实名认证结果、账号绑定的手机号码、设备指纹；
所述直播行为数据为所述待验证用户在观看直播过程中生成的行为数据，包括观看直播分类集中度、直播入口集中度、弹幕/送礼/评论/抽奖操作、单IP观看次数、观看IP区域分布、观看时长统计。
12.一种数据处理装置，其特征在于，应用于心跳服务器，包括：
接收模块，被配置为接收历史心跳数据，其中，所述历史心跳数据中包含待验证用户的用户标识；
获取模块，被配置为基于所述用户标识获取所述待验证用户的用户画像及直播行为数据；
第一确定模块，被配置为根据所述用户画像确定所述待验证用户的第一刷量分值，并根据所述直播行为数据确定所述待验证用户的第二刷量分值；
第二确定模块，被配置为根据所述第一刷量分值和所述第二刷量分值确定所述待验证用户的刷量验证结果。
13.一种计算设备，其特征在于，包括：
存储器和处理器；
所述存储器用于存储计算机可执行指令，所述处理器用于执行所述计算机可执行指令，其中，所述处理器执行所述计算机可执行指令时实现权利要求1-11任意一项所述的数据处理方法的步骤。
14.一种计算机可读存储介质，其特征在于，其存储有计算机指令，该指令被处理器执行时实现权利要求1-11任意一项所述的数据处理方法的步骤。
CN202210295349.7A 2022-03-24 2022-03-24 数据处理方法及装置 Pending CN114679600A (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN202210295349.7A CN114679600A (zh) 2022-03-24 2022-03-24 数据处理方法及装置
PCT/CN2022/143537 WO2023179162A1 (zh) 2022-03-24 2022-12-29 数据处理方法及装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210295349.7A CN114679600A (zh) 2022-03-24 2022-03-24 数据处理方法及装置

Publications (1)

Publication Number Publication Date
CN114679600A true CN114679600A (zh) 2022-06-28

Family

ID=82074543

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210295349.7A Pending CN114679600A (zh) 2022-03-24 2022-03-24 数据处理方法及装置

Country Status (2)

Country Link
CN (1) CN114679600A (zh)
WO (1) WO2023179162A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023179162A1 (zh) * 2022-03-24 2023-09-28 上海哔哩哔哩科技有限公司 数据处理方法及装置

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106937172A (zh) * 2017-03-23 2017-07-07 百度在线网络技术（北京）有限公司 基于人工智能的视频播放时的互动方法及装置
CN109561348A (zh) * 2018-12-27 2019-04-02 广州虎牙信息科技有限公司 一种基于直播的业务处理方法、装置、设备和存储介质
WO2020257991A1 (zh) * 2019-06-24 2020-12-30 深圳市欢太科技有限公司 用户识别方法及相关产品
CN112788351A (zh) * 2019-11-01 2021-05-11 武汉斗鱼鱼乐网络科技有限公司 一种目标直播间的识别方法、装置、设备和存储介质
CN112995689A (zh) * 2021-02-24 2021-06-18 上海哔哩哔哩科技有限公司 确定直播间刷量的方法及装置
CN113347497A (zh) * 2021-08-02 2021-09-03 武汉斗鱼鱼乐网络科技有限公司 目标用户识别方法、装置、电子设备以及存储介质
CN113766256A (zh) * 2021-02-09 2021-12-07 北京沃东天骏信息技术有限公司 一种直播风控方法和装置
CN113938318A (zh) * 2021-12-01 2022-01-14 上海哔哩哔哩科技有限公司 确定直播间刷量的方法及装置

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10009358B1 (en) * 2014-02-11 2018-06-26 DataVisor Inc. Graph based framework for detecting malicious or compromised accounts
CN106658096A (zh) * 2016-11-17 2017-05-10 百度在线网络技术（北京）有限公司 推送直播节目的方法和装置
CN107454441B (zh) * 2017-06-30 2019-12-03 武汉斗鱼网络科技有限公司 一种检测直播间刷人气行为的方法、直播平台服务器及计算机可读存储介质
CN109429082B (zh) * 2017-08-31 2020-10-16 武汉斗鱼网络科技有限公司 直播人气检测方法、存储介质、电子设备及***
CN108390883B (zh) * 2018-02-28 2020-08-04 武汉斗鱼网络科技有限公司 刷人气用户的识别方法、装置及终端设备
CN109714636B (zh) * 2018-12-21 2021-04-23 武汉瓯越网视有限公司 一种用户识别方法、装置、设备及介质
CN114679600A (zh) * 2022-03-24 2022-06-28 上海哔哩哔哩科技有限公司 数据处理方法及装置

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106937172A (zh) * 2017-03-23 2017-07-07 百度在线网络技术（北京）有限公司 基于人工智能的视频播放时的互动方法及装置
CN109561348A (zh) * 2018-12-27 2019-04-02 广州虎牙信息科技有限公司 一种基于直播的业务处理方法、装置、设备和存储介质
WO2020257991A1 (zh) * 2019-06-24 2020-12-30 深圳市欢太科技有限公司 用户识别方法及相关产品
CN112788351A (zh) * 2019-11-01 2021-05-11 武汉斗鱼鱼乐网络科技有限公司 一种目标直播间的识别方法、装置、设备和存储介质
CN113766256A (zh) * 2021-02-09 2021-12-07 北京沃东天骏信息技术有限公司 一种直播风控方法和装置
CN112995689A (zh) * 2021-02-24 2021-06-18 上海哔哩哔哩科技有限公司 确定直播间刷量的方法及装置
CN113347497A (zh) * 2021-08-02 2021-09-03 武汉斗鱼鱼乐网络科技有限公司 目标用户识别方法、装置、电子设备以及存储介质
CN113938318A (zh) * 2021-12-01 2022-01-14 上海哔哩哔哩科技有限公司 确定直播间刷量的方法及装置

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
龚俭等: "《计算机网络安全导论（第3版）》", 南京：东南大学出版社, pages: 152 - 154 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023179162A1 (zh) * 2022-03-24 2023-09-28 上海哔哩哔哩科技有限公司 数据处理方法及装置

Also Published As

Publication number Publication date
WO2023179162A1 (zh) 2023-09-28

Similar Documents

Publication Publication Date Title
CN103620585B (zh) 虚拟身份管理器
CN103649981B (zh) 用于输送目标内容的方法和装置
US10580038B2 (en) Systems and methods for leveraging social queuing to identify and prevent ticket purchaser simulation
Ciszkowski et al. Towards quality of experience-based reputation models for future web service provisioning
CN110602514B (zh) 一种直播频道的推荐方法、装置、电子设备及存储介质
CN104836781A (zh) 区分访问用户身份的方法及装置
CN107493326B (zh) 网络投票处理方法、装置、服务器及计算机可读存储介质
CN110929086A (zh) 一种音视频推荐方法、装置及存储介质
CN113535991B (zh) 一种多媒体资源推荐方法、装置、电子设备及存储介质
CN111522724B (zh) 异常账号的确定方法、装置、服务器及存储介质
KR20180114856A (ko) 뮤지션 컨텐츠 모니터링 장치 및 방법
US20230325878A1 (en) Systems and methods for leveraging social queuing to simulate ticket purchaser behavior
Kolomeets et al. Analysis of the malicious bots market
WO2023179162A1 (zh) 数据处理方法及装置
Kigerl Behind the scenes of the underworld: hierarchical clustering of two leaked carding forum databases
CN109829593B (zh) 目标对象的信用度确定方法、装置、存储介质及电子装置
Elmisery et al. Agent based middleware for maintaining user privacy in IPTV recommender services
CN109062945B (zh) 一种社交网络的信息推荐方法、装置及***
Allahbakhsh et al. Harnessing implicit teamwork knowledge to improve quality in crowdsourcing processes
CN112995686B (zh) 数据处理方法、直播方法、鉴权服务器及直播数据服务器
CN114466214B (zh) 直播间人数统计方法及装置
KR20130082788A (ko) 선택적 온라인 매칭 서비스 제공 시스템 및 제공 방법
JP6122138B2 (ja) インタラクションの類似性によってリンクされるコミュニティの間の情報拡散を最適化するための方法およびデバイス
Phoomvuthisarn A survey study on reputation-based trust mechanisms in service-oriented computing
Li et al. YANA: an efficient privacy-preserving recommender system for online social communities

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination