CN108269107A - 用户信息处理方法及装置 - Google Patents

Abstract

本申请实施例公开了用户信息处理方法及装置，其中，所述方法包括：第一服务器提供第一用户标签信息数据库；接收到第二服务器的活动配置请求时，提供可选的用户特征标签，由所述第二服务器通过选择至少一个用户特征标签的方式确定第一用户集合，并将所述第一用户集合确定为当前创建的活动面向的用户集合；获得所述第二服务器回流的业务数据；根据所述活动参与情况信息生成第一用户的活动信息标签，并将所述第一用户的活动信息标签添加到所述数据库中对应的第一用户所在的信息条目中。通过本申请实施例，能够使得海量业务数据得到有效的利用，提高推送活动信息的精准性，提升用户体验。

Description

用户信息处理方法及装置

技术领域

本申请涉及用户信息处理技术领域，特别是涉及用户信息处理方法及装置。

背景技术

在各种类型的电子商务销售平台中，存在一些专注于垂直领域的销售平台，例如，“阿里旅行”等“航旅”领域的销售平台，等等。在这种垂直领域销售平台中，应用服务器经常举办一些促销活动，商家可以报名参加。例如，机票应用服务器举办的活动为：购买机票可以使用30元优惠券，等等，航空公司等商家在报名参加该活动时，就可以配置一些可以参加该活动的机票，例如，某航空公司从北京到杭州早上6：00的某航班参加该活动，等等。显然，通过参加这种活动有利于帮助提升销量，因此，是销售平台中的比较重要的营销手段。在商家报名参加活动后，应用服务器还可以向用户进行活动信息的推送，以提高关注度，进而转化为销量。

但是，在现有技术中，活动信息的推送通常都是基于海量用户进行的，转化率不高，对与不需要这种活动信息的用户而言也是一种不好的骚扰似的体验；对应用服务器来讲，由于活动中发放的优惠券一般也有数量限制，不能超发，因此，使得这种批量发送也会大幅度降低平台活动效果。另外，由于参加活动的商家众多，参加活动的买家用户数量通常也非常多，因此，活动中会产生大量数据(经统计，在某销售平台中，每天产生的活动相关的数据条数以数十亿计，所占的存储空间为TB级)，面对这种海量数据，难以从中提取出有价值的信息，使得这些数据无法发挥出应有的作用。

总之，如何提高推送活动信息的精准性，在给用户提供最佳用户体验的同时，将活动中产生的海量数据加以有效利用，以用于指导后续的活动开展，成为需要本领域技术人员解决的技术问题。

发明内容

本申请提供了用户信息处理方法及装置，能够使得海量业务数据得到有效的利用，提高推送活动信息的精准性，提升用户体验。

本申请提供了如下方案：

一种用户信息处理方法，包括：

第一服务器提供第一用户标签信息数据库，所述数据库中保存有多个信息条目，各信息条目用于记录各第一用户的用户特征标签信息；

接收到第二服务器的活动配置请求时，提供可选的用户特征标签，由所述第二服务器通过选择至少一个用户特征标签的方式确定第一用户集合，并将所述第一用户集合确定为当前创建的活动面向的用户集合；

获得所述第二服务器回流的业务数据，所述回流的业务数据中包括第一用户的活动参与情况信息；

根据所述活动参与情况信息生成第一用户的活动信息标签，并将所述第一用户的活动信息标签添加到所述数据库中对应的第一用户所在的信息条目中，所述第一用户集合信息以及所述第一用户的活动信息标签用于对活动效果指标进行分析。

一种用户信息处理方法，包括：

第二服务器向第一服务器提交活动配置请求，由所述第一服务器提供可选的用户特征标签；其中，所述第一服务器提供第一用户标签信息数据库，所述数据库中保存有多个信息条目，每个信息条目用于记录一个第一用户关联的用户特征标签信息；

将选中的至少一个用户特征标签提交到第一服务器，由所述第一服务器根据所述至少一个用户特征标签确定第一用户集合；

将所述第一用户集合确定为当前创建的活动面向的用户集合；

将活动过程中产生的业务数据回流给所述第一服务器，所述回流的业务数据中包括第一用户的活动参与情况信息，由所述第一服务器根据所述活动参与情况信息生成第一用户的活动信息标签，并将所述第一用户的活动信息标签添加到所述数据库中对应的第一用户所在的信息条目中。

一种用户信息处理装置，应用于第一服务器，包括：

数据库提供单元，用于提供第一用户标签信息数据库，所述数据库中保存有多个信息条目，各信息条目用于记录各第一用户的用户特征标签信息；

特征标签提供单元，用于接收到第二服务器的活动配置请求时，提供可选的用户特征标签，由所述第二服务器通过选择至少一个用户特征标签的方式确定第一用户集合，并将所述第一用户集合确定为当前创建的活动面向的用户集合；

业务数据获得单元，用于获得所述第二服务器回流的业务数据，所述回流的业务数据中包括第一用户的活动参与情况信息；

活动信息标签生成单元，用于根据所述活动参与情况信息生成第一用户的活动信息标签，并将所述第一用户的活动信息标签添加到所述数据库中对应的第一用户所在的信息条目中，所述第一用户集合信息以及所述第一用户的活动信息标签用于对活动效果指标进行分析。

一种用户信息处理装置，应用于第二服务器，包括：

活动配置请求提交单元，用于向第一服务器提交活动配置请求，由所述第一服务器提供可选的用户特征标签；其中，所述第一服务器提供第一用户标签信息数据库，所述数据库中保存有多个信息条目，每个信息条目用于记录一个第一用户关联的用户特征标签信息；

特征标签提交单元，用于将选中的至少一个用户特征标签提交到第一服务器，由所述第一服务器根据所述至少一个用户特征标签确定第一用户集合；

用户集合创建单元，用于将所述第一用户集合确定为当前创建的活动面向的用户集合；

数据回流单元，用于将活动过程中产生的业务数据回流给所述第一服务器，所述回流的业务数据中包括第一用户的活动参与情况信息，由所述第一服务器根据所述活动参与情况信息生成第一用户的活动信息标签，并将所述第一用户的活动信息标签添加到所述数据库中对应的第一用户所在的信息条目中。

根据本申请提供的具体实施例，本申请公开了以下技术效果：

通过本申请实施例，第一服务器(如画像平台服务器等)可以保存第一用户的用户特征标签数据库，在第二服务器(例如，具体业务方的应用服务器等)需要创建活动时，可以首先进行人群圈定，也即，可以从用户特征标签中选择所需的标签，第一服务器可以基于选择的标签圈定出第一用户集合，这样，第二服务器就可以基于该第一用户集合进行活动的开展，包括向其中的第一用户推送活动信息等等。对于活动过程中产生的业务数据，第二服务器还可以回流给第一服务器，第一服务器可以以标签的形式对用户的活动参与情况信息进行处理以及保存，进而就可以基于这种标签信息对活动效果的各项指标进行分析。分析的结果又可以用于指导第二服务器后续活动中第一用户集合的创建，以此形成闭环。通过上述闭环，为海量业务数据高效处理具有可行性，从而使得海量业务数据得到有效的利用，提高推送活动信息的精准性，提升用户体验。

当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请实施例提供的系统架构的示意图；

图2是本申请实施例提供的第一方法的流程图；

图3是本申请实施例提供的第二方法的流程图；

图4是本申请实施例提供的第一装置的示意图；

图5是本申请实施例提供的第二装置的示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本申请保护的范围。

在本申请实施例中，参见图1，首先可以提供一第一服务器101(例如，在具体实现时，可以提供专门的“画像平台”，该平台可以利用特征标签对具体的用户进行描述，描绘出用户的特点，等等，因此，第一服务器就可以是指这种“画像平台”的服务器)，该第一服务器可以收集大量第一用户(主要是指买家用户、消费者用户等)，包括不限于当前销售平台中的注册用户，航空公司所有历史购票用户，在酒店平台预订过酒店的用户等。然后，可以根据第一用户的个人信息、搜索行为、用户分类、购买行为、特定偏好等，为第一用户打标签，标签可以包括但不限于以下几种：

个人信息，包括性别，年龄段，常住地，家庭人数等；

搜索行为，N天内搜索航线、酒店、度假等数据对象的历史；

用户分类，N个月新用户、半年内活跃用户、365天沉睡用户阿里旅行、淘宝、天猫、支付宝用户等等；

购买行为，购买次数分布、提前购票天数等；

用户偏好，机票产品偏好，购票渠道偏好，等等。

上述标签是根据用户的各类特征生成的，因此，可以称为“用户特征标签”。具体实现时，关于第一服务器收集到的用户信息，以及各第一用户对应的用户特征标签信息可以通过数据库的形式进行保存，例如，在“阿里旅行”平台中，具体的第一用户数据可以保存在GARUDA(一种数据库系统)中。

在保存了上述第一用户画像数据的情况下，平台内的各业务方就可以基于这种用户画像数据进行人群的圈定，进而基于圈定的人群开展活动，这样，有利于提高活动的转化率。其中，所谓的业务方也就是指，平台内提供具体业务的一方，例如，在“阿里旅行”平台内，具体的业务方可以包括“机票”业务、“酒店”业务、“火车票”业务，等等。其中，每个业务方可以看作是一个独立的应用，在各自的应用内部提供各自的数据对象，并且可以基于自己内部的数据对象开展一系列的活动。在本申请实施例中，关于活动的创建、人群的圈定等可以由业务方来执行，为便于描述，本申请实施例中，称为图1中所示的第二服务器102(实际应用中，可以是具体业务方的应用服务器等，通常为多个，图1中仅示出两个作为示意)。例如，假设“机票”业务需要创建一个活动，则机票业务的第二服务器102可以通过第一服务器101进行人群的圈定。此时，第一服务器101可以为第二服务器102提供可选的用户特征标签，例如，可以将各个第一用户的用户特征标签取并集，并作为可选标签提供给第二服务器102，这样，第二服务器102可以结合其创建的活动的特点，选择其中至少一个用户特征标签。例如，可以包括“80后”、“男性”等等。这样，第一服务器101就可以根据这些用户特征标签，从数据库中提取出符合条件的第一用户，组成第一用户集合。也就是说，一个第一用户集合中可以包括多个第一用户的用户ID等标签。每个第二服务器102每次在创建一个新的活动时，都可以通过重新选择用户特征标签的方式，重新确定出一个第一用户集合。这也就是所谓的圈定人群的过程。具体实现时，为了对每个第一用户集合进行区别，每生成一个第一用户集合，可以为其分配唯一的集合ID，每个第一用户集合内的用户ID列表可以保存为一个文件，保存在预置的存储位置。当然，第二服务器102在创建活动时，还可以选择已有的某个第一用户集合，该已有的第一用户集合可以是该第二服务器自己之前为其他活动创建的，还可以是其他第二服务器创建的，等等。

在第二服务器102为其创建的活动圈定了第一用户集合的情况下，第一服务器101还可以将第一用户集合内的第一用户ID列表等信息提供给第二服务器102，这样，第二服务器102还可以向该第一用户集合内的各个第一用户推送关于当前创建的活动的通知消息，包括发放“优惠券”等。也就是说，在本申请实施例中，发放“优惠券”等推送信息不再是针对海量用户进行，而是基于圈定出的第一用户集合范围内进行推送。

在业务方的活动正式展开后，第二服务器102可以收集第一用户对活动的参与情况信息，并回流到第一服务器101，由第一服务器101进行数据分析，例如，可以统计出基于各个第一用户集合开展活动时，活动的效果(包括转化率等)，等等。具体实现时，第一服务器101还可以提供一分布式的数据处理平台，例如，ODPS等，第二服务器102业务数据可以先回流到ODPS进行处理。在这种情况下，第一服务器101在根据第二服务器102选择的用户特征标签生成第一用户集合后，也可以通过GARUDA等数据库，将第一用户集合的人群数据(包括第一用户集合中包括的第一用户id列表等)回流到ODPS，这样，ODPS中的实时计算引擎就可以根据第一服务器101回流的第一用户集合原始数据，以及第二服务器102回流的业务数据(其中主要包括第一用户的活动参与情况信息)，进行统计分析。

在本申请实施例中，考虑到业务方数量众多，开展的活动数量也非常多，再加上用户数量众多等诸多因素，导致回流到第二服务器的业务数据量相当大，因此，本申请实施例提供了相应的解决方案：在获取到第二服务器回流的业务数据后，可以首先根据第一用户的活动参与情况信息生成第一用户的活动信息标签，然后，将所述第一用户的活动信息标签添加到所述数据库中对应的第一用户所在的信息条目中，这样，就可以基于所述第一用户集合以及所述第一用户的活动信息标签，进行活动效果分析。

也就是说，在本申请实施例中，第二服务器可以根据第一用户的用户特征标签来圈定参加活动的人群，在活动正式开展之后，第一服务器还可以将第一用户的活动参加情况信息，作为用户的活动信息标签，保存在数据库中，这样，就可以基于第一用户的活动信息标签对活动的转化率等效果指标进行统计分析，进而，还可以将统计分析的结果提供给第二服务器，以用于指导后续活动中的人群圈定操作，以此形成闭环，随着活动的开展，第一用户的画像数据更清晰，第二服务器也可以从历史活动数据中获得更多的有效信息，提高数据的有效利用率，避免造成浪费。

下面对具体的实现方式进行详细介绍。

实施例一

参见图2，该实施例一首先从第一服务器的角度提供了一种用户信息处理方法，具体的，该方法可以包括以下步骤：

S201：第一服务器提供第一用户标签信息数据库，所述数据库中保存有多个信息条目，每个信息条目用于记录一个第一用户关联的用户特征标签信息；

第一服务器可以在数据库(例如，GARUDA等)中保存第一用户的用户特征标签信息，如前文所述，具体可以根据第一用户的个人信息、搜索行为、用户分类、购买行为、特定偏好等为第一用户打标签。其中，同一个第一用户可以具有多个维度上的多个不同的特征标签，不同的第一用户也可能具有相同的特征标签。

S202：接收到第二服务器的活动配置请求时，提供可选的用户特征标签，由所述第二服务器通过选择至少一个用户特征标签的方式确定第一用户集合，并将所述第一用户集合确定为当前创建的活动面向的用户集合；

在本申请实施例中，业务方在创建一个活动时，可以利用第一服务器提供的数据库进行人群圈定。具体的，可以为业务方提供操作界面，第二服务器可以通过该操作界面向第一服务器提交活动配置请求，此时，第一服务器就可以将可选的用户特征标签展示在界面中，这样，第二服务器可以从中选择自己所需的至少一个用户特征标签。进而，第一服务器就可以根据第二服务器选择的至少一个用户特征标签，生成第一用户集合。具体的，第二服务器可以从中选择任何一个标签，将带有该标签的第一用户筛选出来，组成第一用户集合。另外，也可以支持选择多个标签，将具有每个标签的用户做合并，取交集，获得具有所有所选择标签的第一用户集合。

在确定出第一用户集合后，可以将第一用户集合中包括的第一用户ID等列表信息提供给第二服务器，这样，第二服务器就可以向该第一用户集合中的各个第一用户推送关于活动的通知消息，或者，还可以向该第一用户集合中的各个用户发放“优惠券”等，以便第一用户在参加活动时使用。

需要说明的是，在具体实现时，不同的第二服务器针对不同的活动，都可能创建出不同的第一用户集合，为了便于管理以及区分，可以分别为各个第一用户集合生成各自对应的唯一性标识，例如第一用户集合ID等。第二服务器可以通过调用第一服务器提供的API等方式，获得第一用户集合的ID，并且，还可以通过调用其他的API，来获得第一用户集合的具体数据文件，其中就可以包括第一用户ID列表等。

另外需要说明的是，在本申请实施例中，在第二服务器创建了一个第一用户集合后，后续可以会具有数据分析需求，此时，第一服务器可以针对该第一用户集合中各个第一用户对活动的参加情况进行分析，给出相应的分析结果，包括哪些特征标签的第一用户对应的活动转化率最高，等等。但在实际应用中，也可能存在不需要分析的情况，也就是说，第二服务器在圈定出某个第一用户集合后，可能只是想用于当前创建的活动，后续不再使用，也不需要针对相关的活动参与情况进行统计分析。为此，在本申请实施例中，还可以为第二服务器提供用于对第一用户集合进行登记的操作选项，如果第二服务器在圈定出某个第一用户集合后，需要由第一服务器执行后续的统计分析操作，则可以对该第一用户集合进行登记。相应的，第一服务器可以将该第一用户集合关联的人群数据(也即第一用户ID列表)进行记录，在统一由OPDS进行统计分析的情况下，还可以将第一用户集合的具体人群数据，通过GARUDA回流到OPDS，这样，后续第二服务器产生的业务数据也回流到ODPS后，就可以在ODPS中进行具体的统计分析操作。当然，如果第二服务器在圈定出某第一用户集合后，不需要针对该第一用户集合以及其中的第一用户对象对应活动的参与情况进行后续的统计分析操作，则可以不必对该第一用户集合进行登记，相应的，第一服务器也可以不必执行将第一用户集合中的人群数据回流到ODPS的相关操作。

S203：获得第二服务器回流的业务数据，所述回流的业务数据中包括第一用户的活动参与情况信息；

第二服务器在从第一服务器获取到第一用户集合的人群数据后，可以基于该第一用户集合进行活动信息的推送等操作，在活动过程中，或者结束之后，可以向第一服务器回流具体的业务数据，其中主要可以包括第一用户的活动参与情况信息，以用于对该第一用户集合对于该活动而言带来的转化率等效果指标进行分析。

其中，具体实现时，第一用户的活动参与情况信息具体可以包括：第一用户所参与活动的活动标识，以及参加该活动时所属的第一用户集合标识，当然，在实际应用中，一个活动可能会分为多个不同的活动阶段，因此，在活动参与情况信息中还可以包括活动阶段标识等。

需要说明的是，在实际应用中，业务方通常会有多个，对应的第二服务器也是多个，各个第二服务器将各自系统中产生的业务数据回流到第一服务器提供的ODPS等分布式计算平台中，再由ODPS进行统计分析。而各个第二服务器产生的业务数据通常会由数据表的方式来保存，并且，数据表中包括的字段数量、字段名称等等，通常是由第二服务器根据具体的业务特点来确定，关于第一用户对活动的参与情况信息通常是保存在这些字段中。因此，ODPS在收到回流的业务数据时，可以从第二服务器回流的数据表中提取出所需字段上的对应的数据。为此，在实际应用中，为了使得ODPS能够正确提取出所需的业务数据，还可以预先与各个业务方约定标准的字段名称等信息。例如，这些字段可以包括第一用户ID、活动ID、活动阶段ID、第一用户集合ID等，当然，在优选的实现方案中，还可以包括第一用户集合的创建时间(对此，在后文中会有介绍)，对于以上字段，可以与业务方约定好各字段的名称，第二服务器在生成业务数据表时，对于这些字段，可以按照该约定好的方式设定字段名称，如果业务数据表中还包括其他字段，则可以不做限制。这样，ODPS就可以根据这种约定好的字段名称，从业务数据表中提取出上述各字段的数据，这些数据是与第一用户的活动参与情况相关的。

例如，可以将第一用户ID字段名称定义为user_id，活动ID定义为activity_id，活动阶段id可以定义为phase_id，第一用户集合ID可以定义为crowd_id，等等。例如，假设某第二服务器回流的某条业务数据中，user_id字段为甲，activity_id为A，phase_id为1，crowd_id为10001，则证明用户甲参加了活动A的1阶段，并且该活动A关联的第一用户集合为10001，等等。当然，在实际应用中，具体的字段名称定义方式可以有多种，以上仅用于举例说明，并不是本申请保护范围的限制。

另外需要说明的是，业务方的第二服务器回流业务数据的时机可以有多种，例如，可以是在每产生一条业务数据，就实时添加到业务数据表中，并实时回流到第一服务器提供的指定位置，或者还可以在活动结束后，再统一将业务数据表进行回流，等等。另外，业务方的第二服务器还可通过多种方式将需要回流的业务数据导入至画像平台用于后续分析，例如，可以包括本地日志、MetaQ消息队列、回写API、TT Agent、MySQL数据库回流等。业务方可根据自己的业务需求选择合适的方式将数据回流至第一服务器，并且，无论采用具体何种回流方式，业务数据最终都可以被写入ODPS。其中，关于各种回流方式的具体实现，可以参见已有技术的介绍，这里不再详述。

S204：根据所述活动参与情况信息生成第一用户的活动信息标签，并将所述第一用户的活动信息标签添加到所述数据库中对应的第一用户所在的信息条目中，所述第一用户集合以及所述第一用户的活动信息标签用于对活动效果指标进行分析。

画像平台一侧的ODPS在收到第二服务器回流的业务数据后，可以对业务数据进行处理，在本申请实施例中，具体的处理方式可以是，根据业务数据中包括的第一用户的活动参与情况信息生成第一用户的活动信息标签。也就是说，关于第一用户的活动参与情况信息，可以以用户标签的形式进行保存，为了与“用户特征标签”相区别，这里称为“活动信息标签”。这样，后续的具体的分析操作可以基于这种活动信息标签来进行，可以简化分析的流程。

具体在根据活动参与情况信息生成第一用户的活动信息标签时，可以有多种实现方式。例如，在活动参与情况信息包括第一用户所参与活动的活动标识，以及参加该活动时所属的第一用户集合标识的情况下，可以将所述活动标识以及第一用户集合标识进行组合，生成所述活动信息标签，也就是说，每个活动信息标签可以由活动id，第一用户集合id组合而成，例如act_id-crowd_id。如果某第一用户带有上述标签，则证明该第一用户曾经被选入该第一用户集合，并且参加了该第一用户集合对应的该活动。当然，在实际应用中，如果还将活动划分为多个阶段，并且活动参与情况信息中还包括活动阶段id，则活动信息标签还可以包括活动阶段id，例如，act_id-phase_id-crowd_id。

具体实现时，由于系统中的业务方数量可能会很多，每个业务方又可能同时开展多个活动，因此，一个第一用户通常会对应很多个活动信息标签，为此，具体在生成活动信息标签之前，可以首先对第二服务器回流的业务数据进行“数据清洗”。所谓的数据清洗也就是，从回流的业务数据中提取出所需字段上的数据，并按照预置的标准格式进行整理，其中至少包括第一用户id、活动id以及第一用户集合id。例如，(user_id_111，act_id-crowd_id-phase_index)，当然，在一种优选的实现方案中，这里整理的数据中还可以包括第一用户集合的创建时间信息，也就是说，整理出的标准格式的数据可以为(user_id_111,act_id-crowd_id-phase_index,2016-01-01 12:12:12)，等等。

在按照上述标准格式对业务数据进行整理后，可以得到多条上述格式的数据，进而，就可以从第一用户标识维度对所述整理后的数据进行分组，获得同一第一用户标识对应的多个活动信息标签(act_id-phase_id-crowd_id)。

在生成第一用户的活动信息标签后，可以将这种信息从ODPS回流到数据库中，例如GARUDA，这样，就可以将第一用户的活动信息标签添加到所述数据库中对应的第一用户所在的信息条目中，后续就可以基于所述第一用户集合以及所述第一用户的活动信息标签，对活动效果指标进行分析。

其中，如前文所述，由于业务方数量较多，活动数量也很多，并且，同一第一用户通常会参加多个活动，因此，如果不进行特殊处理，则一个第一用户的活动信息标签list会很长，这样不利于进行数据查询等处理。并且，随着时间的推移，第一用户的活动信息标签list会变得越来越长，此时，不仅不利于查询，而且其中可能会包含了一些失效的数据，但是却难以处理。例如，对于一个第一用户而言，其活动参与情况信息可能仅在一定的时间内，对后续的活动开展等是有意义的，例如一年内，等等，再以前的历史数据，可能参考价值已经很低，甚至没有参考价值，等等。

为此，在本申请的优选实施例中，还可以进行以下处理：预先为所述活动信息标签设置的数据保存周期，并按照该数据保存周期的时间长度，将数据保存周期划分为多个时间段，数据库中每个信息条目中可以包括多个活动信息标签子字段，每个子字段对应一个所述时间段。例如，数据保存周期为一年，则可以划分为12个时间段，一年中的每个月为一个时间段，这样，活动信息标签可以对应12个子字段。并且，在从业务方回流的业务数据中提取活动参与情况信息时，还可以提取出第一用户集合的创建时间信息，这样，每个活动信息标签还可以与各种的第一用户集合创建时间信息相对应，在将活动标签信息添加到数据库中时，可以按照所述活动信息标签对应的第一用户集合创建时间所属的目标时间段，将所述第一用户对应的活动信息标签添加到该目标时间段所对应的活动信息标签子字段。

例如，假设从业务方回流的业务数据库中提取出某第一用户的信息包括：(user_id_111,act_id-crowd_id-phase_index,2016-01-01 12:12:12)，可见该用户111参加了某活动，并且，该活动对应的第一用户集合创建于2016-01-0112:12:12，也就是说，该第一用户集合创建时间所属的目标时间段为1月，因此，可以将该活动信息标签添加到该第一用户所在条目中，“1月”所在的子字段中。这样，第一用户的活动信息标签可以被拆分成12个子list，每个第一用户的活动信息标签都可以包括12列，每列上可以包括多个活动信息标签，代表第一用户在对应月份上参加的活动信息。例如，具体的保存形式可以为：

表1

可见，每个第一用户可以在多个月份对应的子字段中包括一个或多个活动信息标签，分别代表该第一用户在对应月份上参加的活动情况，如果在某个月份的子字段中没有活动标签，则代表该第一用户在对应月份中没有参加任何活动。

由于活动信息标签列按照自然月份纵向分割成12列，每一列代表对应月份的活动信息标签，因此，时间超过一年后或者更久，每一列上的活动信息标签值个数也可能会增长到很大。所以在本申请实施例中，画像平台数据库可以只提供一年之内(以人群创建时间为准)的活动效果分析，超过一年的活动信息标签数据可以固化到MySQL等位置进行保存，以静态图标的方式提供服务。而12列活动标签按照一年的周期轮转使用，到达下一个周期后，覆盖上一个周期对应的列值。

当然，在实际应用中，在对保存周期进行分割时，还可以拆分成更多或者更少的时间段，例如，按照每周进行分割，或者按照每个季度进行分割等等，另外，保存周期的时间长度也可以是长于或者短于一年的其他值，这里均不作限定。

总之，在通过上述方式将第一用户参加活动的相关信息采用标签的方式保存在第一用户标签数据库中之后，就可以基于这种标签信息，根据第一用户集合内各第一用户对对应活动的参与情况，对活动效果进行分析。具体的，可以以第一用户集合对应的各个用户特征标签为单位，统计第一用户的活动参与情况信息，例如，统计出各年龄段的第一用户为活动带来的平均转化率，等等。或者，还可以以第一用户集合为单位，统计第一用户集合内第一用户的活动参与情况信息，例如，统计出该第一用户集合内，参加活动的第一用户的比例，等等。统计出的结果可以提供给对应业务方的第二服务器，例如，假设某第一用户集合是某业务方为某活动创建的，则在得到统计分析结果之后可以提供给该业务方，为其后续创建新活动做指导。例如，某活动中，25至35年龄段的用户对应的转化率最高，35至45年龄段的第一用户几乎没有带来转化率，则在下次举办类似的活动时，可以不再将35至45年龄段的第一用户圈定到集合中，等等。

另外，关于分析效果信息，还可以是在接收到新的活动配置请求时提供给第二服务器，也就是说，如果某业务方需要为新创建的活动圈定第一用户集合，则在进入到相应的界面后，可以将已有的第一用户集合及其对应的活动效果信息提供给当前业务方的第二服务器，这样，第二服务器可以根据所述活动分析效果，为新创建的活动进行用户特征标签的选择。或者，还可以直接选择其中一个已有的第一用户集合，并基于该第一用户集合开展当前的活动，等等。

总之，通过本申请实施例，第一服务器可以保存第一用户的用户特征标签数据库，在业务方第二服务器需要创建活动时，可以首先进行人群圈定，也即，可以从用户特征标签中选择所需的标签，第一服务器可以基于选择的标签圈定出第一用户集合，这样，第二服务器就可以基于该第一用户集合进行活动的开展，包括向其中的第一用户推送活动信息等等。对于活动过程中产生的业务数据，第二服务器还可以回流给第一服务器，第一服务器可以以标签的形式对用户的活动参与情况信息进行处理以及保存，进而就可以基于这种标签信息对活动效果的各项指标进行分析。分析的结果又可以用于指导第二服务器后续活动中第一用户集合的创建，以此形成闭环。通过上述闭环，为海量业务数据高效处理具有可行性，从而使得海量业务数据得到有效的利用，提高推送活动信息的精准性，提升用户体验。

实施例二

该实施例二是与实施例一相对应的，从第二服务器的角度提供了一种用户信息处理方法，具体的，参见图3，该方法可以包括以下步骤：

S301：第二服务器向第一服务器提交活动配置请求，由所述第一服务器提供可选的用户特征标签；其中，所述第一服务器提供第一用户标签信息数据库，所述数据库中保存有多个信息条目，每个信息条目用于记录一个第一用户关联的用户特征标签信息；

S302：将选中的至少一个用户特征标签提交到第一服务器，以便所述第一服务器根据所述至少一个用户特征标签确定第一用户集合；

S303：将所述第一用户集合确定为当前创建的活动面向的用户集合；

S304：将活动过程中产生的业务数据回流给所述第一服务器，所述回流的业务数据中包括第一用户的活动参与情况信息，由所述第一服务器根据所述活动参与情况信息生成第一用户的活动信息标签，并将所述第一用户的活动信息标签添加到所述数据库中对应的第一用户所在的信息条目中。

由于该实施例二是与实施例一相对应的，并且相关的具体实现在实施例一中已经进行了介绍，因此，可以参见实施例一中的记载，这里不再赘述。

与实施例一相对应，本申请实施例还提供了一种用户信息处理装置，参见图4，该装置应用于第一服务器，包括：

数据库提供单元401，用于提供第一用户标签信息数据库，所述数据库中保存有多个信息条目，各信息条目用于记录各第一用户的用户特征标签信息；

特征标签提供单元402，用于接收到第二服务器的活动配置请求时，提供可选的用户特征标签，由所述第二服务器通过选择至少一个用户特征标签的方式确定第一用户集合，并将所述第一用户集合确定为当前创建的活动面向的用户集合；

业务数据获得单元403，用于获得所述第二服务器回流的业务数据，所述回流的业务数据中包括第一用户的活动参与情况信息；

活动信息标签生成单元404，用于根据所述活动参与情况信息生成第一用户的活动信息标签，并将所述第一用户的活动信息标签添加到所述数据库中对应的第一用户所在的信息条目中，所述第一用户集合信息以及所述第一用户的活动信息标签用于对活动效果指标进行分析。

其中，所述第一用户的活动参与情况信息，包括：第一用户所参与活动的活动标识，以及参加该活动时所属的第一用户集合标识；此时，活动信息标签生成单元具体可以用于：

将所述活动标识以及第一用户集合标识进行组合，生成所述活动信息标签。

具体实现时，所述第二服务器可以为多个，其中，所述第二服务器回流的业务数据包括：按照服务器统一定义的字段标识提供的对应字段上的业务数据内容，所述预置字段包括：第一用户标识，第一用户集合标识以及活动标识；

此时，活动信息标签生成单元具体可以包括：

整理子单元，用于从各个第二服务器回流的业务数据中分别提取出第一用户标识，第一用户集合标识以及活动标识，并按照预置的标准格式进行整理；

分组子单元，用于从第一用户标识维度对所述整理后的数据进行分组，获得同一第一用户标识对应的多个活动信息标签，以便将所述多个活动信息标签添加到所述数据库中对应的第一用户所在的信息条目中。

具体实现时，可以按照预先为所述活动信息标签设置的数据保存周期的时间长度，将所述数据保存周期划分为多个时间段；所述数据库中每个信息条目中包括多个活动信息标签子字段，每个子字段对应一个所述时间段；

所述第二服务器回流的数据还包括：第一用户集合创建时间，所述从第二服务器回流的业务数据中提取出的数据还包括所述第一用户集合创建时间信息；

所述装置还可以包括：

时间确定单元，用于在为第一用户生成活动信息标签时，确定所述活动信息标签对应的第一用户集合创建时间；

所述活动信息标签生成单元具体用于：

按照所述活动信息标签对应的第一用户集合创建时间所属的目标时间段，将所述第一用户对应的活动信息标签添加到该目标时间段所对应的活动信息标签子字段。

另外，该装置还可以包括：

固化保存单元，用于在一个数据保存周期期满后，将该数据保存周期内保存的各第一用户在各子字段上的活动信息标签进行固化保存，以便以静态信息的方式提供给第二服务器。

再者，该装置还可以包括：

覆盖保存单元，用于进入新的数据保存周期后，利用新获得的活动信息标签将对应子字段上一数据保存周期的数据进行覆盖处理。

分析单元，用于根据第一用户集合内各第一用户对对应活动的参与情况，对活动效果进行分析。

具体的在进行分析时，可以以第一用户集合对应的各个用户特征标签为单位，统计第一用户的活动参与情况信息。

或者，以第一用户集合为单位，统计第一用户集合内第一用户的活动参与情况信息。

另外，该装置还可以包括：

分析效果提供单元，用于接收到新的活动配置请求时，将活动分析结果提供给第二服务器，由所述第二服务器根据所述活动分析效果，为新创建的活动进行用户特征标签的选择。

与实施例二相对应，本申请实施例还提供了一种用户信息处理装置，参见图5，该装置应用于第二服务器，包括：

活动配置请求提交单元501，用于向第一服务器提交活动配置请求，由所述第一服务器提供可选的用户特征标签；其中，所述第一服务器提供第一用户标签信息数据库，所述数据库中保存有多个信息条目，每个信息条目用于记录一个第一用户关联的用户特征标签信息；

特征标签提交单元502，用于将选中的至少一个用户特征标签提交到第一服务器，由所述第一服务器根据所述至少一个用户特征标签确定第一用户集合；

用户集合创建单元503，用于将所述第一用户集合确定为当前创建的活动面向的用户集合；

数据回流单元504，用于将活动过程中产生的业务数据回流给所述第一服务器，所述回流的业务数据中包括第一用户的活动参与情况信息，由所述第一服务器根据所述活动参与情况信息生成第一用户的活动信息标签，并将所述第一用户的活动信息标签添加到所述数据库中对应的第一用户所在的信息条目中。

通过本申请实施例，第一服务器(如画像平台服务器等)可以保存第一用户的用户特征标签数据库，在第二服务器(例如，具体业务方的应用服务器等)需要创建活动时，可以首先进行人群圈定，也即，可以从用户特征标签中选择所需的标签，第一服务器可以基于选择的标签圈定出第一用户集合，这样，第二服务器就可以基于该第一用户集合进行活动的开展，包括向其中的第一用户推送活动信息等等。对于活动过程中产生的业务数据，第二服务器还可以回流给第一服务器，第一服务器可以以标签的形式对用户的活动参与情况信息进行处理以及保存，进而就可以基于这种标签信息对活动效果的各项指标进行分析。分析的结果又可以用于指导第二服务器后续活动中第一用户集合的创建，以此形成闭环。通过上述闭环，为海量业务数据高效处理具有可行性，从而使得海量业务数据得到有效的利用，提高推送活动信息的精准性，提升用户体验。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上对本申请所提供的用户信息处理方法及装置，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处。综上所述，本说明书内容不应理解为对本申请的限制。

Claims (13)

1.一种用户信息处理方法，其特征在于，包括：

第一服务器提供第一用户标签信息数据库，所述数据库中保存有多个信息条目，各信息条目用于记录各第一用户的用户特征标签信息；

接收到第二服务器的活动配置请求时，提供可选的用户特征标签，由所述第二服务器通过选择至少一个用户特征标签的方式确定第一用户集合，并将所述第一用户集合确定为当前创建的活动面向的用户集合；

获得所述第二服务器回流的业务数据，所述回流的业务数据中包括第一用户的活动参与情况信息；

根据所述活动参与情况信息生成第一用户的活动信息标签，并将所述第一用户的活动信息标签添加到所述数据库中对应的第一用户所在的信息条目中，所述第一用户集合信息以及所述第一用户的活动信息标签用于对活动效果指标进行分析。

2.根据权利要求1所述的方法，其特征在于，所述第一用户的活动参与情况信息，包括：第一用户所参与活动的活动标识，以及参加该活动时所属的第一用户集合标识；

所述根据所述活动参与情况信息生成第一用户的活动信息标签，包括：

将所述活动标识以及第一用户集合标识进行组合，生成所述活动信息标签。

3.根据权利要求2所述的方法，其特征在于，所述第二服务器为多个，所述第二服务器回流的业务数据包括：按照服务器统一定义的字段标识提供的对应字段上的业务数据内容，所述预置字段包括：第一用户标识，第一用户集合标识以及活动标识；

