CN107918882A - 提供数据对象信息的方法及装置 - Google Patents

Abstract

本申请实施例公开了提供数据对象信息的方法及装置，其中，所述方法可以包括：服务器接收第二用户客户端的数据对象搜索请求，并确定符合条件的至少一个数据对象；确定各数据对象是否关联预置活动，所述预置活动由所述数据对象对应的第一用户客户端进行配置，所述预置活动还关联有面向的用户范围信息以及资源相关信息；如果所述数据对象关联有预置活动，则判断所述第二用户客户端关联的目标第二用户是否属于所述用户范围；如果所述目标第二用户属于所述用户范围，则根据所述预置活动关联的资源相关信息对对应的数据对象进行处理。通过本申请实施例，可以提高页面转化率，并提高活动效率，提升用户体验。

Description

提供数据对象信息的方法及装置

技术领域

本申请涉及数据对象信息处理技术领域，特别是涉及提供数据对象信息的方法及装置。

背景技术

在各种类型的电子商务销售平台中，存在一些专注于垂直领域的销售平台，例如，“阿里旅行”等“航旅”领域的销售平台，等等。在这种垂直领域销售平台中，平台方经常举办一些促销活动，商家可以报名参加。例如，平台方举办的活动为：购买机票可以使用30元优惠券，等等，商家在报名参加该活动时，就可以配置一些可以参加该活动的机票，例如，从北京到杭州早上6：00的某航班，可以参加该活动，等等。显然，通过参加这种活动，可以提升销量或者关注度，因此，是销售平台中的比较重要的营销手段。

但是，在上述方式下，由于活动是由平台方举办的，商家只能被动的参加，因此，至少存在以下问题：由于商家有很多，因此，平台方不可能针对每个商家都配置个性化的活动，基本是各个商家都一样的简单粗暴方式。这就导致活动的规则等可能并不适合所有商家或者所有商品，使得一些商家或者一些商品无法参加这种活动，也就无法通过这种方式来提升销量或者关注度。并且，由于每次开展活动都需要平台方的运营人员进行配置，也会存在效率低下等问题。另外，为了提高活动的效果，平台通常还会向消费者用户推送关于活动中的优惠等信息，甚至提前将“优惠券”等发放给消费者用户。但是，这种信息的推送通常是面向海量用户进行的，实际的转化率不高，对一些用户还可能造成一种骚扰似的体验。并且，优惠券的发放通常还有数量限制，因此，这种海量的发送方式，也会影响到实际的活动效果。从系统资源角度而言，将一些信息发送给实际上并不需要的用户的过程，也意味着对系统资源造成了浪费。

因此，如何在提升活动配置的灵活性，满足商家的个性化需求，并节省系统资源，成为需要本领域技术人员解决的技术问题。

发明内容

本申请提供了提供数据对象信息的方法及装置，可以提高页面转化率，并提高活动效率，提升用户体验。

本申请提供了如下方案：

一种数据对象信息处理方法，包括：

服务器接收到第一用户客户端提交的活动配置请求时，提供可选的用户标签，以便从所述可选的用户标签中选择用于建立第二用户集合的至少一个用户标签；

接收所述第一用户客户端提交的活动配置信息，所述活动配置信息中包括所述至少一个用户标签、参加活动的数据对象信息以及活动关联的资源相关信息；

保存所述活动配置信息，以便在接收到第二用户客户端的访问请求时，根据所述活动配置信息，向所述第二用户客户端提供数据对象信息。

一种数据对象信息处理方法，包括：

第一用户客户端提供活动配置界面，所述配置界面中包括候选的用户标签；

确定被选中的至少一个用户标签；

确定参加活动的数据对象信息，以及活动关联的资源相关信息；

将所述至少一个用户标签、参加活动的数据对象信息以及所述资源相关信息作为活动配置信息提交到服务器，以便所述服务器根据所述活动规则向第二用户客户端提供数据对象信息页面。

一种提供数据对象信息的方法，包括：

服务器接收第二用户客户端的数据对象搜索请求，并确定符合条件的至少一个数据对象；

确定各数据对象是否关联预置活动，所述预置活动由所述数据对象对应的第一用户客户端进行配置，所述预置活动还关联有面向的用户范围信息以及资源相关信息；

如果所述数据对象关联有预置活动，则判断所述第二用户客户端关联的目标第二用户是否属于所述用户范围；

如果所述目标第二用户属于所述用户范围，则根据所述预置活动关联的资源相关信息对对应的数据对象进行处理。

一种提供数据对象信息的方法，包括：

第二用户客户端接收数据对象搜索请求；

将所述请求提交到服务器，以便所述服务器确定符合条件的至少一个数据对象，并确定各数据对象是否关联预置活动，所述预置活动由所述数据对象对应的第一用户客户端进行配置，所述预置活动还关联有面向的用户范围信息以及资源相关信息；如果所述数据对象关联有预置活动，则判断所述第二用户客户端关联的目标第二用户是否属于所述用户范围，如果所述目标第二用户属于所述用户范围，则根据所述预置活动关联的资源相关信息对对应的数据对象进行处理；

根据服务器返回的响应提供数据对象信息。

一种数据对象信息处理装置，应用于服务器，包括：

用户标签提供单元，用于接收到第一用户客户端提交的活动配置请求时，提供可选的用户标签，以便从所述可选的用户标签中选择用于建立第二用户集合的至少一个用户标签；

活动配置信息接收单元，用于接收所述第一用户客户端提交的活动配置信息，所述活动配置信息中包括所述至少一个用户标签、参加活动的数据对象信息以及活动关联的资源相关信息；

保存单元，用于保存所述活动配置信息，以便在接收到第二用户客户端的访问请求时，根据所述活动配置信息，向所述第二用户客户端提供数据对象信息。

一种数据对象信息处理装置，应用于第一用户客户端，包括：

配置界面提供单元，用于提供活动配置界面，所述配置界面中包括候选的用户标签；

用户标签确定单元，用于确定被选中的至少一个用户标签；

数据对象信息确定单元，用于确定参加活动的数据对象信息，以及活动关联的资源相关信息；

提交单元，用于将所述至少一个用户标签、参加活动的数据对象信息以及所述资源相关信息作为活动配置信息提交到服务器，以便所述服务器根据所述活动规则向第二用户客户端提供数据对象信息页面。

一种提供数据对象信息的装置，应用于服务器，包括：

数据对象确定单元，用于接收第二用户客户端的数据对象搜索请求，并确定符合条件的至少一个数据对象；

活动确定单元，用于确定各数据对象是否关联预置活动，所述预置活动由所述数据对象对应的第一用户客户端进行配置，所述预置活动还关联有面向的用户范围信息以及资源相关信息；

判断单元，用于如果所述数据对象关联有预置活动，则判断所述第二用户客户端关联的目标第二用户是否属于所述用户范围；

处理单元，用于如果所述目标第二用户属于所述用户范围，则根据所述预置活动关联的资源相关信息对对应的数据对象进行处理。

一种提供数据对象信息的装置，应用于第二用户客户端，包括：

搜索请求接收单元，用于接收数据对象搜索请求；

请求提交单元，用于将所述请求提交到服务器，以便所述服务器确定符合条件的至少一个数据对象，并确定各数据对象是否关联预置活动，所述预置活动由所述数据对象对应的第一用户客户端进行配置，所述预置活动还关联有面向的用户范围信息以及资源相关信息；如果所述数据对象关联有预置活动，则判断所述第二用户客户端关联的目标第二用户是否属于所述用户范围，如果所述目标第二用户属于所述用户范围，则根据所述预置活动关联的资源相关信息对对应的数据对象进行处理；

数据对象信息提供单元，用于根据服务器返回的响应提供数据对象信息。

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

通过本申请实施例，可以由第一用户客户端自定配置活动信息，并且，除了活动中的资源相关信息可以灵活配置之外，还可以通过用户标签的方式来配置活动面向的第二用户范围信息，这样，在保证平台中的用户信息不至于被泄露的情况下，使得第一用户可以根据自己的需求来设定自己举办的活动所面向的第二用户群，在基于这种第二用户群进行活动信息的推送时，可以提高转化率，并且，在利用这种第二用户群对活动关联的资源相关信息的处理时，还可以提高活动效率，提升用户体验。

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

附图说明

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

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

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

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

图4是本申请实施例提供的统计结果示意图；

图5是本申请实施例提供的交互流程示意图；

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

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

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

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

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

具体实施方式

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

在本申请实施例中，可以向第一用户客户端(例如，为航司人员提供的客户端等)提供配置接口，使得第一用户可以通过其客户端对活动信息进行配置，这样，可以使得在第一用户看来，平台是自己的“第二官网”，而不再单纯的平台的概念，因此，可以为用户提供最大的利益点。同时，第一用户在配置活动信息时，不仅可以配置参加活动的数据对象及其资源相关信息(例如，使用优惠券、满减等优惠信息)，还可以包括面向的第二用户的信息，这种第二用户信息可以用于对第二用户进行定向的活动信息推送，以及在圈定出的第二用户范围内开展优惠活动，因此，在功能上可以提高推送活动信息的精准性，在给用户提供最佳用户体验的同时，精准的给目标用户推送优惠促销等信息，有利于提高转化率。

其中，所谓的“定向”，也就意味着并不是所有消费者都能享受活动中设定的优惠，而是仅向一些特定的人群发放这种优惠。例如，某活动在创建时可以圈定出人群A，则意味着只有人群A在购买机票时可以使用30元优惠券，等等。

当然，如果直接将活动配置的权限开放给第二用户，则可能会涉及到一些第二用户的数据保护的问题，也就是说，由于活动规则对于第二用户而言具有定向性的特点，也即，在第一用户配置自己的活动数据时，可能会需要通过第二用户的信息，来指定自己开展的活动面向的第二用户人群。但是，如果直接将平台中第二用户的信息提供给第一用户，则可能意味着平台内的第二用户信息发生暴露，这在很多情况下是不可行的。

为此，在本申请实施例中，可以通过用户标签的方式，来接收第一用户设定的用户范围信息。具体实现时，可以根据第二用户的个人信息、搜索行为、用户分类、购买行为、特定偏好等，为第二用户打标签。例如，对于航旅领域的平台而言，第二用户可能会具有的用户标签可以包括但不限于以下几种：

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

搜索行为：N天内搜索某条航线未下单，搜索酒店，度假等商品的历史；

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

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

用户偏好：机票产品偏好，购票渠道偏好；

……

通过用户标签可以设定用户条件，并且，可以根据这种条件圈定出符合条件的第二用户集合。为此，在本申请实施例中，在为第一用户开放了活动配置接口的情况下，在第一用户配置第二用户的范围信息时，可以将可选的用户标签提供给第一用户，这样，第一用户可自由选择任何一个标签，相应的，服务器便可以将符合条件的第二用户筛选出来；也可以支持选择多个标签，服务器可以将具有每个标签的用户做合并，取交集，获得具有所选择标签的第二用户集合，进而，基于这种第二用户集合进行活动信息的推送，以及活动优惠的定向发放，等等。

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

实施例一

在该实施例一中，首先提供了一种数据对象信息处理方法，参加图1，该方法可以包括以下步骤：

S101：服务器接收到第一用户客户端提交的活动配置请求时，提供可选的用户标签，以便从所述可选的用户标签中选择用于建立第二用户集合的至少一个用户标签；

第一用户客户端可以通过访问服务器提供的接口，发起活动配置请求，相应的，服务器就可以提供可选的用户标签，其中，可选的用户标签可以是根据系统中的各第二用户各自所具有的用户标签的并集而确定出的。在向第一用户客户端提供了用户标签候选项后，第一用户客户端就可以从中选择至少一个用户标签，这样，服务器就可以利用这种用户标签，圈定出具体的第二用户人群范围。

当然，在配置活动信息时，除了可以配置用户标签信息，还可以对参加活动的数据对象范围进行圈定，以及活动关联的资源相关信息。其中，关于参加活动的数据对象范围，可以由服务器提供当前第一用户已发布的数据对象列表，这样，第一用户可以通过其客户端界面，从中选择参加当前活动的数据对象。当然，还可以通过其他方式来配置数据对象信息。另外，关于活动关联的资源相关信息，具体可以是活动中关联的优惠方式信息等，在本申请实施例中，第一用户可以根据其自身的需要设定任意的优惠方式。例如，可以是允许使用指定金额的优惠券，或者，还可以是优惠一定的金额，或者，可享受某种折扣，或者，还可以是发放“红包”、“礼包”，甚至还可以与第三方进行交叉营销，例如，可以赠送某网约车服务平台中的优惠券，或者，赠送某餐厅的代金券，等等。总之，在本申请实施例中，由于活动信息是由第一用户客户端自行配置，因此，可以根据自己的实际需求、数据对象的特点等，配置出最相符的活动信息，包括第二用户人群范围、数据对象范围、资源相关信息，等等。

S102：接收所述第一用户客户端提交的活动配置信息，所述活动配置信息中包括所述至少一个用户标签、参加活动的数据对象信息以及活动关联的资源相关信息；

通过第一用户客户端编辑好的活动配置信息，可以提交到服务器，其中就可以包括所述至少一个用户标签、参加活动的数据对象信息以及活动关联的资源相关信息。

S103：保存所述活动配置信息，以便在接收到第二用户客户端的访问请求时，根据所述活动配置信息，向所述第二用户客户端提供数据对象信息。

服务器在接收到活动配置信息后可以进行保存，这样，在在接收到第二用户客户端的访问请求时，可以根据所述活动配置信息，向所述第二用户客户端提供数据对象信息。

具体实现时，保存的活动配置信息可以如表1所示：

表1

具体实现时，服务器在保存活动配置信息之后，还可以根据所述至少一个用户标签，从预置的用户信息数据库中确定出至少一个用户组成的用户群，并保存所述用户群信息，以便在接收到第二用户客户端的访问请求时，通过判断所述第二用户是否属于所述用户群，确定该第二用户是否符合对应的活动条件。另外，还可以基于这种用户群，向用户群中的各用户推送关于所述活动的通知消息，例如，提前向该用户群中的用户发放优惠券等等。当然，在具体实现时，如果根据用户标签确定出的用户群中包括的用户数量比较大，则为了避免对存储资源造成过多的占用，还可以直接对活动关联的用户标签进行保存。后续在确定第二用户是否符合活动条件时，直接利用这种保存的用户标签对第二用户进行判断。

实施例二

该实施例二是与实施例一相对应的，从第一用户客户端的角度进行的介绍，参见图2，该实施例二提供了一种数据对象信息处理方法，该方法具体可以包括以下步骤：

S201：第一用户客户端提供活动配置界面，所述配置界面中包括候选的用户标签；

