CN109858919B - 异常账号的确定方法及装置、在线下单方法及装置 - Google Patents
异常账号的确定方法及装置、在线下单方法及装置 Download PDFInfo
- Publication number
- CN109858919B CN109858919B CN201711209032.2A CN201711209032A CN109858919B CN 109858919 B CN109858919 B CN 109858919B CN 201711209032 A CN201711209032 A CN 201711209032A CN 109858919 B CN109858919 B CN 109858919B
- Authority
- CN
- China
- Prior art keywords
- account
- accounts
- association
- same
- real
- 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.)
- Active
Links
- 230000002159 abnormal effect Effects 0.000 title claims abstract description 120
- 238000000034 method Methods 0.000 title claims abstract description 59
- 230000006399 behavior Effects 0.000 claims description 67
- 238000004891 communication Methods 0.000 claims description 8
- 230000000694 effects Effects 0.000 claims description 8
- 230000004044 response Effects 0.000 claims description 6
- 230000000875 corresponding effect Effects 0.000 claims 14
- 230000002596 correlated effect Effects 0.000 claims 4
- 241000283690 Bos taurus Species 0.000 abstract description 29
- 230000002265 prevention Effects 0.000 abstract description 6
- 238000010586 diagram Methods 0.000 description 8
- 238000003672 processing method Methods 0.000 description 8
- 238000011156 evaluation Methods 0.000 description 3
- 238000012804 iterative process Methods 0.000 description 3
- 230000005856 abnormality Effects 0.000 description 1
- 238000004458 analytical method Methods 0.000 description 1
- 244000144980 herd Species 0.000 description 1
- 238000007477 logistic regression Methods 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 230000000750 progressive effect Effects 0.000 description 1
- 238000011160 research Methods 0.000 description 1
- 238000012549 training Methods 0.000 description 1
Images
Landscapes
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
本申请提供了异常账号的确定方法及装置、在线下单方法及装置，异常账号的确定方法包括：获取待确定账号之间的历史关联分值和实时关联分值；将所述历史关联分值和实时关联分值符合预设关联阈值的待确定账号，划分为同一个关联账号组；参考所述关联账号组内账号的正常账号概率，确定所述关联账号组内的账号是否为异常账号。采用本申请实施例的方法或装置，可以结合实际的业务，从下单金额，下单的产品个数，下单涉及的用户个数等方面进行基于团伙的黄牛防控，等等。
Description
技术领域
本申请涉及互联网数据处理技术领域，特别涉及一种异常账号的确定方法及装置，一种在线下单方法及装置。
背景技术
目前，在互联网越来越发达的今天，越来越多的用户采用网络购买日常用品、通讯器材等各种物品。而在一些节日期间，很多电商平台可能会推出不少优惠的在线产品供用户选购，在这种情况下，会有一些用户采用自己的账号对优惠力度大的在线产品进行抢购，例如，将优惠力度大的在线产品抢购之后再高价卖出，从中谋取不正当的利益。
在实际应用中，为了防止一些用户的账号完成下单，现有技术可以采用基于人机行为的防控方式来拒绝这一类的用户账号的下单行为。例如，可以通过是否接收到大并发的下单请求来判断当前下单的行为是否为机器行为，如果接收到大并发的下单请求就是机器行为，从而防止某些用户通过软件进行优惠产品的抢购。
发明内容
发明人在研究过程中发现，在实际应用中，优化过的软件也不需要每一次下单都会产生大并发的网络请求，仅仅通过是否接收到大并发的下单请求来判断是否为机器行为，并不能完全覆盖到全部的机器行为，不能准确地识别出全部的异常账号。并且，有些异常抢购的用户并不会采用软件来集中下单，因此，基于人机行为的防控方式不仅无法有效防止现有技术中异常下单的行为，还会因为对于正常下单的用户而言，其快速点击鼠标发送请求也容易被误判为异常的抢购行为，所以给正常下单的用户还会造成不好的用户体验。
基于此，本申请提供了一种异常账号的确定方法以及一种在线下单方法，用以采用。
本申请还提供了一种异常账号的确定装置以及一种在线下单装置，用以保证上述方法在实际中的实现及应用。
为了解决上述问题，本申请公开了一种异常账号的确定方法，包括：
获取待确定账号之间的历史关联分值和实时关联分值；
将所述历史关联分值和实时关联分值符合预设关联阈值的待确定账号，划分为同一个关联账号组；
参考所述关联账号组内账号的正常账号概率，确定所述关联账号组内的账号是否为异常账号。
其中，所述获取各待确定账号之间的历史关联分值，包括：
获取各待确定账号在互联网上对应的历史用户行为，所述历史用户行为包括：登录、注册、认证、浏览、下单和/或售后；
依据所述历史用户行为提取所述各待确定账号的历史关联特征，所述历史关联特征包括：采用同一个联系方式注册的同注册信息、采用同一个设备登录的同设备信息、或者同一个IP地址的同地址信息；
依据所述历史关联特征从多个待确定账号中，分别确定属于同一个用户的多个待确定账号，作为同用户账号；
将所述同用户账号作为正样本，其他非同用户账号作为负样本，通过回归模型计算得到任意两个待确定账号之间的历史关联分值。
其中，所述获取各待确定账号之间的实时关联分值，包括：
获取各待确定账号在互联网上对应的实时用户行为，所述实时用户行为包括：登录、注册、认证、浏览、下单和/或售后；
依据所述实时用户行为提取所述各待确定账号的实时关联特征，所述实时关联特征包括：采用同一个联系方式注册的同注册信息、采用同一个设备登录的同设备信息、或者同一个IP地址的同地址信息；
依据所述实时关联特征从多个待确定账号中，分别确定属于同一个用户的多个待确定账号，作为同用户账号；
将所述同用户账号作为正样本，其他非同用户账号作为负样本，通过回归模型计算得到任意两个待确定账号之间的实时关联分值。
其中，依据将所述历史关联程度和实时关联程度符合预设关联阈值的各待确定账号，划分为同一个关联账号组，包括：
按照所述历史关联分值或实时关联分值越高则目标关联分值越高的原则，确定所述各待确定账号分别与其他账号之间的目标关联分值；
判断各待确定账号分别与其他账号的目标关联分值是否大于预设分值阈值，如果是，则将该待确定账号与相对应的其他账号建立关联；
将各待确定账号及其关联的其他账号，以及与关联的其他账号具有关联的关联账号，划分为同一个关联账号组。
其中，所述参考所述关联账号组内各账号的正常账号概率，确定所述关联账号组内的账号是否为异常账号，包括：
依据所述关联账号组内各账号的活跃度、消费频率和消费金额，计算各账号的正常账号概率；
针对关联账号组内的各账号，以任一账号为当前账号，确定该当前账号与其相邻的关联账号之间关联分值最大的目标账号；
判断所述目标账号是否可以替换所述当前账号，如果是，则将所述当前账号替换为所述目标账号；
如果否，则获取下一个未判断过的账号为当前账号，执行所述定该当前账号与其相邻的关联账号之间关联分值最大的目标账号，直至所述关联账号组内的各账号都判断完毕，或者，所述关联账号组内没有账号可被替换；
依据所述关联账号组中相同账号的个数，确定该关联账号组内的账号是否为异常账号。
其中，所述判断所述目标账号是否可以替换所述当前账号，包括：
判断该当前账号与目标账号之间的关联分值，与，该目标账号的正常账号概率相除的商，是否大于预设替换阈值。
其中，所述依据所述关联账号组中相同账号的个数，确定该关联账号组内的账号是否为异常账号，包括：
判断依据所述关联账号组内相同账号的个数是否大于预设个数阈值，如果是，则将该关联账号组内的各账号确定为异常账号；如果否，则将所述关联账号组内的各账号确定为正常账号。
其中，所述方法还包括：
向所述异常账号发送下单限制指令，所述下单限制指令用于提示所述异常账号的用户其账号不允许下单。
本申请还提供了一种在线下单方法，包括：
接收第一客户端发送的第一下单请求，以及，第二客户端发送的第二下单请求；
获取所述第一下单请求对应的第一账号的历史关联程度和实时关联程度，以及，所述第二下单请求对应的第二账号的历史关联程度和实时关联程度；
判断所述第一账号和第二账号的历史关联程度和实时关联程度，是否符合预设关联阈值，如果符合，则将所述第一账号和第二账号加入关联账号组，并参考所述第一账号和第二账号的正常账号概率，确定所述关联账号组内的账号是否为异常账号，如果是异常账号，则拒绝所述第一下单请求和所述第二下单请求；
如果不是异常账号，或者不符合预设关联阈值，则响应于所述第一下单请求和所述第二下单请求执行所述第一账号的下单操作和所述第二账号的下单操作。
本申请还提供了一种在线下单方法，包括：
第一客户端向服务器第一下单请求，以及，第二客户端向服务器发送第二下单请求；
所述第一客户端接收服务器发送的下单限制指令，所述下单限制指令用于提示所述第一客户端对应的第一账号不允许下单；
所述第二客户端执行对应的第二账号的下单操作。
本申请还提供了一种异常账号的确定装置，包括：
处理器，用于获取待确定账号之间的历史关联分值和实时关联分值；将所述历史关联分值和实时关联分值符合预设关联阈值的待确定账号，划分为同一个关联账号组；参考所述关联账号组内账号的正常账号概率，确定所述关联账号组内的账号是否为异常账号；
显示器，用于将所述异常账号进行显示。
其中，所述处理器用于获取各待确定账号之间的历史关联分值，包括：
获取各待确定账号在互联网上对应的历史用户行为，所述历史用户行为包括：登录、注册、认证、浏览、下单和/或售后；
依据所述历史用户行为提取所述各待确定账号的历史关联特征，所述历史关联特征包括：采用同一个联系方式注册的同注册信息、采用同一个设备登录的同设备信息、或者同一个IP地址的同地址信息；
依据所述历史关联特征从多个待确定账号中，分别确定属于同一个用户的多个待确定账号，作为同用户账号；
将所述同用户账号作为正样本，其他非同用户账号作为负样本，通过回归模型计算得到任意两个待确定账号之间的历史关联分值。
其中，所述处理器用于获取各待确定账号之间的实时关联分值，包括：
获取各待确定账号在互联网上对应的实时用户行为，所述实时用户行为包括：登录、注册、认证、浏览、下单和/或售后；
依据所述实时用户行为提取所述各待确定账号的实时关联特征，所述实时关联特征包括：采用同一个联系方式注册的同注册信息、采用同一个设备登录的同设备信息、或者同一个IP地址的同地址信息；
依据所述实时关联特征从多个待确定账号中，分别确定属于同一个用户的多个待确定账号，作为同用户账号；
将所述同用户账号作为正样本，其他非同用户账号作为负样本，通过回归模型计算得到任意两个待确定账号之间的实时关联分值。
其中，所述处理器用于依据将所述历史关联程度和实时关联程度符合预设关联阈值的各待确定账号，划分为同一个关联账号组，包括：
按照所述历史关联分值或实时关联分值越高则目标关联分值越高的原则，确定所述各待确定账号分别与其他账号之间的目标关联分值；
判断各待确定账号分别与其他账号的目标关联分值是否大于预设分值阈值，如果是，则将该待确定账号与相对应的其他账号建立关联；
将各待确定账号及其关联的其他账号，以及与关联的其他账号具有关联的关联账号，划分为同一个关联账号组。
其中，所述处理器用于参考所述关联账号组内各账号的正常账号概率，确定所述关联账号组内的账号是否为异常账号，包括：
依据所述关联账号组内各账号的活跃度、消费频率和消费金额，计算各账号的正常账号概率；
针对关联账号组内的各账号，以任一账号为当前账号，确定该当前账号与其相邻的关联账号之间关联分值最大的目标账号；
判断所述目标账号是否可以替换所述当前账号，如果是，则将所述当前账号替换为所述目标账号；
如果否，则获取下一个未判断过的账号为当前账号，执行所述定该当前账号与其相邻的关联账号之间关联分值最大的目标账号，直至所述关联账号组内的各账号都判断完毕，或者，所述关联账号组内没有账号可被替换；
依据所述关联账号组中相同账号的个数，确定该关联账号组内的账号是否为异常账号。
其中，所述处理器用于判断所述目标账号是否可以替换所述当前账号，包括：
判断该当前账号与目标账号之间的关联分值，与，该目标账号的正常账号概率相除的商，是否大于预设替换阈值。
其中，所述处理器用于依据所述关联账号组中相同账号的个数，确定该关联账号组内的账号是否为异常账号，包括：
判断依据所述关联账号组内相同账号的个数是否大于预设个数阈值，如果是，则将该关联账号组内的各账号确定为异常账号；如果否，则将所述关联账号组内的各账号确定为正常账号。
其中，所述处理器还用于：
向所述异常账号发送下单限制指令，所述下单限制指令用于提示所述异常账号的用户其账号不允许下单。
本申请还提供了一种在线下单装置，包括：
通信接口，用于接收第一客户端发送的第一下单请求，以及，第二客户端发送的第二下单请求；
处理器，用于获取所述第一下单请求对应的第一账号的历史关联程度和实时关联程度，以及，所述第二下单请求对应的第二账号的历史关联程度和实时关联程度；判断所述第一账号和第二账号的历史关联程度和实时关联程度，是否符合预设关联阈值，如果符合，则将所述第一账号和第二账号加入关联账号组，并参考所述第一账号和第二账号的正常账号概率，确定所述关联账号组内的账号是否为异常账号，如果是异常账号，则拒绝所述第一下单请求和所述第二下单请求；如果不是异常账号，或者不符合预设关联阈值，则响应于所述第一下单请求和所述第二下单请求执行所述第一账号的下单操作和所述第二账号的下单操作。
本申请还提供了一种数据处理方法，包括：
获取与待分析账号存在关联关系的关联账号；
确定超过预设数量的关联账号为异常账号；
确定所述待分析账号为异常账号。
其中，获取与待分析账号存在关联关系的关联账号包括：
获取待分析账号和关联账号之间的关联分值，其中，所述关联分值用于表示一个账号和另一个账号之间的关系程度；
获取关联分值超过预设阈值的账号。
本申请还提供了一种数据处理方法，包括：
获取与待分析账号存在关联关系的关联账号；
确定超过预设数量的关联账号为正常账号；
确定所述待分析账号为正常账号。
本申请还提供了一种数据处理方法，包括：
获取与待分析账号存在关联关系的关联账号；
确定所述关联账号超过预设数量；
确定所述待分析账号为疑似异常账号。
本申请还提供了一种数据处理方法，包括：
获取与待分析账号存在关联关系的关联账号；
确定所述关联账号超过预设数量；
确定所述待分析账号为异常账号。
与现有技术相比，本申请包括以下优点：
在本申请实施例中，通过账号之间的历史关联分值和实时关联分值，可以确定哪些账号是异常账号(黄牛账号等)，以及异常账号所在的关联账号组(黄牛账号所属的黄牛团伙等)，并且可以从数据库中查询到某个黄牛团伙的已下单次数、已购买金额、已购买用户数等，在实际应用中可以只允许一个关联账号组中的某一个账号下单(例如第一个账号)，即仅允许黄牛团伙的第一个用户购买，而对该接下来下单的用户进行拦截。亦或者，结合实际的业务，从下单金额，下单的产品个数，下单涉及的用户个数等方面进行基于团伙的黄牛防控，等等。
此外，服务器在接收到多个账号提交的下单请求的时候，可以判断这多个账号是否为异常账号例如黄牛账号等，并可以正常执行用户的正常账号的下单操作，并且拒绝黄牛账号的下单请求，较为准确和精确的对黄牛团伙进行防控。
当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。
附图说明
为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
图1是本申请的异常账号的确定方法实施例的示例性流程图；
图2是本申请的账号之间的历史关联分值的示例性示意图；
图3是本申请的一个关联账号组的示例性示意图；
图4a和图4b是本申请的迭代过程和迭代结果的示例性示意图；
图5是本申请的关联账号组中异常账号的判断结果的示意图；
图6是本申请的在线下单方法实施例的示例性流程图；
图7是本申请的异常账号的确定装置实施例的结构框图；
图8是本申请的在线下单装置实施例的结构框图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
参考图1，示出了本申请一种异常账号的确定方法实施例的流程图，本实施例可以包括以下步骤：
步骤101：获取各待确定账号之间的历史关联分值和实时关联分值。
在本实施例中，账号即是用户在电商平台上注册时使用的标识ID，用户在一个电商平台上注册的账号能够在该电商平台内唯一标识一个用户。
两个账号之间的历史关联分值，例如，可以在0-1之间连续，并且分值越高表示两个账号之间的历史关联越紧密，即两个账号相对应的用户行为或账号信息等在该电商平台上的历史关联程度越高。在实际应用中，如果用户在电商平台上注册了账号，由于用户使用的设备成本、时间成本的各类原因，两个账号相对应的用户行为或者账号信息等之间会产生各种关联。例如，两个账号都采用同一个IP地址进行注册，或者，两个账号都采用同一个IP地址并且在同一个时段登陆电商平台，或者，两个账号都采用同一个手机号码作为收货信息，等等。
具体的，获取各待确定账号之间的历史关联分值的过程可以包括步骤A1～步骤A4：
步骤A1：获取各待确定账号在互联网上对应的历史用户行为，所述历史用户行为包括：登录、注册、认证、浏览、下单和/或售后。
为了确定电商平台上各个账号之间的关联，可以通过对各个账号的在该电商平台上的生命周期中各个节点中的信息，确定各个账号之间的历史关联程度。其中，生命周期可以包括如下节点：注册、认证、登录、浏览、购买和售后等，注册即是用户在电商平台上为了将自己区别于他人而首次设立自己的账号；认证即是电商平台的服务器对用户设立的账号是否与他人一样进行验证；登录即是用户注册自己的账号之后在该电商平台上输入账号和对应的密码，从而可以了解自己的购物详情；浏览即是用户登录之后在该电商平台上观看了哪些在线产品；购买即是用户采用自己的账号成功下单了哪些在线产品；售后即是用户的订单交易完成之后，用户是否请求了在线产品的售后服务。
步骤A2：依据所述历史用户行为提取各待确定账号的历史关联特征，所述历史关联特征包括：采用同一个联系方式注册的同注册信息、采用同一个设备登录的同设备信息、和/或同一个IP地址的同地址信息。
因此，通过记录各个账号在上述生命周期内各个节点的用户行为，可以提取到各个账号之间的关联特征，例如，不同的账号采用同一个IP地址进行注册，不同账号采用同一个设备登陆，采用同一个联系方式注册的同注册信息，等等。
步骤A3：从多个待确定账号中，分别确定属于同一个用户的多个待确定账号，作为同用户账号。
在实际应用中，对于上述用户行为，可以预先确定出属于同一个用户的不同账号有哪些，这些同用户账号是已知的，例如，用户本人向电商平台确认过哪两个或者哪几个账号都是本人的账号，等等。
步骤A4：将所述同用户账号作为正样本，多个待确定账号中的其他非同用户账号作为负样本，依据所述历史关联特征和回归模型计算得到任意两个待确定账号之间的历史关联分值。
在本步骤中，选择已知的同一人的不同账号为正样本，多个待确定账号中其余的、与该同用户账号不同的其他账号作为负样本，依据关联特征和回归模型来计算得到两两账号之间的历史关联分值。通过回归模型计算第i个账号与第j个账号之间的历史关联分值的方式可以如公式(一)所示：
rscore_hisij＝1/(1+exp(-(w1*a1+w1*a2+...+wn*an))) (一)
其中：wn为第i个账号与第j个账号之间的第n个变量的权重，通过逻辑回归训练得到；an为第n个同介质是否产生关联，1表示第i个账号和第j个账号在当前介质上有关联，0表示第i个账号和第j个账号在当前介质上无关联。其中，同介质可以包括：同IP登录的同地址信息、同一个手机号码注册、采用同一个设备登录的同设备信息，等等。其中，n等于第i个账号和第j个账号存在关联的同介质的总个数，例如，第i个账号和第j个账号在同IP登录的同地址信息和同一个手机号码注册的两个介质上存在关联，则n等于2，a1、a2分别为同一个联系方式注册的同注册信息的个数、以及同一个IP地址的同地址信息的个数，则w1、w2分别为a1、a2的权重，可以由本领域技术人员预先设置。例如，同一个手机作为收货信息相比于同一个IP地址登陆的同地址信息，前者更有可能是同一个用户的不同账号，而后者涉及的不同账号可能只是同小区的不同用户，因此本领域技术人员可以为前者设置更大的权重。
在一个具体的示例性实施例中，得到关于账号A、账号B和账号C之间的历史关联分值可以参考图2所示，在图2中，账号A与账号C之间的历史关联分值为0.5，账号A和账号B之间的历史关联分值为0.9，因为0.5小于0.9，所以账号A和账号C之间的历史关联程度，比账号A和账号C之间的历史关联程度较低。此外，在账号B和账号C之间没有连线，表示账号B和账号对应的用户行为或者账号信息等之间不存在历史关联。当然，图2中的具体数值为一种示例性的数据，不应将其理解为本申请的限定。
与历史关联分值不同的是，两个账号之间的实时关联分值也可以在0-1之间连续，并且分值越高表示两个账号之间用户行为或账号信息等的实时关联程度越高。因为在实际应用中，有些用户的多个账号虽然都是异常的，但是在其下单之前，并没有历史关联，因此，在各个账号进行下单的当前时刻，也可以实时计算各个账号在下单时刻之间的实时关联分值，来确定各个账号之间的用户行为或账号信息在当前时刻是否存在关联。
具体的，计算各待确定账号之间的实时关联分值具体可以包括步骤B1～步骤B4：
步骤B1：获取各待确定账号在互联网上对应的实时用户行为，所述实时用户行为包括：登录、注册、认证、浏览、下单和/或售后；
在本步骤中，需要获取的是当前时刻下，各个账号在电商平台上对应的实时用户行为，其他实现过程与步骤A1类似，在此不再赘述。
步骤B2：依据所述实时用户行为提取所述各待确定账号的实时关联特征，所述实时关联特征包括：采用同一个联系方式注册的同注册信息、采用同一个设备登录的同设备信息、和/或同一个IP地址的同地址信息；
在本步骤中，再依据步骤B1中的实时用户行为来提取各个账号之间的实时关联特征，其中，关联特征可以参考步骤B2的介绍，在此不再赘述。
步骤B3：从多个待确定账号中，分别确定属于同一个用户的多个待确定账号，作为同用户账号。
预先确定出属于同一个用户的不同账号有哪些，这些同用户账号与是已知的。具体可以参考步骤A3的介绍。
步骤B4：将所述同用户账号作为正样本，多个待确定账号中的其他非同用户账号作为负样本，依据所述实时关联特征和回归模型计算得到任意两个待确定账号之间的实时关联分值。
在本步骤中，选择已知的同一人的不同账号为正样本，多个待确定账号中其余的、与该同用户账号不同的其他账号作为负样本，依据实时关联特征和回归模型来计算得到两两账号之间的实时关联分值。
通过回归模型计算第i个账号与第j个账号之间的实时关联分值的方式可以如公式(二)所示：
rscore_recentij＝1-exp(-(w1*a1+w1*a2+...+wn*an)) (二)
其中：wn为第i个账号与第j个账号之间的第n个变量的权重；an为第n个同介质是否产生关联，1表示第i个账号和第j个账号在当前介质上有关联，0表示第i个账号和第j个账号在当前介质上无关联。
步骤102：将所述历史关联分值和实时关联分值符合预设关联阈值的各待确定账号，划分为同一个关联账号组。
在得到各个账号之间的历史关联分值和实时关联分值之后，可以根据历史关联分值和实时关联分值来预先设置一个关联阈值，并将历史关联分值和实时关联分值符合该预设关联阈值的多个账号，划分为同一个关联账号组。
具体的，步骤102可以包括步骤C1～步骤C4：
步骤C1：按照所述历史关联分值或实时关联分值越高则目标关联分值越高的原则，确定所述各待确定账号与其他账号的目标关联分值。
在得到两两账号之间的历史关联分值或实时关联分值之后，可以计算两两账号之间的目标关联分值，具体可以采用如下所示的公式(三)进行计算：
rscore_totalij＝1-exp(-rscore_hisij-rscore_recij) (三)
其中，目标关联分值可以采用将历史关联分值和实时关联分值相加并进行归一化的方式得到。
步骤C2：判断各待确定账号与其他账号的目标关联分值是否大于预设分值阈值，如果是，则进入步骤C3。
接着，得到目标关联分值之后，可以将目标关联分值与预设分值阈值相比较，例如，可以将预设分值阈值设置为0.5，则如果两个账号之间的目标关联分值大于0.5，就将这两个账号建立关联，以便将这两个账号划分至同一个关联账号组中。当然，预设分值阈值的大小可以由本领域技术人员自主设置。
步骤C3：将该待确定账号与相对应的其他账号建立关联。
具体的，在实际应用中，可以通过将待确定账号和相对于的其他账号设置相同的标识，来建立该待确定账号与相对应的其他账号之间的关联，例如，将有关联的各个账号都设置“1”的标识，而对于另外一组存在关联的各个账号则可以设置“2”的标识，等等。当然，也可以采用树结构来实现同一个账号组之间各个账号的关联。
步骤C4：将各待确定账号和与该待确定账号关联的其他账号，以及与其他账号具有关联的关联账号，划分为同一个关联账号组。
具体的，参考图3所示，为一个采用树结构来实现关联账号组中正好之间的关联的示例性示意图，关联账号组的各个关联账号都可以采用树中的一个节点来表示，各个节点之间如果有关联就会有连线，例如，账号“L＝1”与账号“L＝2”有关联，则账号“L＝1”与账号“L＝2”之间存在连线，而账号“L＝2”与账号“L＝4”之间没有关联，则账号“L＝2”与账号“L＝4”之间没有连线。在图3所示意的关联账号组中，共有6个关联账号。当然，图3中的示例性数据不应限制本申请实施例的实现。
步骤103：参考所述关联账号组内各账号的正常账号概率，确定所述关联账号组内的账号是否为异常账号。
在步骤103中，先获取到关联账号组内各账号的异常账号概率。即是一个账号属于异常账号的概率，然后各个账号的正常账号概率，对同一个关联账号组内的账号进行迭代，并且通过设置最大迭代次数，或者在一轮迭代之后关联账号组内的账号关系没有发生变化时，来终止迭代，并根据终止迭代时各个关联账号组内关联账号的总个数，来判断该组关联账号组中的关联账号是否为异常账号。
具体的，步骤103具体可以包括：
步骤D1：依据所述关联账号组内各账号的活跃度、消费频率和消费金额，计算各账号的正常账号概率。
除了能够表示账号间的关系的历史关联分值和实时关联分值之外，可以还通过账号在电商平台上的全链路行为，依据各个账号的活跃度、消费频率和消费金额，来计算出账号的正常账号概率，用于衡量用户的账号评价价值。一般情况下，相似的行为模式，在不同价值的账号上有着不同的解读。例如，对于高价值的白账号即正常账号概率较大或者较大可能是正常账号的账号，即便通过同IP地址进行登录并购买日常用品，也很有可能是帮助别人下单购物或共同购买的正常行为。而对于疑似垃圾的账号即正常账号概率较小或者很有可能是异常账号的账号，通过同IP地址进行登录并购买手机，就很有可能是垃圾账号，例如是黄牛团伙。
在本步骤中，正常账号概率可以使用活跃度、消费频率和消费金额(FRM，Recency、Monetary Frequency)进行建模，即由如下三个指标进行正常账号概率的计算即用于账号的价值评估：最近一次消费(Recency)，即活跃度；消费频率(Frequency)，即忠诚度；消费金额(Monetary)，即购买力。
其中，计算活跃度的方式如公式(四)所示：
计算消费频率的方式如公式(五)所示：
计算消费金额的方式如公式(六)所示：
然后，在计算得到活跃度、消费频率和消费金额之后，利用如下所示的公式(七)计算正常账号概率：
Value_scorei＝1-exp(-(0.6*P_scorei+0.2*L_scorei+0.2*A_scorei)/0.5)
其中，采用公式(七)计算得到的正常账号概率即账号价值分数Value_score，为在0-1之间的连续值。其中，分值越高，表示账号的价值越高即该账号是正常账号的概率越大，或者，该账号作为黄牛的可能性就越低。
步骤D2：针对关联账号组内的各账号，以任一账号为当前账号，确定该当前账号与其相邻的关联账号之间目标关联分值最大的目标账号。
在本步骤中，针对关联账号组内的各账号，就可以采用改进的LPA(LabelPropagation Algorithm)算法对关联账号组内的各账号进行迭代计算，从而确定哪些账号是异常账号，即进行哪些账号对应了黄牛团伙的计算。
在本实施例中，对于关联账号组内的某一个账号的节点，考察其所有邻居节点的标签，查找到相邻的关联账号之间关联分值最大的那个账号作为目标账号。
步骤D3：判断所述目标账号是否可以替换所述当前账号，如果是，则进入步骤D4；如果否，则返回步骤D2。
在LPA算法中融入之前的目标关联分值以及正常账号概率，具体步骤如下：第一步:关联账号组中的所有节点的初始所属团伙为自身；第二步:逐轮对关联账号组内的各个关联账号进行迭代，直到达到收敛条件为止。迭代的过程即是针对关联账号组中的各个关联账号，来判断步骤D2中得到的目标账号是否能当当前的关联账号进行替换。
具体的，判断所述目标账号是否可以替换所述当前账号，可以先判断该当前账号与目标账号之间的目标关联分值，与，该目标账号的正常账号概率相除的商，是否大于预设替换阈值。
具体判断过程，即是迭代方式可以如公式(八)所示：
其中：
为在第k轮迭代时，账号j的团伙标示；当k＝1，标示为账号本身，即
rscore_totalij为采用公式(三)计算的、账号i与账号j之间的目标关联分值；Value_scorej则为采用公式(七)计算的、账号j的正常账号概率。
参考公式(八)，针对关联账号组中的第i个关联账号，确定目标关联分值最大的账号j，作为第i个关联账号的节点当前迭代的目标账号，如果第i个关联账号与目标账号j之间的目标关联分值与目标账号j的正常账号概率的商，大于预设替换阈值，则将第j个账号替换第i个账号；如果不大于预设替换阈值，则第i个账号保持不变。例如，可以将预设替换阈值的大小设置为0.5，该替换阈值的大小可以由本领域技术人员根据经验值进行设置。
步骤D4：将所述当前账号替换为所述目标账号。
将目标账号j替换当前账号i。
步骤D5：获取下一个未判断过的账号为当前账号，执行所述定该当前账号与其相邻的关联账号之间关联分值最大的目标账号，直至所述关联账号组内的各账号都判断完毕，或者，所述关联账号组内没有账号可被替换。
接着将同一个关联账号组中的其他未进行过判断的账号作为当前账号，执行对其的迭代过程，即是判断是否存在可以替换该当前账号的其他目标账号，直至该关联账号组内所有的账号都判断完毕，或者，该关联账号组内没有账号可以被替换为止。
具体的，参考图4a所示，为图3所示的账号“L＝1”被账号“L＝3”替换，接着账号“L＝2”也被账号“L＝3”替换，以及，账号“L＝4”和账号“L＝5”被账号“L＝6”替换的示意图；以及，在对图4a示意的关联账号组中的各个账号进一步迭代之后，该关联账号组中的各个账号都被替换为“L＝5”。
当然，图4a和图4b示意的迭代过程和迭代结果仅仅是示例性数据，不应将其理解为本申请实施例的限定。
步骤D6：依据所述关联账号组中相同账号的个数，确定该关联账号组内的账号是否为异常账号。
接着，依据迭代后的关联账号组内相同账号的个数有多少，来确定关联账号组内的各个账号是否为异常账号。例如，判断关联账号组内相同账号的个数是否大于预设个数阈值，如果是，则将该关联账号组内的各账号确定为异常账号；如果否，则将所述关联账号组内的各账号确定为正常账号。具体的，可以统计关联账号组内相同账号的个数是否大于预先设置的个数阈值，如果大于，则将该关联账号组内的各个账号都确定为异常账号，例如，这是一个专门刷票的黄牛团伙等，如果不大于，则将该关联账号组内的各个账号作为正常账号。
参考图5所示，假设本领域技术人员预先设置了个数阈值为3，则图5左上方的关联账号组中，组内的账号总个数共有6个，6大于3，则将图5左上方的关联账号组内的各个账号判断为属于黄牛团伙的异常账号；而对于图5右上方的关联账号组内只有一个账号，则该关联账号组内的账号就是用户的正常账号；而图5左下方的关联账号组内只有两个账号，2小于3，因此该关联账号组内的账号也是用户的正常账号；而图5右下方的关联账号组内有4个账号，4大于3，则图5右下方的关联账号组内的4个账号也属于黄牛团伙。
在本实施例中，通过用户的历史关联程度以及实时关联程度可以进行准确的异常账号判断，例如黄牛团伙的识别防控等，这个过程对于正常用户而言，完全是透明的，不会影响用户体验；而对于异常账号的用户而言，无论是修改IP地址还是其他方式，都很难在多个特征维度的历史行为和当前行为上，规避同团伙的购买行为，因此，采用本申请实施例的异常账号的确定方案就会更为准确和精确。并且，在本申请实施例中，还通过对一个账号的正常账号概率进行评估，从而引入用户的账号的价值评估作为团伙判定的重要因子，从而能对于不同的账号采取不同的团伙识别策略，减少误判断的概率。因此，本申请实施例在保证了不影响用户体验的同时，还能达到对黄牛团伙较好的识别。
在步骤103确定了异常账号之后，还可以包括步骤104：
步骤104：向所述异常账号发送下单限制指令，所述下单限制指令用于提示所述异常账号的用户其账号不允许下单。
在确定了哪些账号为异常账号之后，服务器可以屏蔽或者拒绝这些异常账号的下单请求，并且进一步的可以向异常之后发生下单限制指令，下单限制指令用于提示所述异常账号的用户其账号不允许下单。
可见，通过图1所示的实施例，可以确定哪些账号是异常账号(黄牛账号等)，以及异常账号所在的关联账号组(黄牛账号所属的黄牛团伙等)，并且可以从数据库中查询到某个黄牛团伙的已下单次数、已购买金额、已购买用户数等，在实际应用中可以只允许一个关联账号组中的某一个账号下单(例如第一个账号)，即仅允许黄牛团伙的第一个用户购买，而对该接下来下单的用户进行拦截。亦或者，结合实际的业务，从下单金额，下单的产品个数，下单涉及的用户个数等方面进行基于团伙的黄牛防控，等等。
参考图6，示出了本申请一种在线下单的方法实施例的流程图，本实施例可以应用于客户端，本实施例可以包括以下步骤：
步骤601：第一客户端向服务器发送第一下单请求，以及，第二客户端向服务器发送第二下单请求。
在实际应用中，服务器可以是电商平台的服务器等。假设当前有两个用户通过两个客户端(第一客户端和第二客户端)分别向服务器发送了第一下单请求和第二下单请求。其中，第一下单请求和第二下单请求涉及的产品、金额和收货地址可以相同也可以不同。
步骤602：响应于所述第一下单请求和所述第二下单请求，服务器获取所述第一下单请求对应的第一账号的历史关联分值和实时关联分值，以及，所述第二下单请求对应的第二账号的历史关联分值和实时关联分值。
而服务器在接收到多个下单请求的时候，服务器获取第一下单请求对应的第一账号的历史关联分值和实时关联分值，以及，所述第二下单请求对应的第二账号的历史关联分值和实时关联分值。
步骤603：判断所述第一账号和第二账号的历史关联分值和实时关联分值，是否符合预设关联阈值，如果符合，则进入步骤604；如果不符合则进入步骤606。
服务器可以采用图1所示的实施例涉及的方式，来判断第一账号和第二账号的历史关联分值和实时关联分值，是否符合预设关联阈值，如果符合则将这两个账号划分为同一个关联账号组，如果不符合则正常响应这多个下单请求。其中，本步骤的具体实现方式可以参考步骤102的详细介绍，在此不再赘述。
步骤604：将所述第一账号和第二账号加入关联账号组，并参考所述第一账号和第二账号的正常账号概率，确定所述关联账号组内的账号是否为异常账号，如果是异常账号，则进入步骤605，如果不是异常账号，则进入步骤606。
在本步骤中，参考步骤103的详细介绍，根据计算得到的第一账号和第二账号的正常账号概率，来判断加入同一个关联账号组的第一账号和第二账号是否为异常账号。
在实际应用中，服务器也可以将对各个账号是否为异常账号的判断结果进行判断，以便下一次该账号再次发起下单请求的时候，可以从保存的判断结果中直接查询到该账号并确定该账号为异常账号，例如黄牛账号等。
步骤605：拒绝所述第一下单请求和所述第二下单请求。
如果这关联账号组中的第一账号和第二账号都是异常账号，则服务器可以将这两个账号的下单请求都拒绝。当然，服务器也可以仅仅通过或者响应其中任意一个账号的下单请求，并拒绝或者忽略同一个关联账号组内的其他账号的下单请求。
步骤606：如果不是异常账号，或者不符合预设关联阈值，则响应于所述第一下单请求和所述第二下单请求执行所述第一账号的下单操作和所述第二账号的下单操作。
而如果步骤603判断得到不符合预设关联阈值，或者步骤604判断得到不是异常账号，则对第一下单请求和第二下单请求分别进行响应，正常执行第一账号的下单操作和第二账号的下单操作。
在本实施例中，服务器在接收到多个账号提交的下单请求的时候，可以判断这多个账号是否为异常账号例如黄牛账号等，并可以正常执行用户的正常账号的下单操作，并且拒绝黄牛账号的下单请求，较为准确和精确的对黄牛团伙进行防控。
本申请还提供了一种数据处理方法，该数据处理方法可以包括：
步骤E1：获取与待分析账号存在关联关系的关联账号。
在本实施例中，待分析的账号可以是用户在电商平台上注册时使用的标识ID，用户在一个电商平台上注册的账号能够在该电商平台内唯一标识一个用户。其中，与待分析账号存在关联关系的关联账号，可以是账号相对应的用户行为或者账号信息等之间会产生关联的那些账号。具体详情可以参考步骤101的解释，在此不再赘述。
具体的，可以先获取待分析账号和关联账号之间的关联分值，其中，关联分值用于表示一个账号和另一个账号之间的关系程度，具体详情可以参考步骤101的解释，在此不再赘述。然后将关联分值超过预设阈值的账号作为关联账户。其中，预设阈值可以由本领域技术人员自主设置。
步骤E2：确定超过预设数量的关联账号为异常账号。
在本步骤中，如果有些关联账户的个数超过预设数量，例如，与待分析账号有关联关系的关联账号超过3个，则可以认为这几个关联账号为异常账号。当然，预设数量可以由本领域技术人员自主设置。
步骤E3：确定所述待分析账号为异常账号。
然后，将待分析账号也确定为异常账号，例如在电商行业中的黄牛账号等，待分析账号和关联账号属于同一个黄牛账号组。
本申请还提供了另一种数据处理方法，可以包括：
步骤F1：获取与待分析账号存在关联关系的关联账号。
本步骤的解释可以参考步骤E1的详细介绍，在此不再赘述。
步骤F2：确定超过预设数量的关联账号为正常账号。
在本步骤中，如果有些关联账户的个数超过预设数量，例如，与待分析账号有关联关系的关联账号超过3个，则可以认为这几个关联账号为正常账号。当然，预设数量可以由本领域技术人员自主设置。因为在实际应用中，有些账号例如可以公司内部一个部门多个同事的账号，所以可以采用同一个局域网接入互联网，等，因此，将这一类账号都确定为正常账号。
步骤F3：确定所述待分析账号为正常账号。
接着将与这些关联账户有关联关系的待分析账号也为正常账号。
本申请还提供了一种数据处理方法，可以包括：
步骤G1：获取与待分析账号存在关联关系的关联账号。
本步骤可以参考步骤E1的介绍，在此不再赘述。
步骤G2：确定所述关联账号超过预设数量。
获取本领域技术人员预先设置的数量，例如，5个，如果关联账户的个数超过5个，则确定关联账户的个数超过预设数量。
步骤G3：确定所述待分析账号为疑似异常账号。
接着，将关联账户的个数超过预设数量对应的待分析账号确定疑似异常账号。在本实施例中，因为还有些场景是几个用户组成的小组共同申请各自的账号，比如通过同一台电脑或者通过同一个手机号申请账号，因此，关联账户的个数超过预设数量也未必说明待分析账号就是异常账号，可以先将其确定为疑似异常账号，后续再采用其他方式进一步确定。
本申请还提供了一种数据处理方法，可以包括：
步骤H1：获取与待分析账号存在关联关系的关联账号。
本步骤可以参考步骤E1的介绍，在此不再赘述。
步骤H2：确定所述关联账号超过预设数量。
本步骤具体可以参考步骤G2的介绍，在此不再赘述。
步骤H3：确定所述待分析账号为异常账号。
接着，将关联账户的个数超过预设数量对应的待分析账号确定为正常账号。在本实施例中，因为还有些场景是几个用户组成的小组共同申请各自的账号，比如通过同一台电脑或者通过同一个手机号申请账号，因此，关联账户的个数超过预设数量也未必说明分析账号就是异常账号，针对这种情况，可以将待分析账号确定为正常账号。
对于前述的方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本申请所必须的。
与上述本申请一种异常账号的确定方法实施例所提供的方法相对应，参见图7，本申请还提供了一种异常账号的确定装置实施例，在本实施例中，该装置可以集成于服务器端，该装置可以包括：
通信总线701，以及，处理器702，用于通过读取所述存储器703中存储的指令和/或数据，用于执行以下操作：获取待确定账号之间的历史关联分值和实时关联分值；将所述历史关联分值和实时关联分值符合预设关联阈值的待确定账号，划分为同一个关联账号组；参考所述关联账号组内账号的正常账号概率，确定所述关联账号组内的账号是否为异常账号。
显示器704，用于将所述异常账号进行显示。
其中，所述处理器702用于获取各待确定账号之间的历史关联分值，可以包括：
获取各待确定账号在互联网上对应的历史用户行为，所述历史用户行为包括：登录、注册、认证、浏览、下单和/或售后；
依据所述历史用户行为提取所述各待确定账号的历史关联特征，所述历史关联特征包括：采用同一个联系方式注册的同注册信息、采用同一个设备登录的同设备信息、或者同一个IP地址的同地址信息；
依据所述历史关联特征从多个待确定账号中，分别确定属于同一个用户的多个待确定账号，作为同用户账号；
将所述同用户账号作为正样本，其他非同用户账号作为负样本，通过回归模型计算得到任意两个待确定账号之间的历史关联分值。
其中，所述处理器702用于获取各待确定账号之间的实时关联分值，可以包括：
获取各待确定账号在互联网上对应的实时用户行为，所述实时用户行为包括：登录、注册、认证、浏览、下单和/或售后；
依据所述实时用户行为提取所述各待确定账号的实时关联特征，所述实时关联特征包括：采用同一个联系方式注册的同注册信息、采用同一个设备登录的同设备信息、或者同一个IP地址的同地址信息；
依据所述实时关联特征从多个待确定账号中，分别确定属于同一个用户的多个待确定账号，作为同用户账号；
将所述同用户账号作为正样本，其他非同用户账号作为负样本，通过回归模型计算得到任意两个待确定账号之间的实时关联分值。
其中，所述处理器703用于依据将所述历史关联程度和实时关联程度符合预设关联阈值的各待确定账号，划分为同一个关联账号组，可以包括：
按照所述历史关联分值或实时关联分值越高则目标关联分值越高的原则，确定所述各待确定账号分别与其他账号之间的目标关联分值；
判断各待确定账号分别与其他账号的目标关联分值是否大于预设分值阈值，如果是，则将该待确定账号与相对应的其他账号建立关联；
将各待确定账号及其关联的其他账号，以及与关联的其他账号具有关联的关联账号，划分为同一个关联账号组。
其中，所述处理器702用于参考所述关联账号组内各账号的正常账号概率，确定所述关联账号组内的账号是否为异常账号，包括：
依据所述关联账号组内各账号的活跃度、消费频率和消费金额，计算各账号的正常账号概率；
针对关联账号组内的各账号，以任一账号为当前账号，确定该当前账号与其相邻的关联账号之间关联分值最大的目标账号；
判断所述目标账号是否可以替换所述当前账号，如果是，则将所述当前账号替换为所述目标账号；
如果否，则获取下一个未判断过的账号为当前账号，执行所述定该当前账号与其相邻的关联账号之间关联分值最大的目标账号，直至所述关联账号组内的各账号都判断完毕，或者，所述关联账号组内没有账号可被替换；
依据所述关联账号组中相同账号的个数，确定该关联账号组内的账号是否为异常账号。
其中，所述处理器702用于判断所述目标账号是否可以替换所述当前账号，可以包括：
判断该当前账号与目标账号之间的关联分值，与，该目标账号的正常账号概率相除的商，是否大于预设替换阈值。
其中，所述处理器702用于依据所述关联账号组中相同账号的个数，确定该关联账号组内的账号是否为异常账号，可以包括：
判断依据所述关联账号组内相同账号的个数是否大于预设个数阈值，如果是，则将该关联账号组内的各账号确定为异常账号；如果否，则将所述关联账号组内的各账号确定为正常账号。
其中，所述处理器702还可以用于：
向所述异常账号发送下单限制指令，所述下单限制指令用于提示所述异常账号的用户其账号不允许下单。
参考图8所示，本申请还提供了一种在线下单装置实施例，在本实施例中，该在线下单装置可以包括：
通信接口801，用于接收第一客户端发送的第一下单请求，以及，第二客户端发送的第二下单请求；
通信总线802，以及，处理器803，通过读取所述存储器804中存储的指令和/或数据，用于执行以下操作：获取所述第一下单请求对应的第一账号的历史关联程度和实时关联程度，以及，所述第二下单请求对应的第二账号的历史关联程度和实时关联程度；判断所述第一账号和第二账号的历史关联程度和实时关联程度，是否符合预设关联阈值，如果符合，则将所述第一账号和第二账号加入关联账号组，并参考所述第一账号和第二账号的正常账号概率，确定所述关联账号组内的账号是否为异常账号，如果是异常账号，则拒绝所述第一下单请求和所述第二下单请求；如果不是异常账号，或者不符合预设关联阈值，则响应于所述第一下单请求和所述第二下单请求执行所述第一账号的下单操作和所述第二账号的下单操作。
需要说明的是，本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。对于装置类实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
以上对本申请所提供的异常账号的确定方法及装置、在线下单方法及装置进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。
Claims (18)
1.一种异常账号的确定方法，其特征在于，包括：
获取待确定账号之间的历史关联分值和实时关联分值；所述历史关联分值和实时关联分值分别用于表示不同账号之间的历史关联程度和实时关联程度；所述历史关联分值和实时关联分值基于账号对应的用户行为和账号信息之间的关联关系而确定；
将所述历史关联分值和实时关联分值符合预设关联阈值的待确定账号，划分为同一个关联账号组；
参考所述关联账号组内账号的正常账号概率，确定所述关联账号组内的账号是否为异常账号。
2.根据权利要求1所述的方法，其特征在于，所述获取各待确定账号之间的历史关联分值，包括：
获取各待确定账号在互联网上对应的历史用户行为，所述历史用户行为包括：登录、注册、认证、浏览、下单和/或售后；
依据所述历史用户行为提取所述各待确定账号的历史关联特征，所述历史关联特征包括：采用同一个联系方式注册的同注册信息、采用同一个设备登录的同设备信息、或者同一个IP地址的同地址信息；
依据所述历史关联特征从多个待确定账号中，分别确定属于同一个用户的多个待确定账号，作为同用户账号；
将所述同用户账号作为正样本，其他非同用户账号作为负样本，通过回归模型计算得到任意两个待确定账号之间的历史关联分值。
3.根据权利要求1所述的方法，其特征在于，所述获取各待确定账号之间的实时关联分值，包括：
获取各待确定账号在互联网上对应的实时用户行为，所述实时用户行为包括：登录、注册、认证、浏览、下单和/或售后；
依据所述实时用户行为提取所述各待确定账号的实时关联特征，所述实时关联特征包括：采用同一个联系方式注册的同注册信息、采用同一个设备登录的同设备信息、或者同一个IP地址的同地址信息；
依据所述实时关联特征从多个待确定账号中，分别确定属于同一个用户的多个待确定账号，作为同用户账号；
将所述同用户账号作为正样本，其他非同用户账号作为负样本，通过回归模型计算得到任意两个待确定账号之间的实时关联分值。
4.根据权利要求2所述的方法，其特征在于，所述将所述历史关联分值和实时关联分值符合预设关联阈值的待确定账号，划分为同一个关联账号组，包括：
按照所述历史关联分值或实时关联分值越高则目标关联分值越高的原则，确定所述各待确定账号分别与其他账号之间的目标关联分值；
判断各待确定账号分别与其他账号的目标关联分值是否大于预设分值阈值，如果是，则将该待确定账号与相对应的其他账号建立关联；
将各待确定账号及其关联的其他账号，以及与关联的其他账号具有关联的关联账号，划分为同一个关联账号组。
5.根据权利要求1所述的方法，其特征在于，所述参考所述关联账号组内各账号的正常账号概率，确定所述关联账号组内的账号是否为异常账号，包括：
依据所述关联账号组内各账号的活跃度、消费频率和消费金额，计算各账号的正常账号概率；
针对关联账号组内的各账号，以任一账号为当前账号，确定该当前账号与其相邻的关联账号之间关联分值最大的目标账号；
判断所述目标账号是否可以替换所述当前账号，如果是，则将所述当前账号替换为所述目标账号；
如果否，则获取下一个未判断过的账号为当前账号，执行所述定该当前账号与其相邻的关联账号之间关联分值最大的目标账号，直至所述关联账号组内的各账号都判断完毕，或者，所述关联账号组内没有账号可被替换；
依据所述关联账号组中相同账号的个数，确定该关联账号组内的账号是否为异常账号。
6.根据权利要求5所述的方法，其特征在于，所述判断所述目标账号是否可以替换所述当前账号，包括：
判断该当前账号与目标账号之间的关联分值，与，该目标账号的正常账号概率相除的商，是否大于预设替换阈值。
7.根据权利要求5所述的方法，其特征在于，所述依据所述关联账号组中相同账号的个数，确定该关联账号组内的账号是否为异常账号，包括：
判断依据所述关联账号组内相同账号的个数是否大于预设个数阈值，如果是，则将该关联账号组内的各账号确定为异常账号；如果否，则将所述关联账号组内的各账号确定为正常账号。
8.根据权利要求1所述的方法，其特征在于，还包括：
向所述异常账号发送下单限制指令，所述下单限制指令用于提示所述异常账号的用户其账号不允许下单。
9.一种在线下单方法，其特征在于，包括：
接收第一客户端发送的第一下单请求，以及，第二客户端发送的第二下单请求；
获取所述第一下单请求对应的第一账号的历史关联分值和实时关联分值，以及，所述第二下单请求对应的第二账号的历史关联分值和实时关联分值；所述历史关联分值和实时关联分值分别用于表示不同账号之间的历史关联程度和实时关联程度；所述历史关联分值和实时关联分值基于账号对应的用户行为和账号信息之间的关联关系而确定；
判断所述第一账号和第二账号的历史关联分值和实时关联分值，是否符合预设关联阈值，如果符合，则将所述第一账号和第二账号加入关联账号组，并参考所述第一账号和第二账号的正常账号概率，确定所述关联账号组内的账号是否为异常账号，如果是异常账号，则拒绝所述第一下单请求和所述第二下单请求；
如果不是异常账号，或者不符合预设关联阈值，则响应于所述第一下单请求和所述第二下单请求执行所述第一账号的下单操作和所述第二账号的下单操作。
10.一种异常账号的确定装置，其特征在于，包括：
处理器，用于获取待确定账号之间的历史关联分值和实时关联分值；将所述历史关联分值和实时关联分值符合预设关联阈值的待确定账号，划分为同一个关联账号组；参考所述关联账号组内账号的正常账号概率，确定所述关联账号组内的账号是否为异常账号；所述历史关联分值和实时关联分值分别用于表示不同账号之间的历史关联程度和实时关联程度；所述历史关联分值和实时关联分值基于账号对应的用户行为和账号信息之间的关联关系而确定；
显示器，用于将所述异常账号进行显示。
11.根据权利要求10所述的装置，其特征在于，所述处理器用于获取各待确定账号之间的历史关联分值，包括：
获取各待确定账号在互联网上对应的历史用户行为，所述历史用户行为包括：登录、注册、认证、浏览、下单和/或售后；
依据所述历史用户行为提取所述各待确定账号的历史关联特征，所述历史关联特征包括：采用同一个联系方式注册的同注册信息、采用同一个设备登录的同设备信息、或者同一个IP地址的同地址信息；
依据所述历史关联特征从多个待确定账号中，分别确定属于同一个用户的多个待确定账号，作为同用户账号；
将所述同用户账号作为正样本，其他非同用户账号作为负样本，通过回归模型计算得到任意两个待确定账号之间的历史关联分值。
12.根据权利要求10所述的装置，其特征在于，所述处理器用于获取各待确定账号之间的实时关联分值，包括：
获取各待确定账号在互联网上对应的实时用户行为，所述实时用户行为包括：登录、注册、认证、浏览、下单和/或售后；
依据所述实时用户行为提取所述各待确定账号的实时关联特征，所述实时关联特征包括：采用同一个联系方式注册的同注册信息、采用同一个设备登录的同设备信息、或者同一个IP地址的同地址信息；
依据所述实时关联特征从多个待确定账号中，分别确定属于同一个用户的多个待确定账号，作为同用户账号；
将所述同用户账号作为正样本，其他非同用户账号作为负样本，通过回归模型计算得到任意两个待确定账号之间的实时关联分值。
13.根据权利要求12所述的装置，其特征在于，所述将所述历史关联分值和实时关联分值符合预设关联阈值的待确定账号，划分为同一个关联账号组，包括：
按照所述历史关联分值或实时关联分值越高则目标关联分值越高的原则，确定所述各待确定账号分别与其他账号之间的目标关联分值；
判断各待确定账号分别与其他账号的目标关联分值是否大于预设分值阈值，如果是，则将该待确定账号与相对应的其他账号建立关联；
将各待确定账号及其关联的其他账号，以及与关联的其他账号具有关联的关联账号，划分为同一个关联账号组。
14.根据权利要求10所述的装置，其特征在于，所述处理器用于参考所述关联账号组内各账号的正常账号概率，确定所述关联账号组内的账号是否为异常账号，包括：
依据所述关联账号组内各账号的活跃度、消费频率和消费金额，计算各账号的正常账号概率；
针对关联账号组内的各账号，以任一账号为当前账号，确定该当前账号与其相邻的关联账号之间关联分值最大的目标账号；
判断所述目标账号是否可以替换所述当前账号，如果是，则将所述当前账号替换为所述目标账号；
如果否，则获取下一个未判断过的账号为当前账号，执行所述定该当前账号与其相邻的关联账号之间关联分值最大的目标账号，直至所述关联账号组内的各账号都判断完毕，或者，所述关联账号组内没有账号可被替换；
依据所述关联账号组中相同账号的个数，确定该关联账号组内的账号是否为异常账号。
15.根据权利要求14所述的装置，其特征在于，所述处理器用于判断所述目标账号是否可以替换所述当前账号，包括：
判断该当前账号与目标账号之间的关联分值，与，该目标账号的正常账号概率相除的商，是否大于预设替换阈值。
16.根据权利要求14所述的装置，其特征在于，所述处理器用于依据所述关联账号组中相同账号的个数，确定该关联账号组内的账号是否为异常账号，包括：
判断依据所述关联账号组内相同账号的个数是否大于预设个数阈值，如果是，则将该关联账号组内的各账号确定为异常账号；如果否，则将所述关联账号组内的各账号确定为正常账号。
17.根据权利要求10所述的装置，其特征在于，所述处理器还用于：
向所述异常账号发送下单限制指令，所述下单限制指令用于提示所述异常账号的用户其账号不允许下单。
18.一种在线下单装置，其特征在于，包括：
通信接口，用于接收第一客户端发送的第一下单请求，以及，第二客户端发送的第二下单请求；
处理器，用于获取所述第一下单请求对应的第一账号的历史关联分值和实时关联分值，以及，所述第二下单请求对应的第二账号的历史关联分值和实时关联分值；所述历史关联分值和实时关联分值分别用于表示不同账号之间的历史关联程度和实时关联程度；所述历史关联分值和实时关联分值基于账号对应的用户行为和账号信息之间的关联关系而确定；判断所述第一账号和第二账号的历史关联分值和实时关联分值，是否符合预设关联阈值，如果符合，则将所述第一账号和第二账号加入关联账号组，并参考所述第一账号和第二账号的正常账号概率，确定所述关联账号组内的账号是否为异常账号，如果是异常账号，则拒绝所述第一下单请求和所述第二下单请求；如果不是异常账号，或者不符合预设关联阈值，则响应于所述第一下单请求和所述第二下单请求执行所述第一账号的下单操作和所述第二账号的下单操作。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201711209032.2A CN109858919B (zh) | 2017-11-27 | 2017-11-27 | 异常账号的确定方法及装置、在线下单方法及装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201711209032.2A CN109858919B (zh) | 2017-11-27 | 2017-11-27 | 异常账号的确定方法及装置、在线下单方法及装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN109858919A CN109858919A (zh) | 2019-06-07 |
| CN109858919B true CN109858919B (zh) | 2023-04-07 |
Family
ID=66887600
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201711209032.2A Active CN109858919B (zh) | 2017-11-27 | 2017-11-27 | 异常账号的确定方法及装置、在线下单方法及装置 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN109858919B (zh) |
Families Citing this family (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110225036B (zh) * | 2019-06-12 | 2022-03-22 | 北京奇艺世纪科技有限公司 | 一种账号检测方法、装置、服务器及存储介质 |
| CN111064741A (zh) * | 2019-12-27 | 2020-04-24 | 全知科技(杭州)有限责任公司 | 一种识别web应用系统中账号借用风险的方法 |
| CN113554438B (zh) * | 2020-04-23 | 2023-12-05 | 北京京东振世信息技术有限公司 | 账号的识别方法、装置、电子设备及计算机可读介质 |
| CN111726359B (zh) * | 2020-06-18 | 2023-04-07 | 五八有限公司 | 一种账户信息的检测方法和装置 |
| CN111476510B (zh) * | 2020-06-23 | 2020-10-16 | 武汉斗鱼鱼乐网络科技有限公司 | 一种风险用户识别的方法及系统、存储介质、设备 |
| CN111784468B (zh) * | 2020-07-01 | 2022-11-18 | 支付宝(杭州)信息技术有限公司 | 一种账户关联方法、装置及电子设备 |
| CN115374195A (zh) * | 2022-07-25 | 2022-11-22 | 北京数美时代科技有限公司 | 一种离线风控管理方法、系统、存储介质和电子设备 |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104025094A (zh) * | 2011-10-13 | 2014-09-03 | 新人类有限公司 | 检测异常账号的装置及方法 |
| CN104426885A (zh) * | 2013-09-03 | 2015-03-18 | 深圳市腾讯计算机系统有限公司 | 异常账号提供方法及装置 |
| CN106302612A (zh) * | 2015-06-10 | 2017-01-04 | 阿里巴巴集团控股有限公司 | 账号的创建方法及装置 |
| CN106372938A (zh) * | 2015-07-21 | 2017-02-01 | 华为技术有限公司 | 异常账号识别方法及系统 |
| CN107124391A (zh) * | 2016-09-22 | 2017-09-01 | 北京小度信息科技有限公司 | 异常行为的识别方法及装置 |
-
2017
- 2017-11-27 CN CN201711209032.2A patent/CN109858919B/zh active Active
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104025094A (zh) * | 2011-10-13 | 2014-09-03 | 新人类有限公司 | 检测异常账号的装置及方法 |
| CN104426885A (zh) * | 2013-09-03 | 2015-03-18 | 深圳市腾讯计算机系统有限公司 | 异常账号提供方法及装置 |
| CN106302612A (zh) * | 2015-06-10 | 2017-01-04 | 阿里巴巴集团控股有限公司 | 账号的创建方法及装置 |
| CN106372938A (zh) * | 2015-07-21 | 2017-02-01 | 华为技术有限公司 | 异常账号识别方法及系统 |
| CN107124391A (zh) * | 2016-09-22 | 2017-09-01 | 北京小度信息科技有限公司 | 异常行为的识别方法及装置 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN109858919A (zh) | 2019-06-07 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN109858919B (zh) | 异常账号的确定方法及装置、在线下单方法及装置 | |
| CN107066616B (zh) | 用于账号处理的方法、装置及电子设备 | |
| KR102151862B1 (ko) | 서비스 처리 방법 및 장치 | |
| CN107146089B (zh) | 一种刷单识别方法及装置，电子设备 | |
| CN109922032B (zh) | 用于确定登录账户的风险的方法、装置、设备及存储介质 | |
| CN107423613B (zh) | 依据相似度确定设备指纹的方法、装置及服务器 | |
| CN107563757B (zh) | 数据风险识别的方法及装置 | |
| WO2016015444A1 (zh) | 一种目标用户的确定方法、设备和网络服务器 | |
| US20230115406A1 (en) | Method and System for Providing a User Agent String Database | |
| US9754306B2 (en) | Recommendation engine with profile analysis | |
| CN105183781B (zh) | 信息推荐方法及装置 | |
| CN107341716A (zh) | 一种恶意订单识别的方法、装置及电子设备 | |
| TW201816678A (zh) | 一種非法交易檢測方法及裝置 | |
| CN111460312A (zh) | 空壳企业识别方法、装置及计算机设备 | |
| JP2012504288A (ja) | オンライン・マーケティング効率の評価 | |
| CN107203883B (zh) | 一种风险控制方法和设备 | |
| CN111966912B (zh) | 基于知识图谱的推荐方法、装置、计算机设备及存储介质 | |
| CN112801670B (zh) | 针对支付操作的风险评估方法及装置 | |
| CN108805598A (zh) | 相似度信息确定方法、服务器及计算机可读存储介质 | |
| CN110705585A (zh) | 网络欺诈识别方法、装置、计算机装置及存储介质 | |
| CN112966865B (zh) | 携号转网预测方法、装置及设备 | |
| CN107153656A (zh) | 一种信息搜索方法和装置 | |
| CN111259952A (zh) | 异常用户识别方法、装置、计算机设备及存储介质 | |
| CN107622197A (zh) | 设备识别方法及装置、用于设备识别的权重计算方法及装置 | |
| KR20190002593A (ko) | 계정 컴플레인트 처리 방법 및 서버 |
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 | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |