CN106570010A - 识别交互数据中连号用户的方法及装置 - Google Patents

Abstract

本申请揭示了一种识别交互数据中连号用户的方法及装置，其中，所述方法包括：获取待识别的交互数据涉及的第一类和第二类账户的用户身份信息，并按照交互关系列表；根据第二类账户的用户身份信息对所述列表进行划分，以获得至少一组第二类账户中相同用户身份信息所对应的第一类账户的用户身份信息的聚合数据；将每一组聚合数据中第一类账户的用户身份信息按照升序排列，并获取每一组聚合数据中每一个第一类账户在排列后列表中的行号；分别计算每一个第一类账户的用户身份信息与获取到的行号的差值；分别统计每一组聚合数据中具有相同差值的数量；若相同差值的数量大于1，则识别为所述待识别的交互数据中存在连号用户。

Description

识别交互数据中连号用户的方法及装置

技术领域

本申请涉及计算机领域，尤其是涉及一种识别交互数据中连号用户的方法及装置。

背景技术

识别交互数据中连号用户(例如多个用户ID为连续的号码、多个用户用户手机号为连续的号码等)几乎是互联网时代下每个互联网企业都要面对的问题，无论是短信营销推广，还是用户行为监控，都需要防止同一实体人通过批量注册大量的用户(一般通过批量注册的用户在用户ID和/或用户手机号上会产生连号)来伪造真实交互数据。

发明内容

本申请的目的在于提供一种识别交互数据中连号用户的方法及装置，该方法和装置可方便的识别出对交互数据中的连号用户。

为实现上述申请目的之一，本申请一实施方式提供了一种识别交互数据中连号用户的方法，所述方法包括：

获取待识别的交互数据涉及的第一类账户和第二类账户的用户身份信息，并按照交互关系列表；

根据第二类账户的用户身份信息对所述列表进行划分，以获得至少一组第二类账户中相同用户身份信息所对应的第一类账户的用户身份信息的聚合数据；

将每一组聚合数据中第一类账户的用户身份信息按照升序排列，并获取每一组聚合数据中每一个第一类账户在排列后列表中的行号；

分别计算每一个第一类账户的用户身份信息与获取到的行号的差值；

分别统计每一组聚合数据中具有相同差值的数量；

若相同差值的数量大于1，则识别为所述待识别的交互数据中存在连号用户。

作为本申请一实施方式的进一步改进，若相同差值的数量大于1，则认为所述待识别的交互数据中存在用户身份信息连号的用户步骤具体包括：

将具有相同差值数量大于或等于预设阈值的聚合数据识别为存在连号用户的异常交互数据。

作为本申请一实施方式的进一步改进，在分别计算每一个第一类账户的用户身份信息与其对应的行号的差值的步骤前，所述方法还包括：

将第一类账户的用户身份信息数字化。

作为本申请一实施方式的进一步改进，所述方法还包括：

将识别为存在连号用户的异常交互数据对应的交互数据和/或第一类账户的用户身份信息进行标注。

作为本申请一实施方式的进一步改进，所述用户身份信息为用户ID或用户绑定的手机号码。

作为本申请一实施方式的进一步改进，获取交互数据涉及的两类账户的用户身份信息的步骤具体包括：

获取预订时间内预订业务所产生的交互数据涉及的两类账户的用户身份信息，并按照交互关系列表。

为实现上述申请目的之一，本申请一实施方式提供了一种识别交互数据中连号用户的模块，所述模块包括：

数据处理模块，用于获取待识别的交互数据涉及的第一类账户和第二类账户的用户身份信息，并按照交互关系列表；

分组模块，用于根据第二类账户的用户身份信息对所述列表进行划分，以获得至少一组第二类账户中相同用户身份信息所对应的第一类账户的用户身份信息的聚合数据；

排列模块，用于将每一组聚合数据中第一类账户的用户身份信息按照升序排列；

统计模块，用于获取每一组聚合数据中每一个第一类账户在排列后列表中的行号；

计算模块，用于分别计算每一个第一类账户的用户身份信息与获取到的行号的差值，以及分别统计每一组聚合数据中具有相同差值的数量；

处理模块，用于若相同差值的数量大于1，则识别为所述待识别的交互数据中存在连号用户。

作为本申请一实施方式的进一步改进，所述处理模块还用于：

将具有相同差值数量大于或等于预设阈值的聚合数据识别为存在连号用户的异常交互数据。

作为本申请一实施方式的进一步改进，所述装置还包括转换模块，用于：

将第一类账户的用户身份信息数字化。

作为本申请一实施方式的进一步改进，所述处理模块还用于：

将识别为存在连号用户的异常交互数据对应的交互数据和/或第一类账户的用户身份信息进行标注。

作为本申请一实施方式的进一步改进，所述用户身份信息为用户ID或用户绑定的手机号码。

作为本申请一实施方式的进一步改进，所述数据处理模块具体用于：

获取预订时间内预订业务所产生的交互数据涉及的两类账户的用户身份信息，并按照交互关系列表。

相对于现有技术，本申请的识别交互数据中连号用户的方法及装置，可方便有效地识别出产生交互数据的连号用户，以便对用户交互行为进行监控，防止同一实体人通过批量注册大量的用户来伪造真实交互数据，使得交互数据更为真实可靠。

附图说明

图1是本申请一实施方式中识别交互数据中连号用户的方法的流程图。

图2是本申请一示例的两类账户的用户身份信息按照交互关系列表的示意图。

图3是本申请另一示例的两类账户的用户身份信息按照交互关系列表的示意图。

图4是本申请一实施方式中识别交互数据中连号用户的装置的模块图。

具体实施方式

以下将结合附图所示的具体实施方式对本申请进行详细描述。但这些实施方式并不限制本申请，本领域的普通技术人员根据这些实施方式所做出的结构、方法、或功能上的变换均包含在本申请的保护范围内。

如图1所示，在本申请一实施方式中，所述识别交互数据中连号用户的方法包括：

S1、获取待识别的交互数据涉及的第一类账户和第二类账户的用户身份信息，并按照交互关系列表；

S2、根据第二类账户的用户身份信息对所述列表进行划分，以获得至少一组第二类账户中相同用户身份信息所对应的第一类账户的用户身份信息的聚合数据；

S3、将每一组聚合数据中第一类账户的用户身份信息按照升序排列，并获取每一组聚合数据中每一个第一类账户在排列后列表中的行号；

S4、分别计算每一个第一类账户的用户身份信息与获取到的行号的差值；

S5、分别统计每一组聚合数据中具有相同差值的数量；

S6、若相同差值的数量大于1，则识别为所述待识别的交互数据中存在连号用户。

为了避免获取到的用户身份信息数据太过庞大导致的计算负荷太大，进一步地，在本实施方式中，所述获取交互数据涉及的两类账户的用户身份信息的步骤具体包括：获取预订时间内预订业务所产生的交互数据涉及的两类账户的用户身份信息，并按照交互关系列表。

以下将结合一现实场景的示例对本申请的技术方案进行详细说明。

例如，电子交易平台下，买家和卖家之间发生交易时，会产生交易信息，该交易信息所涉及到的两类账户即是买家账户和卖家账户。这里，可将买家账户看作第一类账户，卖家账户看作第二类账户，当然，也可将卖家账户看作第一类账户，买家账户看作第二类账户。

以买家账户为第一类账户，卖家账户为第二类账户为例，在本示例中，可先获取预订时间(例如一周)内的所述电子交易平台下的交易信息，其中包括了买家账户和卖家账户，以及交易记录。

买家账户包括了多个买家身份信息，卖家账户包括一个或多个与买家账户中的买家在预订时间内发生过交易的卖家身份信息。

其次，将买家身份信息和卖家身份信息按照交易关系进行列表，如图2所示。在本示例中，买家和卖家是对多一的关系，用户身份信息为用户ID，即所述买家身份信息为买家ID；所述卖家身份信息为卖家ID。

在该列表中，相同买家和相同卖家的交易对应表中的一行，即是若一个买家和一个卖家发生了多笔交易，只在列表中记录一次。

例如，买家ID为001的买家和卖家ID为001的卖家之间发生过交易，故将两者列在同一行中，作为一笔交易记录；买家ID为002的买家和卖家ID为001的卖家也发生过交易，故将两者列在同一行中，作为一笔交易记录；买家ID为375的买家和卖家ID为001的卖家也发生过交易，故将两者列在同一行中，作为一笔交易记录，以此类推。

接下来，根据卖家ID对列表进行划分，获得相同卖家ID对应的买家ID的聚合数据，当然，在本示例中，因为卖家ID为同一个，故聚合后的数据实质无变化。

然后，将买家ID按照升序排列，因为已经是相同卖家ID的聚合数据，故尽管排列顺序不同，买家和卖家的发生交易的关系并不会改变。其中，所述的升序排列是指将买家ID从小到大进行排列，使得对应的行数越小，买家ID越小。

通过上述的升序排列，可获得每个买家ID所对应排列后列表中的行号，例如，买家ID为001的买家对应的行号为2，买家ID为002的买家对应的行号为3，买家ID为375的买家对应的行号为200等。

如此，可计算每个买家ID和对应行号的差值，例如，买家ID为001的买家对应差值为001-2＝-1，买家ID为002的买家对应的差值为002-3＝-1，买家ID为375的买家对应的差值为375-200＝175。

可以看出，买家ID为001的买家和买家ID为002的买家其计算出的差值是相同的，并可通过统计每一组聚合数据中具有相同差值的数量，来识别交互数据中是否存在买家ID连号的买家。例如，当相同差值的数量大于1时，则识别为所述待识别的交互数据中存在买家ID连号的买家。

本领域技术人员可以理解的是，将买家ID替换为买家绑定的手机号，将卖家ID替换为卖家绑定的手机号，因手机号的唯一性和可批量注册性，也可通过上述技术方案识别交互数据中是否存在买家绑定的手机号连号的买家，在此不再赘述。

参图3所示，在提供的另一示例中，与上述示例的区别在于：买家账户包括了多个买家身份信息，卖家账户也包括了多个卖家身份信息。

例如，买家ID为001的买家和卖家ID为001的卖家之间发生过交易，故将两者列在同一行中，作为一笔交易记录；买家ID为002的买家和卖家ID为002的卖家也发生过交易，故将两者列在同一行中，作为一笔交易记录；买家ID为375的买家和卖家ID为133的卖家也发生过交易，故将两者列在同一行中，作为一笔交易记录，以此类推。

对于此示例，由于卖家ID的多样性，就必须根据卖家ID对列表进行划分，获得相同卖家ID对应的买家ID的聚合数据。这也是在对海量数据进行分析时的普遍场景。

以图3示例来看，可按照卖家ID对列表进行划分，以得到卖家ID为001的卖家所对应的买家的聚合数据、卖家ID为002的卖家所对应的买家的聚合数据，以此类推。如此，可避免同一买家或连号买家与不同卖家发生交易所导致的识别连号用户错误。

另外，在本申请一实施方式中，在分别计算每一个第一类账户的用户身份信息与其对应的行号的差值的步骤前，所述方法还包括：

将第一类账户的用户身份信息数字化。

如上述图2、图3示例，买家的买家ID为纯数字ID，当然，买家绑定的手机号也肯定是纯数字的。然而，也不能排除在某些平台中买家ID并非纯数字ID，例如，其为字母和数字的组合或者纯字母等非数字ID，此时，为了便于升序排列，需要将买家ID数字化，即是将非数字的元素通过预订规则的转换，以数字体现，例如，将ABC001的买家ID数字化为123001。

进一步地，在本申请一实施方式中，若相同差值的数量大于1，则认为所述待识别的交互数据中存在用户身份信息连号的用户步骤具体包括：

将具有相同差值数量大于或等于预设阈值的聚合数据识别为存在连号用户的异常交互数据。

进一步地，可将识别为存在连号用户的异常交互数据对应的交互数据和/或第一类账户的用户身份信息进行标注。

例如，若相同差值的数量大于或等于5，则将对应的交易记录和/或相应的买家ID打上连号便签，以为后续的虚假交易模型提供评分项，当然，还可为用户关系模型的提供评分项。

本领域技术人员可以理解的是，上述示例中是以买家账户为第一类账户为例，在其他示例中，也可以卖家账户为第一类账户，在此不再赘述。

如图4所示，在本申请一实施方式中，所述识别交互数据中连号用户的装置包括：

数据处理模块10，用于获取待识别的交互数据涉及的第一类账户和第二类账户的用户身份信息，并按照交互关系列表；

分组模块20，用于根据第二类账户的用户身份信息对所述列表进行划分，以获得至少一组第二类账户中相同用户身份信息所对应的第一类账户的用户身份信息的聚合数据；

排列模块30，用于将每一组聚合数据中第一类账户的用户身份信息按照升序排列；

统计模块40，用于获取每一组聚合数据中每一个第一类账户在排列后列表中的行号；

计算模块50，用于分别计算每一个第一类账户的用户身份信息与获取到的行号的差值，以及分别统计每一组聚合数据中具有相同差值的数量；

处理模块60，用于若相同差值的数量大于1，则识别为所述待识别的交互数据中存在连号用户。

为了避免获取到的用户身份信息数据太过庞大导致的计算负荷太大，进一步地，在本实施方式中，所述数据处理模块10具体用于：

获取预订时间内预订业务所产生的交互数据涉及的两类账户的用户身份信息，并按照交互关系列表。

以下将结合一现实场景的示例对本申请的技术方案进行详细说明。

例如，电子交易平台下，买家和卖家之间发生交易时，会产生交易信息，该交易信息所涉及到的两类账户即是买家账户和卖家账户。这里，可将买家账户看作第一类账户，卖家账户看作第二类账户，当然，也可将卖家账户看作第一类账户，买家账户看作第二类账户。

以买家账户为第一类账户，卖家账户为第二类账户为例，在本示例中，可先获取预订时间(例如一周)内的所述电子交易平台下的交易信息，其中包括了买家账户和卖家账户，以及交易记录。

买家账户包括了多个买家身份信息，卖家账户包括一个或多个与买家账户中的买家在预订时间内发生过交易的卖家身份信息。

其次，将买家身份信息和卖家身份信息按照交易关系进行列表，如图2所示。在本示例中，买家和卖家是对多一的关系，用户身份信息为用户ID，即所述买家身份信息为买家ID；所述卖家身份信息为卖家ID。

在该列表中，相同买家和相同卖家的交易对应表中的一行，即是若一个买家和一个卖家发生了多笔交易，只在列表中记录一次。

例如，买家ID为001的买家和卖家ID为001的卖家之间发生过交易，故将两者列在同一行中，作为一笔交易记录；买家ID为002的买家和卖家ID为001的卖家也发生过交易，故将两者列在同一行中，作为一笔交易记录；买家ID为375的买家和卖家ID为001的卖家也发生过交易，故将两者列在同一行中，作为一笔交易记录，以此类推。

接下来，根据卖家ID对列表进行划分，获得相同卖家ID对应的买家ID的聚合数据，当然，在本示例中，因为卖家ID为同一个，故聚合后的数据实质不变。

然后，将买家ID按照升序排列，因为已经是相同卖家ID的聚合数据，故尽管排列顺序不同，买家和卖家的发生交易的关系并不会改变。其中，所述的升序排列是指将买家ID从小到大进行排列，使得对应的行数越小，买家ID越小。

通过上述的升序排列，可获得每个买家ID所对应排列后列表中的行号，例如，买家ID为001的买家对应的行号为2，买家ID为002的买家对应的行号为3，买家ID为375的买家对应的行号为200等。

如此，可计算每个买家ID和对应行号的差值，例如，买家ID为001的买家对应差值为001-2＝-1，买家ID为002的买家对应的差值为002-3＝-1，买家ID为375的买家对应的差值为375-200＝175。