S202：确定被选中的至少一个用户标签；

S203：确定参加活动的数据对象信息，以及活动关联的资源相关信息；

S204：将所述至少一个用户标签、参加活动的数据对象信息以及所述资源相关信息作为活动配置信息提交到服务器，以便所述服务器根据所述活动规则向第二用户客户端提供数据对象信息页面。

由于该实施例二与实施例一是对应的，因此，相关的具体实现可以参见前述实施例一中的记载，这里不再赘述。

实施例三

在服务器保存了活动配置信息后，在向第二用户提供数据对象信息时，就可以根据这种活动配置信息来提供具体的页面信息。具体的，参见图3，该实施例三首先从服务器的角度提供了一种提供数据对象信息的方法，该方法具体可以包括以下步骤：

S301：服务器接收第二用户客户端的数据对象搜索请求，并确定符合条件的至少一个数据对象；

由于本申请实施例主要针对垂直业务领域的销售平台，而在这类销售平台中，由于数据对象的类目比较单一，因此，通常是先为第二用户提供搜索入口，由第二用户输入搜索条件后，提供出匹配的数据对象。例如，在“阿里旅行”平台，用户进入“机票”频道后，可以提供用于输入出发地、目的地、出发日期等信息的搜索条件输入框，在第二用户输入具体的搜索条件之后，就可以提供出数据对象列表，包括各航班的机票等等。其中，在该数据对象列表中，通常是包括了多个第一用户发布的数据对象，例如，多家航空公司发布的航班信息，等等。

S302：确定各数据对象是否关联预置活动，所述预置活动由所述数据对象对应的第一用户客户端进行配置，所述预置活动还关联有面向的用户范围信息以及资源相关信息；

在确定出符合搜索条件的数据对象列表后，在本申请实施例中，还可以根据预先保存的第一用户配置的活动信息，判断各个数据对象是否关联有预置活动，如果关联有预置活动，则同时还可以确定出该预置活动关联的用户范围信息以及资源相关信息。

例如，在用户发起出发地为北京、目的地为上海、出发日期为10月1日的航班搜索时，可以返回符合条件的航班信息，并且可以判断各个航班是否被所属的航空公司配置有预置活动，例如，使用优惠券等等。

S303：如果所述数据对象关联有预置活动，则判断所述第二用户客户端关联的目标第二用户是否属于所述用户范围；

如果某数据对象关联有预置活动，则还可以确定出该预置活动关联的用户范围信息。其中，服务器在保存用户范围信息时可以有多种形式，例如，其中一种形式下，用户范围信息可以包括预先根据所述预置活动关联的至少一个用户标签确定的用户群信息，也就是说，服务器在接收到第一用户配置的用户标签后，可以首先根据这种用户标签从众多第二用户中筛选出符合条件的第二用户，形成用户群，并保存这种用户群信息。这样，在判断当前的第二用户是否属于活动关联的用户范围时，就可以直接判断该第二用户是否属于该用户群。例如，假设用户群中保存了多个用户的账户、ID等信息，则可以判断当前第二用户的账户、ID是否出现在集合中。

在另一种情况下，服务器保存用户范围信息时，可以直接保存第一用户配置的通过用户标签表达的条件信息，此时，在判断当前的第二用户是否属于配置的用户范围时，可以根据该第二用户的用户标签，判断其是否满足对应的条件，如果满足，则属于配置的用户范围。

S304：如果所述目标第二用户属于所述用户范围，则根据所述预置活动关联的资源相关信息对对应的数据对象进行处理。

在确定出当前第二用户属于活动配置的用户范围后，就可以根据预置活动关联的资源相关信息对对应的数据对象进行处理，也就是说，如果当前的第二用户属于活动配置的用户范围，则该第二用户可以享受第一用户为该数据对象配置的优惠等信息。其中，具体在对数据对象进行处理时可以包括多种方式，例如，首先可以在数据对象列表页面中提供关于资源相关信息的提示信息，具体如：对应的数据对象可以享受某种优惠的提示信息，如可以使用某金额的优惠券等。当然，如果其他的某第二用户不属于某数据对象关联的活动配置的用户范围，则不会在页面中提供该提示。

另外，具体对数据对象的处理方式还可以包括：在所述第二用户客户端对所述对应的数据对象执行了预置操作时，利用所述资源相关信息进行资源调整。例如，在第二用户购买了某航班的机票时，可以利用对应金额的优惠券，对该机票的价格进行调整，或者，还可以向第二用户客户端发送某金额的“红包”，或者，为该第二用户提供关于第三方应用中的代金券，等等。

可见，通过本申请实施例，可以由第一用户客户端自定配置活动信息，并且，除了活动中的资源相关信息可以灵活配置之外，还可以通过用户标签的方式来配置活动面向的第二用户范围信息，这样，在保证平台中的用户信息不至于被泄露的情况下，使得第一用户可以根据自己的需求来设定自己举办的活动所面向的第二用户群，在基于这种第二用户群进行活动信息的推送时，可以提高转化率，并且，在利用这种第二用户群对活动关联的资源相关信息的处理时，还可以提高活动效率，提升用户体验。