所述将所述活动标识以及第一用户集合标识进行组合，生成所述活动信息标签，包括：

从各个第二服务器回流的业务数据中分别提取出第一用户标识，第一用户集合标识以及活动标识，并按照预置的标准格式进行整理；

从第一用户标识维度对所述整理后的数据进行分组，获得同一第一用户标识对应的多个活动信息标签，以便将所述多个活动信息标签添加到所述数据库中对应的第一用户所在的信息条目中。

4.根据权利要求3所述的方法，其特征在于，按照预先为所述活动信息标签设置的数据保存周期的时间长度，将所述数据保存周期划分为多个时间段；所述数据库中每个信息条目中包括多个活动信息标签子字段，每个子字段对应一个所述时间段；

所述第二服务器回流的数据还包括：第一用户集合创建时间，所述从第二服务器回流的业务数据中提取出的数据还包括所述第一用户集合创建时间信息；

所述方法还包括：

在为第一用户生成活动信息标签时，确定所述活动信息标签对应的第一用户集合创建时间；

所述将所述多个活动信息标签添加到所述数据库中对应的第一用户所在的信息条目中，包括：

按照所述活动信息标签对应的第一用户集合创建时间所属的目标时间段，将所述第一用户对应的活动信息标签添加到该目标时间段所对应的活动信息标签子字段。

5.根据权利要求4所述的方法，其特征在于，还包括：

在一个数据保存周期期满后，将该数据保存周期内保存的各第一用户在各子字段上的活动信息标签进行固化保存，以便以静态信息的方式提供给第二服务器。

6.根据权利要求5所述的方法，其特征在于，还包括：

进入新的数据保存周期后，利用新获得的活动信息标签将对应子字段上一数据保存周期的数据进行覆盖处理。

7.根据权利要求2所述的方法，其特征在于，所述方法还包括：

根据第一用户集合内各第一用户对对应活动的参与情况，对活动效果进行分析。

8.根据权利要求7所述的方法，其特征在于，所述根据第一用户集合内各第一用户对对应活动的参与情况，对活动效果进行分析，包括：

以第一用户集合对应的各个用户特征标签为单位，统计第一用户的活动参与情况信息。

9.根据权利要求7所述的方法，其特征在于，所述根据第一用户集合内各第一用户对对应活动的参与情况，对活动效果进行分析，包括：

以第一用户集合为单位，统计第一用户集合内第一用户的活动参与情况信息。

10.根据权利要求7所述的方法，其特征在于，还包括：

接收到新的活动配置请求时，将活动分析结果提供给第二服务器，由所述第二服务器根据所述活动分析效果，为新创建的活动进行用户特征标签的选择。

11.一种用户信息处理方法，其特征在于，包括：

第二服务器向第一服务器提交活动配置请求，由所述第一服务器提供可选的用户特征标签；其中，所述第一服务器提供第一用户标签信息数据库，所述数据库中保存有多个信息条目，每个信息条目用于记录一个第一用户关联的用户特征标签信息；

将选中的至少一个用户特征标签提交到第一服务器，由所述第一服务器根据所述至少一个用户特征标签确定第一用户集合；

将所述第一用户集合确定为当前创建的活动面向的用户集合；

将活动过程中产生的业务数据回流给所述第一服务器，所述回流的业务数据中包括第一用户的活动参与情况信息，由所述第一服务器根据所述活动参与情况信息生成第一用户的活动信息标签，并将所述第一用户的活动信息标签添加到所述数据库中对应的第一用户所在的信息条目中。

12.一种用户信息处理装置，其特征在于，应用于第一服务器，包括：

数据库提供单元，用于提供第一用户标签信息数据库，所述数据库中保存有多个信息条目，各信息条目用于记录各第一用户的用户特征标签信息；

特征标签提供单元，用于接收到第二服务器的活动配置请求时，提供可选的用户特征标签，由所述第二服务器通过选择至少一个用户特征标签的方式确定第一用户集合，并将所述第一用户集合确定为当前创建的活动面向的用户集合；

业务数据获得单元，用于获得所述第二服务器回流的业务数据，所述回流的业务数据中包括第一用户的活动参与情况信息；

活动信息标签生成单元，用于根据所述活动参与情况信息生成第一用户的活动信息标签，并将所述第一用户的活动信息标签添加到所述数据库中对应的第一用户所在的信息条目中，所述第一用户集合信息以及所述第一用户的活动信息标签用于对活动效果指标进行分析。

13.一种用户信息处理装置，其特征在于，应用于第二服务器，包括：

活动配置请求提交单元，用于向第一服务器提交活动配置请求，由所述第一服务器提供可选的用户特征标签；其中，所述第一服务器提供第一用户标签信息数据库，所述数据库中保存有多个信息条目，每个信息条目用于记录一个第一用户关联的用户特征标签信息；

特征标签提交单元，用于将选中的至少一个用户特征标签提交到第一服务器，由所述第一服务器根据所述至少一个用户特征标签确定第一用户集合；

用户集合创建单元，用于将所述第一用户集合确定为当前创建的活动面向的用户集合；

数据回流单元，用于将活动过程中产生的业务数据回流给所述第一服务器，所述回流的业务数据中包括第一用户的活动参与情况信息，由所述第一服务器根据所述活动参与情况信息生成第一用户的活动信息标签，并将所述第一用户的活动信息标签添加到所述数据库中对应的第一用户所在的信息条目中。