可以看出，买家ID为001的买家和买家ID为002的买家其计算出的差值是相同的，并可通过统计每一组聚合数据中具有相同差值的数量，来识别交互数据中是否存在买家ID连号的买家。例如，当相同差值的数量大于1时，则识别为所述待识别的交互数据中存在买家ID连号的买家。

本领域技术人员可以理解的是，将买家ID替换为买家绑定的手机号，将卖家ID替换为卖家绑定的手机号，因手机号的唯一性和可批量注册性，也可通过上述技术方案识别交互数据中是否存在买家绑定的手机号连号的买家，在此不再赘述。

参图3所示，在提供的另一示例中，与上述示例的区别在于：买家账户包括了多个买家身份信息，卖家账户也包括了多个卖家身份信息。

例如，买家ID为001的买家和卖家ID为001的卖家之间发生过交易，故将两者列在同一行中，作为一笔交易记录；买家ID为002的买家和卖家ID为002的卖家也发生过交易，故将两者列在同一行中，作为一笔交易记录；买家ID为375的买家和卖家ID为133的卖家也发生过交易，故将两者列在同一行中，作为一笔交易记录，以此类推。

对于此示例，由于卖家ID的多样性，就必须根据卖家ID对列表进行划分，获得相同卖家ID对应的买家ID的聚合数据。这也是在对海量数据进行分析时的普遍场景。

以图3示例来看，可按照卖家ID对列表进行划分，以得到卖家ID为001的卖家所对应的买家的聚合数据、卖家ID为002的卖家所对应的买家的聚合数据，以此类推。如此，可避免同一买家或连号买家与不同卖家发生交易所导致的识别连号用户错误。

另外，在本申请一实施方式中，所述装置还包括转换模块70，用于：

将第一类账户的用户身份信息数字化。

如上述图2、图3示例，买家的买家ID为纯数字ID，当然，买家绑定的手机号也肯定是纯数字的。然而，也不能排除在某些平台中买家ID并非纯数字ID，例如，其为字母和数字的组合或者纯字母等非数字ID，此时，为了便于升序排列，需要将买家ID数字化，即是将非数字的元素通过预订规则的转换，以数字体现，例如，将ABC001的买家ID数字化为123001。

进一步地，在本申请一实施方式中，所述处理模块60还用于：

将具有相同差值数量大于或等于预设阈值的聚合数据识别为存在连号用户的异常交互数据。

进一步地，所述处理模块60还用于：

可将识别为存在连号用户的异常交互数据对应的交互数据和/或第一类账户的用户身份信息进行标注。

例如，若相同差值的数量大于或等于5，则将对应的交易记录和/或相应的买家ID打上连号便签，以为后续的虚假交易模型提供评分项，当然，还可为用户关系模型的提供评分项。

本领域技术人员可以理解的是，上述示例中是以买家账户为第一类账户为例，在其他示例中，也可以卖家账户为第一类账户，在此不再赘述。

综上所述，本申请的识别交互数据中连号用户的方法及装置，可方便有效地识别出产生交互数据的连号用户，以便对用户交互行为进行监控，防止同一实体人通过批量注册大量的用户来伪造真实交互数据，使得交互数据更为真实可靠。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的装置，装置和模块的具体工作过程，可以参考前述方法实施方式中的对应过程，在此不再赘述。

在本申请所提供的几个实施方式中，应该理解到，所揭露的装置，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施方式仅仅是示意性的，例如，所述模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个模块或组件可以结合或者可以集成到另一个装置，或一些特征可以忽略，或不执行。另一点，所展示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或模块的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块展示的部件可以是或者也可以不是物理模块，即可以位于一个地方，或者也可以分布到多个网络模块上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施方式方案的目的。

另外，在本申请各个实施方式中的各功能模块可以集成在一个处理模块中，也可以是各个模块单独物理存在，也可以2个或2个以上模块集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用硬件加软件功能模块的形式实现。