另外，在本申请实施例中，由于可以通过用户标签的方式来圈定活动面向的用户范围，因此，使得活动面向的用户群是以用户特征为依据的，这样，还可以基于这种用户特征对活动效果的好坏进行分析，为下次开展活动提供参考。

具体实现时，可以统计第二用户客户端的活动参与情况信息，例如，可以保存第二用户参与活动的记录，包括参与时间，参与渠道(pc还是移动终端)购买机票票数，订单金额，乘机人数等。基于这些记录信息，系统可以针对第二用户的参与记录做统计，分渠道、分时间段等做成交数据报表，另外，还可以支持对参与用户的各类标签特征作分析，包括筛选第二用户时使用的标签以及筛选第二用户时未使用的标签，得出哪类标签用户对当前活动参与度更高等各类数据。或者，还可以以任意标签为单位，对各种运营指标进行自动化分析，包括转化率(购票人数/推送人数)，等等。

基于上述统计数据的基础上，还可以根据统计结果生成可视化报表，并提供给第一用户客户端，例如，如图4所示，可以以年龄段这一用户标签为单位，统计优惠券的发放情况，以及优惠券的使用情况，并形成饼图，将这种饼图提供给第一用户客户端，使得第一用户客户端可以直观的发现活动的参与情况。例如，可以发现，向年龄在30～34岁的第二用户发放的优惠券最多，占到40％，向年龄在18～24岁以及25～29岁的第二用户发放的优惠券相同，分别占20％，等等。而在优惠券的使用方面，年龄在30～34岁的第二用户占37％，年龄18～24岁的第二用户只占3％，年龄在25～29岁的第二用户占到31％，等等。可见，年龄在25～29岁的第二用户从优惠券发放到优惠券使用的转化率最大，而18～24岁的第二用户对应的转化率则很低，这样，第一用户在下次开展活动时，可以加大向25～29岁的第二用户的优惠券发放量，减少向18～24岁的第二用户的优惠券发放量，等等。

另外，在实际应用中，对于服务器而言，还可以将活动产生的新数据导入到标签中，形成新的标签，为参与活动的第二用户添加新的用户标签，进而可以使得平台在数据上不断丰富。相应的，在下次向第一用户客户端提供可选的用户标签时，可以以更新后的用户标签库为准进行提供。可见，在本申请实施例中，可以授权第一用户在指定某类第二用户定向参与活动，配置各种活动规则和用户收益等资源相关信息，并能根据实际的转化率等结果进行数据分析反哺系统，指导下次活动配置的合理性，实现数据闭环。

为了更好的理解本申请实施例，下面以航旅平台为例，对本申请实施例提供的技术方案进行详细介绍。

参见图5，首先从模块角度，该系统可以分为以下模块：

活动配置模块：对航司运营人员提供统一录入活动配置信息的入口，支持录入活动和收益的组合，比如买国内机票(活动)送国际机票优惠券(收益)；也支持批量录入或者导入优惠券，给第二用户直接提供优惠；

活动匹配模块：在第二用户进行机票搜索时，活动匹配模块可以计算用户都满足哪些活动，提示用户如果购买机票可以从这些活动中获得哪些收益；

优惠匹配模块：在第二用户进行机票购买时，优惠匹配模块可以计算第二用户满足的优惠条件，比如，“满减”或者“直减”优惠等等，从而使用原始机票价格减去优惠后给第二用户展示最终购买价格；

收益发放模块：第二用户购买机票后，收益发放模块可以根据活动匹配模块的计算结果，将收益(优惠券，礼包等)发放给第二用户；

用户通知中心：第二用户获得收益后，用户通知中心可以给第二用户发送短信、即时通信消息或者邮件等，提醒第二用户获得的收益，并且还可以提醒第二用户提前使用；

数据中心：可以存储第二用户的所有购买历史，并实时跟进第二用户购买历史，计算任何一个活动以及营销优惠为系统带来的机票销量，购买转化率，复够率等指标；所有计算可以以用户标签为单位进行细分，也支持以小时和天等为单位进行细分；计算出来的数据可以推送给用户中心补充用户特征数据，也可以反馈给航司等第一用户用于判断此次活动的精准性和整体效果，进而指导下次活动信息的配置；

用户中心：存储第二用户数据，包括年龄，性别的个人私有数据，也包括购票偏好比如航空公司偏好，购票时间偏好，搜索历史等各种数据；并根据数据提供各种标签进行用户筛选；

可视化报表系统：可以根据数据提供可视化的报表，包括excel可下载文件格式、列表格式、柱状图、饼图等各种图标格式。

接下来从流程角度，该系统可以分为以下阶段：

1、第一用户运营发布活动/优惠阶段：

1a：航司运营人员(第一用户)可以在入口页面创建新的活动/优惠，录入活动；选择筛选用户标签规则；配置规则和收益等资源相关信息；

1b：服务器的优惠匹配模块可以根据航司运营录入的规则到用户中心去获取用户列表；

1c：将用户列表的用户赋予可以使用本次活动的权利，并存入数据库中；对于涉及用户量巨大或者需要实时在用户中心判断规则的活动将规则记录在数据库中。

2、第二用户搜索机票阶段：

2a：第二用户搜索指定出发地、目的地和出发日期的机票；

2b：搜索中心可以调用活动匹配模块查询此第二用户购买各匹配的航班可以获得的资源相关信息；

2c：活动匹配模块到数据库中根据用户账号进行查询，将所满足的收益和优惠金额等资源相关信息返回给搜索中心；

2d：活动匹配模块对需要实时在用户中心匹配的规则，到用户中心去查询此用户标签判断是否满足条件；并将上一步的结果合并返回给搜索中心；

2e/2f：机搜索中心将用户搜索记录发送给数据中心,数据中心存储到搜索购买数据库中；

3、第二用户购买机票阶段：

3a：用户购买指定出发地、目的地和出发日期的机票；

3b：交易中心可以调用优惠匹配模块查询此用户购买此航班可以获得的资源相关信息；

3c/3d：同搜索流程，优惠匹配模块到数据库中根据用户账号进行查询并在需要时实时使用用户中心判断用户标签，将资源相关信息返回给交易中心；

3e/3f：交易中心将用户交易记录发送给数据中心,数据中心根据已有数据重新计算所用到的活动转化率，存储到搜索购买数据库中；

3g：数据中心将购买数据推送给用户中心，用户中心可以根据用户购买记录更新优化标签；

3h：数据中心将转化率等可视化数据推送给可视化报表系统；

3i：提供各种可视化的报表给航司等第一用户客户端，第一用户客户端可以根据结果优化下次活动内容。

4、发放用户收益阶段：

4a：交易中心将购买记录通知收益发放模块；

4b：收益发放模块从数据库中查询第一用户客户端配置的信息，计算需要给第二用户发放的收益，并完成发放；

4c：收益发放模块将发送消息通知用户通知消息中心；

4d：用户通知中心通过短信邮件等各种方式通知给第二用户，通知其已获得的收益信息。

实施例四

该实施例四是与实施例三相对应的，从第二用户客户端的角度进行介绍。参见图6，该实施例四提供了一种提供数据对象信息的方法，该方法可以包括以下步骤：

S601：第二用户客户端接收数据对象搜索请求；

S602：将所述请求提交到服务器，以便所述服务器确定符合条件的至少一个数据对象，并确定各数据对象是否关联预置活动，所述预置活动由所述数据对象对应的第一用户客户端进行配置，所述预置活动还关联有面向的用户范围信息以及资源相关信息；如果所述数据对象关联有预置活动，则判断所述第二用户客户端关联的目标第二用户是否属于所述用户范围，如果所述目标第二用户属于所述用户范围，则根据所述预置活动关联的资源相关信息对对应的数据对象进行处理；

S603：根据服务器返回的响应提供数据对象信息。

由于该实施例四与实施例三是对应的，因此，相关的具体实现可以参见前述实施例三中的记载，这里不再赘述。

与实施例一相对应，本申请实施例还提供了一种数据对象信息处理装置，参见图7，该装置应用于服务器，具体可以包括：

用户标签提供单元701，用于接收到第一用户客户端提交的活动配置请求时，提供可选的用户标签，以便从所述可选的用户标签中选择用于建立第二用户集合的至少一个用户标签；

活动配置信息接收单元702，用于接收所述第一用户客户端提交的活动配置信息，所述活动配置信息中包括所述至少一个用户标签、参加活动的数据对象信息以及活动关联的资源相关信息；

保存单元703，用于保存所述活动配置信息，以便在接收到第二用户客户端的访问请求时，根据所述活动配置信息，向所述第二用户客户端提供数据对象信息。

具体实现时，该装置还可以包括：

用户群确定单元，用于根据所述至少一个用户标签，从预置的用户信息数据库中确定出至少一个用户组成的用户群，并保存所述用户群信息，以便在接收到第二用户客户端的访问请求时，通过判断所述第二用户是否属于所述用户群，确定该第二用户是否符合对应的活动条件。

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

通知单元，用于向所述用户群中的各个用户推送关于所述活动的通知消息。

与实施例二相对应，本申请实施例还提供了一种数据对象信息处理装置，参见图8，该装置应用于第一用户客户端，具体可以包括：

配置界面提供单元801，用于提供活动配置界面，所述配置界面中包括候选的用户标签；

用户标签确定单元802，用于确定被选中的至少一个用户标签；

数据对象信息确定单元803，用于确定参加活动的数据对象信息，以及活动关联的资源相关信息；

提交单元804，用于将所述至少一个用户标签、参加活动的数据对象信息以及所述资源相关信息作为活动配置信息提交到服务器，以便所述服务器根据所述活动规则向第二用户客户端提供数据对象信息页面。