上述以软件功能模块的形式实现的集成的模块，可以存储在一个计算机可读取存储介质中。上述软件功能模块存储在一个存储介质中，包括若干指令用以使得一台计算机装置(可以是个人计算机，服务器，或者网络装置等)或处理器(processor)执行本申请各个实施方式所述方法的部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上实施方式仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施方式对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施方式所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施方式技术方案的精神和范围。

Claims (12)

1.一种识别交互数据中连号用户的方法，其特征在于，所述方法包括：

获取待识别的交互数据涉及的第一类账户和第二类账户的用户身份信息，并按照交互关系列表；

根据第二类账户的用户身份信息对所述列表进行划分，以获得至少一组第二类账户中相同用户身份信息所对应的第一类账户的用户身份信息的聚合数据；

将每一组聚合数据中第一类账户的用户身份信息按照升序排列，并获取每一组聚合数据中每一个第一类账户在排列后列表中的行号；

分别计算每一个第一类账户的用户身份信息与获取到的行号的差值；

分别统计每一组聚合数据中具有相同差值的数量；

若相同差值的数量大于1，则识别为所述待识别的交互数据中存在连号用户。

2.根据权利要求1所述的识别交互数据中连号用户的方法，其特征在于，若相同差值的数量大于1，则认为所述待识别的交互数据中存在用户身份信息连号的用户步骤具体包括：

将具有相同差值数量大于或等于预设阈值的聚合数据识别为存在连号用户的异常交互数据。

3.根据权利要求1所述的识别交互数据中连号用户的方法，其特征在于，在分别计算每一个第一类账户的用户身份信息与其对应的行号的差值的步骤前，所述方法还包括：

将第一类账户的用户身份信息数字化。

4.根据权利要求2所述的识别交互数据中连号用户的方法，其特征在于，所述方法还包括：

将识别为存在连号用户的异常交互数据对应的交互数据和/或第一类账户的用户身份信息进行标注。

5.根据权利要求1所述的识别交互数据中连号用户的方法，其特征在于，所述用户身份信息为用户ID或用户绑定的手机号码。

6.根据权利要求1所述的识别交互数据中连号用户的方法，其特征在于，获取交互数据涉及的两类账户的用户身份信息的步骤具体包括：

获取预订时间内预订业务所产生的交互数据涉及的两类账户的用户身份信息，并按照交互关系列表。

7.一种识别交互数据中连号用户的装置，其特征在于，所述装置包括：

数据处理模块，用于获取待识别的交互数据涉及的第一类账户和第二类账户的用户身份信息，并按照交互关系列表；

分组模块，用于根据第二类账户的用户身份信息对所述列表进行划分，以获得至少一组第二类账户中相同用户身份信息所对应的第一类账户的用户身份信息的聚合数据；

排列模块，用于将每一组聚合数据中第一类账户的用户身份信息按照升序排列；

统计模块，用于获取每一组聚合数据中每一个第一类账户在排列后列表中的行号；

计算模块，用于分别计算每一个第一类账户的用户身份信息与获取到的行号的差值，以及分别统计每一组聚合数据中具有相同差值的数量；

处理模块，用于若相同差值的数量大于1，则识别为所述待识别的交互数据中存在连号用户。

8.根据权利要求7所述的识别交互数据中连号用户的装置，其特征在于，所述处理模块还用于：

将具有相同差值数量大于或等于预设阈值的聚合数据识别为存在连号用户的异常交互数据。

9.根据权利要求7所述的识别交互数据中连号用户的装置，其特征在于，所述装置还包括转换模块，用于：

将第一类账户的用户身份信息数字化。

10.根据权利要求8所述的识别交互数据中连号用户的装置，其特征在于，所述处理模块还用于：

将识别为存在连号用户的异常交互数据对应的交互数据和/或第一类账户的用户身份信息进行标注。

11.根据权利要求7所述的识别交互数据中连号用户的装置，其特征在于，所述用户身份信息为用户ID或用户绑定的手机号码。

12.根据权利要求7所述的识别交互数据中连号用户的装置，其特征在于，所述数据处理模块具体用于：

获取预订时间内预订业务所产生的交互数据涉及的两类账户的用户身份信息，并按照交互关系列表。