与实施三相对应，本申请实施例还提供了一种提供数据对象信息的装置，参见图9，该装置应用于服务器，具体可以包括：

数据对象确定单元901，用于接收第二用户客户端的数据对象搜索请求，并确定符合条件的至少一个数据对象；

活动确定单元902，用于确定各数据对象是否关联预置活动，所述预置活动由所述数据对象对应的第一用户客户端进行配置，所述预置活动还关联有面向的用户范围信息以及资源相关信息；

判断单元903，用于如果所述数据对象关联有预置活动，则判断所述第二用户客户端关联的目标第二用户是否属于所述用户范围；

处理单元904，用于如果所述目标第二用户属于所述用户范围，则根据所述预置活动关联的资源相关信息对对应的数据对象进行处理。

具体实现时，所述用户范围信息包括预先根据所述预置活动关联的至少一个用户标签确定的用户群信息，所述判断单元具体可以用于：

判断所述第二用户客户端关联的目标第二用户是否属于所述用户群。

或者，所述用户范围信息包括所述预置活动关联的至少一个用户标签信息，所述判断单元具体可以用于：

判断所述第二用户客户端关联的目标第二用户的用户标签是否满足所述活动中设定的条件。

具体实现时，所述处理单元具体可以用于：

针对对应的数据对象，提供关于所述资源相关信息的提示信息。

或者，所述处理单元具体也可以用于：

在所述第二用户客户端对所述对应的数据对象执行了预置操作时，利用所述资源相关信息进行资源调整。

在实际应用中，该装置还可以包括：

统计单元，用于以用户标签为单位，统计第二用户客户端的活动参与情况信息。

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

统计结果提供单元，用于根据统计结果生成可视化报表，并提供给第一用户客户端。

更新单元，用于对于参与活动的所述第二用户客户端，更新对应的目标第二用户的用户标签。

与实施四相对应，本申请实施例还提供了一种提供数据对象信息的装置，参见图10，该装置应用于第二用户客户端，具体可以包括：

搜索请求接收单元1001，用于接收数据对象搜索请求；

请求提交单元1002，用于将所述请求提交到服务器，以便所述服务器确定符合条件的至少一个数据对象，并确定各数据对象是否关联预置活动，所述预置活动由所述数据对象对应的第一用户客户端进行配置，所述预置活动还关联有面向的用户范围信息以及资源相关信息；如果所述数据对象关联有预置活动，则判断所述第二用户客户端关联的目标第二用户是否属于所述用户范围，如果所述目标第二用户属于所述用户范围，则根据所述预置活动关联的资源相关信息对对应的数据对象进行处理；

数据对象信息提供单元1003，用于根据服务器返回的响应提供数据对象信息。

通过本申请实施例，可以由第一用户客户端自定配置活动信息，并且，除了活动中的资源相关信息可以灵活配置之外，还可以通过用户标签的方式来配置活动面向的第二用户范围信息，这样，在保证平台中的用户信息不至于被泄露的情况下，使得第一用户可以根据自己的需求来设定自己举办的活动所面向的第二用户群，在基于这种第二用户群进行活动信息的推送时，可以提高转化率，并且，在利用这种第二用户群对活动关联的资源相关信息的处理时，还可以提高活动效率，提升用户体验。

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

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

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

Claims (17)

1.一种数据对象信息处理方法，其特征在于，包括：

服务器接收到第一用户客户端提交的活动配置请求时，提供可选的用户标签，以便从所述可选的用户标签中选择用于建立第二用户集合的至少一个用户标签；

接收所述第一用户客户端提交的活动配置信息，所述活动配置信息中包括所述至少一个用户标签、参加活动的数据对象信息以及活动关联的资源相关信息；

保存所述活动配置信息，以便在接收到第二用户客户端的访问请求时，根据所述活动配置信息，向所述第二用户客户端提供数据对象信息。

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

根据所述至少一个用户标签，从预置的用户信息数据库中确定出至少一个用户组成的用户群，并保存所述用户群信息，以便在接收到第二用户客户端的访问请求时，通过判断所述第二用户是否属于所述用户群，确定该第二用户是否符合对应的活动条件。

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

向所述用户群中的各个用户推送关于所述活动的通知消息。

4.一种数据对象信息处理方法，其特征在于，包括：

第一用户客户端提供活动配置界面，所述配置界面中包括候选的用户标签；

确定被选中的至少一个用户标签；

确定参加活动的数据对象信息，以及活动关联的资源相关信息；

将所述至少一个用户标签、参加活动的数据对象信息以及所述资源相关信息作为活动配置信息提交到服务器，以便所述服务器根据所述活动规则向第二用户客户端提供数据对象信息页面。

5.一种提供数据对象信息的方法，其特征在于，包括：

服务器接收第二用户客户端的数据对象搜索请求，并确定符合条件的至少一个数据对象；

确定各数据对象是否关联预置活动，所述预置活动由所述数据对象对应的第一用户客户端进行配置，所述预置活动还关联有面向的用户范围信息以及资源相关信息；

如果所述数据对象关联有预置活动，则判断所述第二用户客户端关联的目标第二用户是否属于所述用户范围；

如果所述目标第二用户属于所述用户范围，则根据所述预置活动关联的资源相关信息对对应的数据对象进行处理。

6.根据权利要求5所述的方法，其特征在于，所述用户范围信息包括预先根据所述预置活动关联的至少一个用户标签确定的用户群信息，所述判断所述第二用户客户端关联的目标第二用户是否属于所述用户范围，包括：

判断所述第二用户客户端关联的目标第二用户是否属于所述用户群。

7.根据权利要求5所述的方法，其特征在于，所述用户范围信息包括所述预置活动关联的至少一个用户标签信息，所述判断所述第二用户客户端关联的目标第二用户是否属于所述用户范围，包括：

判断所述第二用户客户端关联的目标第二用户的用户标签是否满足所述活动中设定的条件。

8.根据权利要求5所述的方法，其特征在于，所述根据所述预置活动关联的资源相关信息对对应的数据对象进行处理，包括：

针对对应的数据对象，提供关于所述资源相关信息的提示信息。

9.根据权利要求5所述的方法，其特征在于，所述根据所述预置活动关联的资源相关信息对对应的数据对象进行处理，包括：

在所述第二用户客户端对所述对应的数据对象执行了预置操作时，利用所述资源相关信息进行资源调整。

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

以用户标签为单位，统计第二用户客户端的活动参与情况信息。

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

根据统计结果生成可视化报表，并提供给第一用户客户端。

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

对于参与活动的所述第二用户客户端，更新对应的目标第二用户的用户标签。

13.一种提供数据对象信息的方法，其特征在于，包括：

第二用户客户端接收数据对象搜索请求；

将所述请求提交到服务器，以便所述服务器确定符合条件的至少一个数据对象，并确定各数据对象是否关联预置活动，所述预置活动由所述数据对象对应的第一用户客户端进行配置，所述预置活动还关联有面向的用户范围信息以及资源相关信息；如果所述数据对象关联有预置活动，则判断所述第二用户客户端关联的目标第二用户是否属于所述用户范围，如果所述目标第二用户属于所述用户范围，则根据所述预置活动关联的资源相关信息对对应的数据对象进行处理；

根据服务器返回的响应提供数据对象信息。

14.一种数据对象信息处理装置，其特征在于，应用于服务器，包括：

用户标签提供单元，用于接收到第一用户客户端提交的活动配置请求时，提供可选的用户标签，以便从所述可选的用户标签中选择用于建立第二用户集合的至少一个用户标签；

活动配置信息接收单元，用于接收所述第一用户客户端提交的活动配置信息，所述活动配置信息中包括所述至少一个用户标签、参加活动的数据对象信息以及活动关联的资源相关信息；

保存单元，用于保存所述活动配置信息，以便在接收到第二用户客户端的访问请求时，根据所述活动配置信息，向所述第二用户客户端提供数据对象信息。

15.一种数据对象信息处理装置，其特征在于，应用于第一用户客户端，包括：

配置界面提供单元，用于提供活动配置界面，所述配置界面中包括候选的用户标签；

用户标签确定单元，用于确定被选中的至少一个用户标签；

数据对象信息确定单元，用于确定参加活动的数据对象信息，以及活动关联的资源相关信息；

提交单元，用于将所述至少一个用户标签、参加活动的数据对象信息以及所述资源相关信息作为活动配置信息提交到服务器，以便所述服务器根据所述活动规则向第二用户客户端提供数据对象信息页面。

16.一种提供数据对象信息的装置，其特征在于，应用于服务器，包括：

数据对象确定单元，用于接收第二用户客户端的数据对象搜索请求，并确定符合条件的至少一个数据对象；

活动确定单元，用于确定各数据对象是否关联预置活动，所述预置活动由所述数据对象对应的第一用户客户端进行配置，所述预置活动还关联有面向的用户范围信息以及资源相关信息；

判断单元，用于如果所述数据对象关联有预置活动，则判断所述第二用户客户端关联的目标第二用户是否属于所述用户范围；

处理单元，用于如果所述目标第二用户属于所述用户范围，则根据所述预置活动关联的资源相关信息对对应的数据对象进行处理。

17.一种提供数据对象信息的装置，其特征在于，应用于第二用户客户端，包括：

搜索请求接收单元，用于接收数据对象搜索请求；

请求提交单元，用于将所述请求提交到服务器，以便所述服务器确定符合条件的至少一个数据对象，并确定各数据对象是否关联预置活动，所述预置活动由所述数据对象对应的第一用户客户端进行配置，所述预置活动还关联有面向的用户范围信息以及资源相关信息；如果所述数据对象关联有预置活动，则判断所述第二用户客户端关联的目标第二用户是否属于所述用户范围，如果所述目标第二用户属于所述用户范围，则根据所述预置活动关联的资源相关信息对对应的数据对象进行处理；

数据对象信息提供单元，用于根据服务器返回的响应提供数据对象信息。