本申请涉及互联网技术领域，特别涉及一种业务信息的提供、接收、用户聚合方法、服务器及客户端。
背景技术
随着电子商务的不断发展，各类在线旅游平台也层出不穷。用户通过在线旅游平台，可以订购或者浏览各种旅游产品。当前，用户在旅游平台中注册之后，可以接收到在线旅游平台推送的各式各样的业务信息。这些业务信息例如可以包括旅游优惠信息、旅游套餐推荐信息、航班推荐信息等。然而，很多业务信息都是用户不太感兴趣的。只有向用户提供其感兴趣的业务信息，才能使得业务信息能够有效地发挥作用。
目前，部分在线旅游平台的应用程序可以对用户的订单进行分析，并将购买了同一个航班机票的用户加入同一个聊天组，以便使得乘坐同一个航班的用户在聊天组中交流并且可以向该聊天组中的用户推送航空公司的业务信息。
然而，现有技术中的这种业务信息的提供方法太过单一，只能针对订单进行分析，而对于那些当前没有购买产品，但是正在考虑购买产品的用户则无法提供相应的业务信息。因此，现有的业务信息的提供方法，针对的用户群体过于狭窄，无法保证业务信息的推广效率。
技术实现要素：
本申请实施方式的目的是提供一种业务信息的提供、接收、用户聚合方法、服务器及客户端，能够提高业务信息的推广效率。
为实现上述目的，本申请实施方式提供一种业务信息的提供方法，提供有业务对象的聚合规则，所述聚合规则用于限定所述业务对象的用户群体，所述方法包括：获取用户的行程数据，所述行程数据中包含至少一个地理位置信息；从所述行程数据中提取至少一个标签，并为所述行程数据对应的用户绑定所述至少一个标签；其中，所述标签用于表征用户的行程；从所述用户中确定行程数据中具备相同地理位置信息的目标用户群；将所述目标用户群中标签符合所述聚合规则的用户聚合至所述业务对象的用户集合中；将所述业务对象的业务信息提供给所述用户集合中的用户。
为实现上述目的，本申请实施方式还提供一种服务器，所述服务器包括网络通信端口、存储器以及处理器，其中：所述网络通信端口，用于与用户的客户端进行网络数据通信；所述存储器，用于存储能够被所述处理器执行的计算机程序以及存储业务对象的聚合规则，所述聚合规则用于限定所述业务对象的用户群体；所述处理器，用于在执行所述计算机程序时，能够实现以下步骤：通过所述网络通信端口获取用户的行程数据，所述行程数据中包含至少一个地理位置信息；从所述行程数据中提取至少一个标签，并为所述行程数据对应的用户绑定所述至少一个标签；其中，所述标签用于表征用户的行程；从所述用户中确定行程数据中具备相同地理位置信息的目标用户群；将所述目标用户群中标签符合所述聚合规则的用户聚合至所述业务对象的用户集合中；将所述业务对象的业务信息提供给所述用户集合中的用户。
为实现上述目的，本申请还提供一种业务信息的接收方法，所述方法包括：向服务器提供用户的包括至少一个地理位置信息的行程数据，以用于所述服务器根据所述地理位置信息确定所述用户属于的用户群，以及根据所述行程数据为所述用户绑定至少一个标签，以及将所述用户群中标签符合聚合规则的用户聚合至用户集合中；其中，所述标签用于表征所述用户的行程；所述聚合规则与业务对象对应；接收所述服务器反馈的业务信息；其中，所述业务信息表示所述用户所在用户集合对应的业务对象。
为实现上述目的，本申请还提供一种客户端，所述客户端包括网络通信端口、存储器、显示器以及处理器，其中：所述网络通信端口，用于与服务器进行网络数据通信；所述存储器，用于存储所述服务器反馈的业务信息；显示器，用于显示所述业务信息；所述处理器，用于控制所述网络通信端口向所述服务器提供用户的包括至少一个地理位置信息的行程数据，以用于所述服务器根据所述地理位置信息确定所述用户属于的用户群，以及根据所述行程数据为所述用户绑定至少一个标签，以及将所述用户群中标签符合聚合规则的用户聚合至用户集合中；其中，所述标签用于表征所述用户的行程；所述聚合规则与业务对象对应；控制所述网络通信端口接收所述服务器反馈的业务信息；其中，所述业务信息表示所述用户所在用户集合对应的业务对象；将所述业务信息写入所述存储器中并将所述业务信息通过所述显示器向所述用户展示。
为实现上述目的，本申请还提供一种用户聚合方法，所述方法包括：获取用户的行程数据，所述行程数据中包含至少一个属性信息；从所述行程数据中提取至少一个标签，并为所述行程数据对应的用户绑定所述至少一个标签；从所述用户中确定行程数据中具备相同属性信息的目标用户群；将所述目标用户群中标签符合聚合规则的用户聚合至业务对象的用户集合中。
由以上本申请实施方式提供的技术方案可见，本申请实施方式通过对用户的行程数据进行分析，从而可以为各个用户设定相适配的标签。针对指定的业务对象，其可以预先设置用于限定用户群体的聚合规则。针对行程数据中具备相同地理位置信息的目标用户群，可以通过该聚合规则以及用户的标签，进一步地将目标用户群中的用户聚合至业务对象的用户集合中，从而可以向用户集合中的用户提供业务对象的业务信息。本申请公开的业务信息的提供、接收、用户聚合方法、服务器及客户端，不仅仅对用户的订单数据进行分析，而是对能够对用户的行程数据进行分析，从而扩大了参考的用户群体，进而提高了业务信息的推广效率。
附图说明
为了更清楚地说明本申请实施方式或现有技术中的技术方案，下面将对实施方式或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请中记载的一些实施方式，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
图1为本申请实施方式提供的一种业务信息的提供方法流程图；；
图2为本申请实施方式中提供业务信息的示意图；
图3为本申请实施方式中获取行程数据的示意图；
图4为本申请实施方式提供的一种服务器的结构示意图；
图5为本申请实施方式提供的一种业务信息的接收方法流程图；
图6为本申请实施方式提供的一种客户端的结构示意图；
图7为本申请实施方式提供的一种用户聚合方法的流程图。
具体实施方式
为了使本技术领域的人员更好地理解本申请中的技术方案，下面将结合本申请实施方式中的附图，对本申请实施方式中的技术方案进行清楚、完整地描述，显然，所描述的实施方式仅仅是本申请一部分实施方式，而不是全部的实施方式。基于本申请中的实施方式，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施方式，都应当属于本申请保护的范围。
本申请实施方式提供一种业务信息的提供方法，所述方法可以应用于在线旅游平台的服务器中，所述在线旅游平台的服务器可以为一个具有数据运算、存储功能以及网络交互功能的电子设备；也可以为运行于该电子设备中，为数据处理、存储和网络交互提供支持的软件。
在本实施方式中并不具体限定服务器的数量。服务器可以为一个服务器，还可以为几个服务器，或者还可以为若干服务器形成的服务器集群。
在本实施方式中，可以提供有业务对象的聚合规则。所述业务对象可以是在在线旅游平台中出售的旅游产品。所述旅游产品可以是实体产品。例如机票、门票等。所述旅游产品还可以是虚拟产品。例如在目的城市做spa的资格、专车接送服务等。当然，有些旅游产品既可以通过实体产品的形式出现，也可以通过虚拟产品的形式出现。例如，对于客运公司出售的车票而言，可以是纸质的实体产品，也可以是类似二维码、序列号等形式的虚拟产品。
在本实施方式中，所述业务对象的聚合规则可以用于限定所述业务对象的商家关注的用户群体。例如，对于提供专车接送服务的商家而言，其对应的聚合规则可以是出行费用超过指定数值。这样，该专车接送服务的聚合规则则可以表明，该专车接送服务的商家在众多用户中仅关注消费能力较高的用户群体。
在本实施方式中，各个业务对象的聚合规则可以由业务对象的商家预先指定。例如，对于提供专车接送服务的商家而言，其指定的聚合规则可以是出行费用在两万以上。这样，各个业务对象的商家在指定了聚合规则之后，可以将指定的聚合规则存储于用于执行业务信息的提供方法流程的服务器中。
在本实施方式中，业务对象的聚合规则还可以由服务器通过分析购买该业务对象的用户的信息得到。具体地，用户的信息中可以包含用户在进行账号注册时填写的信息以及用户在在线旅游平台中购买的旅游产品的信息。服务器在分析用户的信息时，可以统计用户信息中相似的信息，以生成聚合规则。例如，对于购买头等舱机票的用户而言，其年龄层基本都在30岁至60岁之间，并且用户的平均月消费均在2万元以上。因此，服务器根据对购买头等舱机票的用户的信息进行分析之后，可以将年龄在30岁至60岁之间并且平均月消费大于或者等于2万元作为头等舱机票的聚合规则。在服务器分析得到各个业务对象的聚合规则后，可以在本地保存各个业务对象的聚合规则。
请参阅图1和图2。本申请提供的业务信息的提供方法可以包括以下步骤。
步骤s1：获取用户的行程数据，所述行程数据中包含至少一个地理位置信息。
在本实施方式中，所述用户的行程数据可以是用户在访问在线旅游平台时产生的能够表征用户行为特征的数据。例如，所述行程数据可以包括用户在在线旅游平台中的订单数据，还可以包括用户在在线旅游平台中浏览商品的浏览数据，还可以包括用户加入购物车中但并没有结算的拟购对象数据。当然，随着在线旅游平台功能的不断丰富，用户在访问在线旅游平台时，还可能产生其他的数据，只要这些数据能够体现用户的行为特征，均属于所述行程数据的范畴。其中，所述浏览数据可以根据用户在访问在线旅游平台过程中的操作行为生成。所述操作行为可以包括点击商品链接、一段时间内持续浏览商品的页面等等。这样，所述浏览数据中则可以包括用户访问的商品链接、在每个商品页面中停留的时间等信息。
在本实施方式中，用户的行为特征可以指用户的旅程安排、购买力、感兴趣的商品等信息。其中，用户的旅程安排可以通过用户在在线旅游平台中购买的旅游产品、机票、火车票、汽车票等与出行相关的商品数据分析得到。用户的购买力可以根据用户在在线旅游平台中消费的金额数据分析得到。用户感兴趣的商品则可以根据用户的浏览数据中浏览次数和浏览频率分析得到。
请参阅图3，在本实施方式中，获取行程数据的方式可以包括通过埋点的方式或者借助于mysqlmtop获取行程数据。具体地，埋点的方式可以是服务器响应于用户的客户端发来的页面显示请求，向所述用户的客户端反馈待显示的页面元素，并为各个页面元素绑定用于获取行程数据的代码。其中，当页面元素被触发时，与页面元素相绑定的代码也被执行。例如，在当前在线旅游平台的页面中，可以在各个商品的链接中以及加入购物车的按键中写入代码，当用户点击商品链接或者点击加入购物车的按键时，代码便被自动执行。执行之后便可以将点击商品链接的事件发送至服务器，也可以将购物车中的商品信息发送至服务器，这样，服务器便可以在代码被执行时，接收所述用户的客户端反馈的行程数据，从而完成行程数据采集的过程。
在本实施方式中，用户在通过客户端访问在线旅游平台时，服务器可以向客户端提供mtop接口，该mtop接口可以采用http协议。当用户在客户端中浏览在线旅游平台时，客户端可以向服务器的mtop接口发送数据获取请求。所述数据获取请求可以用于从服务器处获取预计在客户端的当前页面中显示的页面元素。例如，用户在访问某个商品的介绍页面，那么客户端向服务器发送的数据获取请求可以用于从服务器中获取该介绍页面中的文字信息、图片信息以及视频信息等。这样，在客户端与服务器之间可以通过mtop接口建立通信链路，客户端可以通过该通信链路从服务器处获取页面数据。在本实施方式中，客户端同样可以通过该通信链路，将用户在浏览当前页面时产生的行程数据传输至服务器。也就是说，通过复用该通信链路，客户端不仅可以从服务器处下载待显示的页面元素，还可以将用户的数据上传至服务器，避免了建立额外的信道进行行程数据的上传过程，从而提高了获取行程数据的效率。
在本实施方式中，为了提高获取行程数据的效率，可以结合上述两种方式。具体地，行程数据中的订单数据和拟购对象数据可以通过mtop的方式上传至服务器。而浏览数据则可以通过埋点的方式上传至服务器。上传至服务器的数据可以存储于服务器的数据库中。
在本实施方式中，所述行程数据可以用于表明用户的出行计划。所述出行计划中通常会包括出发地点、目标地点或者中转地点中的至少一个。因此，所述行程数据中可以包含至少一个地理位置信息。所述地理位置信息包括目的地信息、中转站信息、起始地信息中的至少一种。所述地理位置信息可以是地理位置的实际名称，也可以是用于表征地理位置的编码。例如，用户的行程数据中包含目的地为三亚的数据，那么所述地理位置信息可以是“三亚”，也可以是用于表征三亚的地理位置编码“sy”。
步骤s3：从所述行程数据中提取至少一个标签，并为所述行程数据对应的用户绑定所述至少一个标签；其中，所述标签用于表征用户的行程。
在本实施方式中，可以基于用户的行程数据，为各个用户绑定用于表征其行程的至少一个标签。
在本实施方式中，所述标签可以是一个短语，该短语中可以描述用户的行程信息。例如，所述标签可以是“出行时间：2017年1月36日”、“出行方式：飞机”、“航班号：tm52xx8”、“购买力：中等”、“相关产品：北极光”等等。通常，用户的行程信息可以通过出行时间、出行费用、出行人数、出行人员性别以及交通工具类型来表征，因此，所述标签可以包括出行时间、出行费用、出行人数、出行人员性别以及交通工具类型中的至少一种。
在本实施方式中，所述标签中可以包括标签类型和用户实际信息。在为用户设定标签时，可以分别设定标签类型和用户实际信息。其中，所述标签类型可以用于区分不同的标签。例如，所述标签类型可以包括“出行时间”、“出行方式”、“目的城市”、“出发城市”、“相关产品”等等。所述标签类型可以是由服务器分析大量的行程数据后总结得到的，并且标签类型可以随着行程数据的增加而增加。这样，在服务器中便可以存储标签类型的列表，在该列表中可以列出各个标签类型。当服务器对新的行程数据进行分析时，可以根据所述列表中的各个标签类型，提取所述行程数据中包含的标签类型。
在本实施方式中，在提取了行程数据中包含的标签类型之后，可以填充用户实际信息。所述用户实际信息同样可以从行程数据中提取。例如，行程数据中包括东方航空公司的机票订单，该机票的出发城市为“北京”、目的城市为“杭州”，根据该机票订单，从而可以得到用户实际信息为“北京”和“杭州”，从而可以在出发城市的标签类型后填充北京，在目的城市的标签类型后填充杭州。这样便可以得到该用户的多个标签。
在本实施方式中，用户实际信息还可以根据对行程数据进行判定得到。具体地，行程数据中可以包括与用户相关的数值信息。例如，所述数值信息可以包括用户的账号等级、用户的消费账单等。在从行程数据中提取出用户的数值信息之后，可以将提取的数值信息与指定的标准数值信息进行对比，并根据对比结果生成用户实际信息。例如，用户的年消费账单为10万元，指定的标准年消费账单为5万元，超过该标准年消费账单的用户可以对应“中上”的用户实际信息。这样，结合标签类型“购买力”，从而可以得到该用户的一个标签为“购买力：中上”。
在本实施方式中，用户的标签可以按照层级进行设定。具体地，对于“出行人员”这个标签类型，通过分析用户的订单可知，用户的订单中共包括2个人，因此可以为用户设定“出行人员：2人”的标签。进一步地，可以继续分析用户的订单中与出行人员相关的信息。例如，这两个出行人员中，一个为男性，一个为女性，并且男性和女性的年龄差别在4岁以内，此时，可以进一步地判定出行的两个人为情侣关系，因此可以为用户再次设定“出行人员：情侣关系”这样的标签。也就是说，在本实施方式中，针对同一个用户的同一个标签类型，也可以对应不同的用户实际信息。
步骤s5：从所述用户中确定行程数据中具备相同地理位置信息的目标用户群。
在本实施方式中，确定所述目标用户群的方式可以包括由在线旅游平台的商家预先指定一个地理位置，指定的该地理位置可以是该商家的业务所处的地理位置。例如，对于在迪拜提供专车服务的商家而言，其指定的地理位置中可以包括迪拜。这样，可以在各个用户的行程数据中查询是否包含商家指定的地理位置的信息。如果包含，则可以将用户加入目标用户群。在本实施方式中，确定所述目标用户群的方式还可以包括将所述各个用户中，目的地相同的用户划分至所述目标用户群中。具体地，所述目的地可以指用户出行规划中准备抵达的地理位置。例如，用户从苏州去三亚游玩，三亚就可以是所述目的地。又例如，用户准备从苏州去三亚游玩，途中还准备在嘉兴逗留一段时间，那么嘉兴也可以作为所述目的地。这样，只要用户的行程数据中具备相同的目的地，便可以将用户划分至同一个目标用户群中。此外，还可以将行程相同的用户划分至所述目标用户群中。具体地，用户的行程中通常包括至少两个地理位置，一个是出发地点，另一个是最终抵达地点。此外，用户的行程中还可以包括出发地点和最终抵达地点之外的临时逗留地点。这样，用户的行程可以由所述至少两个地理位置来表示。那么，在确定所述目标用户群时，可以判断用户的行程数据中是否包含所述至少两个地理位置，只有在包含所述至少两个地理位置时，才将用户划分至所述目标用户群中。
步骤s7：将所述目标用户群中标签符合所述聚合规则的用户聚合至所述业务对象的用户集合中。
在本实施方式中，业务对象可以具备聚合规则，并且各个用户可以具备绑定的标签。其中，聚合规则可以限定业务对象的商家关注的用户群体。标签则可以表征用户的行程。因此，可以基于所述聚合规则，将各个用户聚合至业务对象的用户集合中。
在本实施方式中，所述用户集合可以由业务对象的聚合规则决定。例如，所述业务对象的聚合规则为“年龄在18至30岁之间，性别为男性”，那么根据该聚合规则得到的用户集合中的各个用户的年龄均可以在18至30岁之间并且性别为男性。
在本实施方式中，将用户聚合至业务对象的用户集合中的方式可以包括遍历为用户绑定的各个标签，当存在满足所述业务对象的聚合规则的标签时，将该用户加入所述业务对象的用户集合中。例如，某个业务对象的聚合规则为“抵达城市为曼谷”，那么可以将具备标签“目的城市：曼谷”的用户划分至该业务对象的用户集合中。
需要说明的是，所述业务对象的聚合规则可能不止一个，那么在将所述目标用户群中标签符合所述聚合规则的用户聚合至所述业务对象的用户集合中时，可以针对每个聚合规则，若在用户的各个标签中均具备满足每个所述聚合规则的标签，将所述用户加入所述业务对象的用户集合中。例如，某个业务对象的聚合规则为“目的地为三亚并且消费水平为中上”，该聚合规则中实际包含了两个聚合规则，一个是“目的地为三亚”，另一个是“消费水平为中上以上”。那么当前有两个用户，这两个用户均具备标签“目的地：三亚”，但是其中一个用户还具备标签“购买力：中上”，而另一个用户在具备标签“购买力：低”，那么只有同时具备“目的地：三亚”和“购买力：中上”这两个标签的用户才能被聚合至该业务对象对应的用户集合中。
在本实施方式中，在将用户聚合至业务对象的用户集合中后，可以为处于同一个用户集合中的用户分配该业务对象的标识。所述标识可以是所述业务对象在服务器中预先设置的编号。需要说明的是，同一个用户可能同时具备多个业务对象的标识，原因在于，同一个用户可能同时满足多个业务对象的聚合规则，而被聚合至不同的用户集合中。
步骤s9：将所述业务对象的业务信息提供给所述用户集合中的用户。
在本实施方式中，在将用户分别聚合至业务对象的用户集合中后，便可以将所述业务对象的业务信息提供给所述用户集合中的用户。
在本实施方式中，所述业务信息可以由业务对象的商家预先设置，并存储于服务器中。所述业务信息可以是业务对象的促销信息、推广信息等。所述业务信息在服务器中可以与业务对象的标识进行关联存储。同时，在服务器中，各个用户的账号也可以与业务对象的标识相关联。这样，当服务器需要向用户提供业务信息时，可以将业务对象的业务信息提供给具备所述业务对象的标识的用户。
在一个具体应用场景中，用户a通过手机在携程网应用程序中反复浏览了上海到普吉岛的旅游产品。此时，携程网的后台服务器便可以为该用户a设定“目的城市：普吉岛”、“出发城市：上海”的标签。携程网中的负责进行普吉岛接机服务的商家可以预先设定聚合规则为“来普吉岛的游客”，此时，用户a的标签“目的城市：普吉岛”便满足该聚合规则，因此可以被聚合至普吉岛接机服务的用户集合中。这样，用户a便可以在携程网的应用程序中接收到商家推送的有关普吉岛接机服务的信息，这些信息可以包括接机时间、接机费用以及接机联系方式等。此外，携程网中负责售卖上海到普吉岛机票的商家可以预先设定聚合规则“出发城市为上海及其周边城市并且抵达城市或者中转城市为普吉岛”，该聚合规则中实际上有两个聚合规则，一个为“出发城市为上海及其周边城市”，另一个聚合规则为“抵达城市或者中转城市为普吉岛”。这样，用户a的“目的城市：普吉岛”以及“出发城市：上海”的这两个标签正好满足该商家的两个聚合规则，从而用户a也可以被聚合至上海到普吉岛机票的用户集合中。而如果另一个用户b的标签为“目的城市：普吉岛”以及“出发城市：北京”，由于其中“出发城市：北京”不满足商家设定的“出发城市为上海及其周边城市”的聚合规则，因此用户b无法加入上海到普吉岛机票的用户集合中。
在本申请一个实施方式中，所述聚合规则在实际应用时可以限定不同的条件。具体地，所述聚合规则可以限定了最低出行费用。那么，在将所述目标用户群中标签符合所述聚合规则的用户聚合至所述业务对象的用户集合中时，可以将所述目标用户群中具备出行费用标签，并且出行费用大于或者等于所述最低出行费用的用户聚合至所述业务对象的用户集合中。
在本申请另一个实施方式中，所述聚合规则还可以限定了交通工具类型。所述交通工具类型例如可以包括飞机、火车、汽车、轮船等。这样，在将所述目标用户群中标签符合所述聚合规则的用户聚合至所述业务对象的用户集合中时，可以将所述目标用户群中具备交通工具类型标签，并且交通工具类型与所述聚合规则限定的交通工具类型一致的用户聚合至所述业务对象的用户集合中。
在本申请另一个实施方式中，所述聚合规则还可以限定了出行时段。所述出行时段可以包括出发时段、抵达时段、中转时段等。那么在将所述目标用户群中标签符合所述聚合规则的用户聚合至所述业务对象的用户集合中时，可以将所述目标用户群中具备出行时间标签，并且出行时间处于所述出行时段内的用户聚合至所述业务对象的用户集合中。例如，所述出行时段为2017年3月7日12点至14点，那么所述目标用户群中的某个用户具备出行时间标签，并且该出行时间标签中包含的出行时间为2017年3月7日13点10分，那么该用户便可以被聚合至业务对象的用户集合中。
在本申请一个实施方式中，服务器还可以设置人数控制策略，例如当业务对象对应的用户集合中包含的用户人数大于或者等于第一人数阈值时，可以视为该业务对象的聚合规则太过宽泛，此时服务器可以向业务对象的商家发出修改聚合规则的提示信息。例如，业务对象的商家原本的聚合规则为“抵达城市：北京”，根据该聚合规则聚合的用户人数可以达到3万人，而第一人数阈值仅为5000人，此时，服务器可以向商家的客户端发送修改聚合规则或者增加聚合规则的提示信息，以减少根据聚合规则得到的用户人数。商家可以增加额外的聚合规则“相关产品：故宫门票”、“抵达时间：2017年1月20日”，这样最终便可以形成三个聚合规则。根据这三个聚合规则聚合的用户人数可以为500人，符合服务器的人数控制策略。
在本申请一个实施方式中，当业务对象对应的用户集合中包含的用户人数小于或者等于第二人数阈值时，可以视为该业务对象的聚合规则太过狭窄，此时服务器可以向业务对象的商家发出修改聚合规则的提示信息。例如，业务对象的商家原本的聚合规则为“抵达城市：北京”、“航班号：tm56xx9”、“抵达时间：2017年1月20日”，根据这三个聚合规则聚合的用户人数仅为10人，而第二人数阈值为200人，此时，服务器可以向商家的客户端发送修改聚合规则或者减少聚合规则的提示信息，以减少根据聚合规则得到的用户人数。商家可以选择将原先的聚合规则“抵达时间：2017年1月20日”修改为“抵达时间：2017年1月10日至2017年1月20日”，这样，根据修改后的三个聚合规则聚合的用户人数可以为500人，符合服务器的人数控制策略。
在本申请一个实施方式中，在向用户集合中的用户提供业务信息时，可以根据当前的时间，提供对应的业务信息。具体地，当用户集合中的用户具备到站时间节点的标签时，可以确定当前的时间节点与所述到站时间节点之间的差值。其中，所述到站时间节点可以表征交通工具抵达目的地的时间节点。例如，某个用户当前处于出售车票的用户集合中，该用户集合的聚合规则为“抵达城市为上海，抵达时间为14点20分，交通工具为高铁”。那么14点20分便可以是所述到站时间节点。服务器可以计算当前的时间节点与所述到站时间节点之间的差值，该差值可以是绝对值。那么当所述差值小于或者等于指定阈值时，可以向所述用户集合中的用户提供与所述到站时间节点相对应的业务信息。例如，在14点10分的时候，计算的差值为10分钟，所述指定阈值也为10分钟，因此可以向该用户集合中的用户提供即将到站的提示信息，并向用户集合中的用户推送上海当地的旅游景点信息以及天气信息。
在本申请一个实施方式中，在向用户提供业务信息时，可以设定疲劳度控制策略。该疲劳度控制策略可以限定业务信息提供的次数、时段以及类别。具体地，服务器可以判断当前系统时间是否处于指定时段内，当处于时，停止向用户提供业务信息，直至当前系统时间处于指定时段外为止。例如，所述指定时段为晚上11点至次日早晨8点，在这个时段内服务器停止向用户提供业务信息。
此外，在本实施方式中，服务器还可以统计指定时间周期内向同一个用户提供业务信息的次数，当统计的次数大于或者等于指定次数阈值时，停止向所述用户提供业务信息。所述指定时间周期例如可以为一个自然日。例如，服务器可以统计截至目前当天向同一个用户提供的业务信息的次数，若该次数为5次，而一天之内的指定次数阈值仅为3，那么此时服务器可以停止向用户提供业务信息，直至第二天。
在本实施方式中，用户可以向服务器反馈是否屏蔽某一类型的业务信息。这样，服务器可以接收用户反馈的针对指定类型的业务信息的屏蔽指令，并且响应于所述屏蔽指令，停止向所述用户提供所述指定类型的业务信息，直至接收到所述用户反馈的针对所述指定类型的业务信息的接触屏蔽指令为止。例如，用户在客户端中将优惠打折信息全部屏蔽了，那么服务器则停止向用户提供优惠打折信息，直至用户解除屏蔽为止。
请参阅图4，本申请实施方式还提供一种服务器，所述服务器包括网络通信端口100、存储器200以及处理器300。
所述网络通信端口100，用于与用户的客户端进行网络数据通信；
所述存储器200，用于存储能够被所述处理器执行的计算机程序以及存储至少一个业务对象的聚合规则，所述聚合规则用于限定所述业务对象的用户群体；
所述处理器300，用于在执行所述计算机程序时，能够实现以下步骤：
通过所述网络通信端口获取用户的行程数据，所述行程数据中包含至少一个地理位置信息；从所述行程数据中提取至少一个标签，并为所述行程数据对应的用户绑定所述至少一个标签；其中，所述标签用于表征用户的行程；从所述用户中确定行程数据中具备相同地理位置信息的目标用户群；将所述目标用户群中标签符合所述聚合规则的用户聚合至所述业务对象的用户集合中；将所述业务对象的业务信息提供给所述用户集合中的用户。
在本实施方式中，所述网络通信端口100可以是与不同的通信协议进行绑定，从而可以发送或接收不同数据的虚拟端口。例如，所述网络通信端口可以是负责进行web数据通信的80号端口，也可以是负责进行ftp数据通信的21号端口，还可以是负责进行邮件数据通信的25号端口。此外，所述网络通信端口还可以是实体的通信接口或者通信芯片。例如，其可以为无线移动网络通信芯片，如gsm、cdma等；其还可以为wifi芯片；其还可以为蓝牙芯片。
在本实施方式中，所述存储器200可以是用于保存信息的记忆设备。在数字系统中，能保存二进制数据的设备可以是存储器；在集成电路中，一个没有实物形式的具有存储功能的电路也可以为存储器，如ram、fifo等；在系统中，具有实物形式的存储设备也可以叫存储器，如内存条、tf卡等。
所述处理器300可以按任何适当的方式实现。例如，处理器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(applicationspecificintegratedcircuit，asic)、可编程逻辑控制器和嵌入微控制器的形式等等。本申请并不作限定。
上述实施方式公开的服务器，其网络通信端口100、存储器200以及处理器300实现的具体功能，可以与本申请中业务信息的提供方法的实施方式相对照解释，可以实现本申请的业务信息的提供方法的实施方式并达到方法实施方式的技术效果。
本申请还提供一种业务信息的接收方法。所述方法可以应用于用户的客户端中。其中，所述客户端可以是用户用于访问在线旅游平台的电子设备。具体地，所述客户端例如可以是平板电脑、智能手机、数字助理、智能可穿戴设备等。所述客户端还可以是安装于上述的电子设备中的软件。例如，所述客户端可以是携程网、去哪儿网等在线旅游平台的应用(application，app)。请参阅图5，所述方法包括以下步骤。
s51：向服务器提供用户的包括至少一个地理位置信息的行程数据，以用于所述服务器根据所述地理位置信息确定所述用户属于的用户群，以及根据所述行程数据为所述用户绑定至少一个标签，以及将所述用户群中标签符合聚合规则的用户聚合至用户集合中；其中，所述标签用于表征所述用户的行程；所述聚合规则与业务对象对应。
在本实施方式中，所述用户的行程数据可以是用户在访问在线旅游平台时产生的能够表征用户行为特征的数据。例如，所述行程数据可以包括用户在在线旅游平台中的订单数据，还可以包括用户在在线旅游平台中浏览商品的浏览数据，还可以包括用户加入购物车中但并没有结算的拟购对象数据。当然，随着在线旅游平台功能的不断丰富，用户在访问在线旅游平台时，还可能产生其他的数据，只要这些数据能够体现用户的行为特征，均属于所述行程数据的范畴。其中，所述浏览数据可以根据用户在访问在线旅游平台过程中的操作行为生成。所述操作行为可以包括点击商品链接、一段时间内持续浏览商品的页面等等。这样，所述浏览数据中则可以包括用户访问的商品链接、在每个商品页面中停留的时间等信息。
在本实施方式中，用户的行为特征可以指用户的旅程安排、购买力、感兴趣的商品等信息。其中，用户的旅程安排可以通过用户在在线旅游平台中购买的旅游产品、机票、火车票、汽车票等与出行相关的商品数据分析得到。用户的购买力可以根据用户在在线旅游平台中消费的金额数据分析得到。用户感兴趣的商品则可以根据用户的浏览数据中浏览次数和浏览频率分析得到。
在本实施方式中，客户端可以通过埋点的方式或者借助于mysqlmtop向服务器提供行程数据。具体地，埋点的方式可以是服务器响应于用户的客户端发来的页面显示请求，向所述用户的客户端反馈待显示的页面元素，并为各个页面元素绑定用于获取行程数据的代码。其中，当页面元素被触发时，与页面元素相绑定的代码也被执行。例如，在当前在线旅游平台的页面中，可以在各个商品的链接中以及加入购物车的按键中写入代码，当用户点击商品链接或者点击加入购物车的按键时，代码便被自动执行。执行之后便可以将点击商品链接的事件发送至服务器，也可以将购物车中的商品信息发送至服务器，这样，在用户通过客户端访问在线旅游平台时，便可以不断触发页面元素中绑定的代码，从而可以在代码被执行时，向服务器提供用户的行程数据。
在本实施方式中，用户在通过客户端访问在线旅游平台时，服务器可以向客户端提供mtop接口，该mtop接口可以采用http协议。当用户在客户端中浏览在线旅游平台时，客户端可以向服务器的mtop接口发送数据获取请求。所述数据获取请求可以用于从服务器处获取预计在客户端的当前页面中显示的页面元素。例如，用户在访问某个商品的介绍页面，那么客户端向服务器发送的数据获取请求可以用于从服务器中获取该介绍页面中的文字信息、图片信息以及视频信息等。这样，在客户端与服务器之间可以通过mtop接口建立通信链路，客户端可以通过该通信链路从服务器处获取页面数据。在本实施方式中，客户端同样可以通过该通信链路，将用户在浏览当前页面时产生的行程数据传输至服务器。也就是说，通过复用该通信链路，客户端不仅可以从服务器处下载待显示的页面元素，还可以将用户的数据上传至服务器，避免了建立额外的信道进行行程数据的上传过程，从而提高了提供行程数据的效率。
在本实施方式中，为了提高提供行程数据的效率，可以结合上述两种方式。具体地，行程数据中的订单数据和拟购对象数据可以通过mtop的方式上传至服务器。而浏览数据则可以通过埋点的方式上传至服务器。上传至服务器的数据可以存储于服务器的数据库中。
在本实施方式中，所述行程数据可以用于表明用户的出行计划。所述出行计划中通常会包括出发地点、目标地点或者中转地点中的至少一个。因此，所述行程数据中可以包含至少一个地理位置信息。所述地理位置信息包括目的地信息、中转站信息、起始地信息中的至少一种。所述地理位置信息可以是地理位置的实际名称，也可以是用于表征地理位置的编码。例如，用户的行程数据中包含目的地为三亚的数据，那么所述地理位置信息可以是“三亚”，也可以是用于表征三亚的地理位置编码“sy”。
在本实施方式中，服务器在接收到客户端提供的行程数据后，可以基于用户的行程数据，为用户绑定用于表征其行程的至少一个标签。在本实施方式中，所述标签可以是一个短语，该短语中可以描述用户的行程信息。例如，所述标签可以是“出行时间：2017年1月36日”、“出行方式：飞机”、“航班号：tm52xx8”、“购买力：中等”、“相关产品：北极光”等等。通常，用户的行程信息可以通过出行时间、出行费用、出行人数、出行人员性别以及交通工具类型来表征，因此，所述标签可以包括出行时间、出行费用、出行人数、出行人员性别以及交通工具类型中的至少一种。
在本实施方式中，服务器可以从各个用户中确定行程数据中具备相同地理位置信息的用户群。确定所述用户群的方式可以包括由在线旅游平台的商家预先指定一个地理位置，指定的该地理位置可以是该商家的业务所处的地理位置。例如，对于在迪拜提供专车服务的商家而言，其指定的地理位置中可以包括迪拜。这样，可以在各个用户的行程数据中查询是否包含商家指定的地理位置的信息。如果包含，则可以将用户加入用户群。在本实施方式中，确定所述用户群的方式还可以包括将所述各个用户中，目的地相同的用户划分至所述用户群中。具体地，所述目的地可以指用户出行规划中准备抵达的地理位置。例如，用户从苏州去三亚游玩，三亚就可以是所述目的地。又例如，用户准备从苏州去三亚游玩，途中还准备在嘉兴逗留一段时间，那么嘉兴也可以作为所述目的地。这样，只要用户的行程数据中具备相同的目的地，便可以将用户划分至同一个用户群中。此外，还可以将行程相同的用户划分至所述用户群中。具体地，用户的行程中通常包括至少两个地理位置，一个是出发地点，另一个是最终抵达地点。此外，用户的行程中还可以包括出发地点和最终抵达地点之外的临时逗留地点。这样，用户的行程可以由所述至少两个地理位置来表示。那么，在确定所述用户群时，可以判断用户的行程数据中是否包含所述至少两个地理位置，只有在包含所述至少两个地理位置时，才将用户划分至所述用户群中。
在本实施方式中，服务器中可以存储业务对象的业务信息，为了将业务信息提供给合适的用户，每个业务对象均可以具备聚合规则，所述聚合规则可以限定业务对象的用户群体。具体地，所述业务对象可以是在在线旅游平台中出售的旅游产品。所述旅游产品可以是实体产品。例如机票、门票等。所述旅游产品还可以是虚拟产品。例如在目的城市做spa的资格、专车接送服务等。当然，有些旅游产品既可以通过实体产品的形式出现，也可以通过虚拟产品的形式出现。例如，对于客运公司出售的车票而言，可以是纸质的实体产品，也可以是类似二维码、序列号等形式的虚拟产品。
在本实施方式中，所述业务对象的聚合规则可以用于限定所述业务对象的商家关注的用户群体。例如，对于提供专车接送服务的商家而言，其对应的聚合规则可以是出行费用超过指定数值。这样，该专车接送服务的聚合规则则可以表明，该专车接送服务的商家在众多用户中仅关注消费能力较高的用户群体。
在本实施方式中，业务对象可以具备聚合规则，并且各个用户可以具备绑定的标签。其中，聚合规则可以限定业务对象的商家关注的用户群体。标签则可以表征用户的行程。因此，可以基于所述聚合规则，将各个用户聚合至业务对象的用户集合中。
在本实施方式中，所述用户集合可以由业务对象的聚合规则决定。例如，所述业务对象的聚合规则为“年龄在18至30岁之间，性别为男性”，那么根据该聚合规则得到的用户集合中的各个用户的年龄均可以在18至30岁之间并且性别为男性。
在本实施方式中，将用户聚合至业务对象的用户集合中的方式可以包括遍历为用户绑定的各个标签，当存在符合所述业务对象的聚合规则的标签时，将该用户加入所述业务对象的用户集合中。例如，某个业务对象的聚合规则为“抵达城市为曼谷”，那么可以将具备标签“目的城市：曼谷”的用户划分至该业务对象的用户集合中。
s53：接收所述服务器反馈的业务信息；其中，所述业务信息表示所述用户所在用户集合对应的业务对象。
在本实施方式中，在将用户聚合至业务对象的用户集合中后，便可以将所述业务对象的业务信息提供给所述用户集合中的用户。
在本实施方式中，所述业务信息可以由业务对象的商家预先设置，并存储于服务器中。所述业务信息可以表示所述用户所在用户集合对应的业务对象。具体地，所述业务信息可以是业务对象的促销信息、推广信息等。所述业务信息在服务器中可以与业务对象的标识进行关联存储。同时，在服务器中，各个用户所在的用户集合也可以与业务对象的标识相关联。这样，当服务器需要向用户集合中的用户提供业务信息时，可以将业务对象的业务信息提供给具备所述业务对象的标识的用户集合中的用户。
请参阅图6，本申请还提供一种客户端，所述客户端包括网络通信端口110、存储器210、显示器310以及处理器410。
其中，所述网络通信端口110，用于与服务器进行网络数据通信。
所述存储器210，用于存储所述服务器反馈的业务信息。
所述显示器310，用于显示所述业务信息。
所述处理器410，用于控制所述网络通信端口向所述服务器提供用户的包括至少一个地理位置信息的行程数据，以用于所述服务器根据所述地理位置信息确定所述用户属于的用户群，以及根据所述行程数据为所述用户绑定至少一个标签，以及将所述用户群中标签符合聚合规则的用户聚合至用户集合中；其中，所述标签用于表征所述用户的行程；所述聚合规则与业务对象对应；控制所述网络通信端口接收所述服务器反馈的业务信息；其中，所述业务信息表示所述用户所在用户集合对应的业务对象；将所述业务信息写入所述存储器中并将所述业务信息通过所述显示器向所述用户展示。
在本实施方式中，所述网络通信端口110可以是与不同的通信协议进行绑定，从而可以发送或接收不同数据的虚拟端口。例如，所述网络通信端口可以是负责进行web数据通信的80号端口，也可以是负责进行ftp数据通信的21号端口，还可以是负责进行邮件数据通信的25号端口。此外，所述网络通信端口还可以是实体的通信接口或者通信芯片。例如，其可以为无线移动网络通信芯片，如gsm、cdma等；其还可以为wifi芯片；其还可以为蓝牙芯片。
在本实施方式中，所述存储器210可以是用于保存信息的记忆设备。在数字系统中，能保存二进制数据的设备可以是存储器；在集成电路中，一个没有实物形式的具有存储功能的电路也可以为存储器，如ram、fifo等；在系统中，具有实物形式的存储设备也可以叫存储器，如内存条、tf卡等。
所述显示器310可以是将一定的电子文件通过特定的传输设备显示到屏幕上再反射到人眼的显示工具。所述显示器可以包括液晶lcd显示屏、阴极射线管crt显示屏、发光二极管led显示屏等。
所述处理器410可以按任何适当的方式实现。例如，处理器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(applicationspecificintegratedcircuit，asic)、可编程逻辑控制器和嵌入微控制器的形式等等。本申请并不作限定。
上述实施方式公开的客户端，其网络通信端口110、存储器210、显示器310以及处理器410实现的具体功能，可以与本申请中业务信息的接收方法的实施方式相对照解释，可以实现本申请的业务信息的接收方法的实施方式并达到方法实施方式的技术效果。
请参阅图7，本申请还提供一种用户聚合方法，所述方法包括以下步骤。
s71：获取用户的行程数据，所述行程数据中包含至少一个属性信息。
在本实施方式中，所述用户的行程数据可以是用户在访问在线旅游平台时产生的能够表征用户行为特征的数据。例如，所述行程数据可以包括用户在在线旅游平台中的订单数据，还可以包括用户在在线旅游平台中浏览商品的浏览数据，还可以包括用户加入购物车中但并没有结算的拟购对象数据。当然，随着在线旅游平台功能的不断丰富，用户在访问在线旅游平台时，还可能产生其他的数据，只要这些数据能够体现用户的行为特征，均属于所述行程数据的范畴。其中，所述浏览数据可以根据用户在访问在线旅游平台过程中的操作行为生成。所述操作行为可以包括点击商品链接、一段时间内持续浏览商品的页面等等。这样，所述浏览数据中则可以包括用户访问的商品链接、在每个商品页面中停留的时间等信息。
在本实施方式中，用户的行为特征可以指用户的旅程安排、购买力、感兴趣的商品等信息。其中，用户的旅程安排可以通过用户在在线旅游平台中购买的旅游产品、机票、火车票、汽车票等与出行相关的商品数据分析得到。用户的购买力可以根据用户在在线旅游平台中消费的金额数据分析得到。用户感兴趣的商品则可以根据用户的浏览数据中浏览次数和浏览频率分析得到。
在本实施方式中，获取行程数据的方式可以包括通过埋点的方式或者借助于mysqlmtop获取行程数据。具体地，埋点的方式可以是服务器响应于用户的客户端发来的页面显示请求，向所述用户的客户端反馈待显示的页面元素，并为各个页面元素绑定用于获取行程数据的代码。其中，当页面元素被触发时，与页面元素相绑定的代码也被执行。例如，在当前在线旅游平台的页面中，可以在各个商品的链接中以及加入购物车的按键中写入代码，当用户点击商品链接或者点击加入购物车的按键时，代码便被自动执行。执行之后便可以将点击商品链接的事件发送至服务器，也可以将购物车中的商品信息发送至服务器，这样，服务器便可以在代码被执行时，接收所述用户的客户端反馈的行程数据，从而完成行程数据采集的过程。
在本实施方式中，用户在通过客户端访问在线旅游平台时，服务器可以向客户端提供mtop接口，该mtop接口可以采用http协议。当用户在客户端中浏览在线旅游平台时，客户端可以向服务器的mtop接口发送数据获取请求。所述数据获取请求可以用于从服务器处获取预计在客户端的当前页面中显示的页面元素。例如，用户在访问某个商品的介绍页面，那么客户端向服务器发送的数据获取请求可以用于从服务器中获取该介绍页面中的文字信息、图片信息以及视频信息等。这样，在客户端与服务器之间可以通过mtop接口建立通信链路，客户端可以通过该通信链路从服务器处获取页面数据。在本实施方式中，客户端同样可以通过该通信链路，将用户在浏览当前页面时产生的行程数据传输至服务器。也就是说，通过复用该通信链路，客户端不仅可以从服务器处下载待显示的页面元素，还可以将用户的数据上传至服务器，避免了建立额外的信道进行行程数据的上传过程，从而提高了获取行程数据的效率。
在本实施方式中，为了提高获取行程数据的效率，可以结合上述两种方式。具体地，行程数据中的订单数据和拟购对象数据可以通过mtop的方式上传至服务器。而浏览数据则可以通过埋点的方式上传至服务器。上传至服务器的数据可以存储于服务器的数据库中。
在本实施方式中，所述行程数据中通常包括较多的信息。例如，所述行程数据中可以包括行程时间、出发地点、中转地点、目的地点、行程花费、航班号、航班时间等信息。上述的这些信息均可以作为所述属性信息。在本实施方式中，所述属性信息可以作为行程数据的筛选条件，根据不同的属性信息，可以将众多的行程数据进行分类。例如，可以将在同一天处于同一个目的地点的行程数据归为一类；还可以将在同一时间乘坐同一个航班号的行程数据归位一类。
s73：从所述行程数据中提取至少一个标签，并为所述行程数据对应的用户绑定所述至少一个标签。
在本实施方式中，所述标签可以是一个短语，该短语中可以描述用户的行程信息。例如，所述标签可以是“出行时间：2017年1月36日”、“出行方式：飞机”、“航班号：tm52xx8”、“购买力：中等”、“相关产品：北极光”等等。通常，用户的行程信息可以通过出行时间、出行费用、出行人数、出行人员性别以及交通工具类型来表征，因此，所述标签可以包括出行时间、出行费用、出行人数、出行人员性别以及交通工具类型中的至少一种。
在本实施方式中，所述标签中可以包括标签类型和用户实际信息。在为用户设定标签时，可以分别设定标签类型和用户实际信息。其中，所述标签类型可以用于区分不同的标签。例如，所述标签类型可以包括“出行时间”、“出行方式”、“目的城市”、“出发城市”、“相关产品”等等。所述标签类型可以是由服务器分析大量的行程数据后总结得到的，并且标签类型可以随着行程数据的增加而增加。这样，在服务器中便可以存储标签类型的列表，在该列表中可以列出各个标签类型。当服务器对新的行程数据进行分析时，可以根据所述列表中的各个标签类型，提取所述行程数据中包含的标签类型。
在本实施方式中，在提取了行程数据中包含的标签类型之后，可以填充用户实际信息。所述用户实际信息同样可以从行程数据中提取。例如，行程数据中包括东方航空公司的机票订单，该机票的出发城市为“北京”、目的城市为“杭州”，根据该机票订单，从而可以得到用户实际信息为“北京”和“杭州”，从而可以在出发城市的标签类型后填充北京，在目的城市的标签类型后填充杭州。这样便可以得到该用户的多个标签。
在本实施方式中，用户实际信息还可以根据对行程数据进行判定得到。具体地，行程数据中可以包括与用户相关的数值信息。例如，所述数值信息可以包括用户的账号等级、用户的消费账单等。在从行程数据中提取出用户的数值信息之后，可以将提取的数值信息与指定的标准数值信息进行对比，并根据对比结果生成用户实际信息。例如，用户的年消费账单为10万元，指定的标准年消费账单为5万元，超过该标准年消费账单的用户可以对应“中上”的用户实际信息。这样，结合标签类型“购买力”，从而可以得到该用户的一个标签为“购买力：中上”。
在本实施方式中，用户的标签可以按照层级进行设定。具体地，对于“出行人员”这个标签类型，通过分析用户的订单可知，用户的订单中共包括2个人，因此可以为用户设定“出行人员：2人”的标签。进一步地，可以继续分析用户的订单中与出行人员相关的信息。例如，这两个出行人员中，一个为男性，一个为女性，并且男性和女性的年龄差别在4岁以内，此时，可以进一步地判定出行的两个人为情侣关系，因此可以为用户再次设定“出行人员：情侣关系”这样的标签。也就是说，在本实施方式中，针对同一个用户的同一个标签类型，也可以对应不同的用户实际信息。
s75：从所述用户中确定行程数据中具备相同属性信息的目标用户群。
在本实施方式中，确定所述目标用户群的方式可以包括由在线旅游平台的商家预先指定一个属性信息，指定的该属性信息可以是该商家的业务所侧重的属性信息。例如，对于在迪拜提供专车服务的商家而言，其指定的属性信息可以是目的地点为迪拜。这样，可以在各个用户的行程数据中查询是否包含商家指定的属性信息。如果包含，则可以将用户加入目标用户群。在本实施方式中，确定所述目标用户群的方式还可以包括将所述各个用户中，具备相同的表征地理位置的属性信息的用户划分至所述目标用户群中。具体地，所述表征地理位置的属性信息例如可以是目的地。所述目的地可以指用户出行规划中准备抵达的地理位置。例如，用户从苏州去三亚游玩，三亚就可以是所述目的地。又例如，用户准备从苏州去三亚游玩，途中还准备在嘉兴逗留一段时间，那么嘉兴也可以作为所述目的地。这样，只要用户的行程数据中具备相同的目的地，便可以将用户划分至同一个目标用户群中。
s77：将所述目标用户群中标签符合聚合规则的用户聚合至业务对象的用户集合中。
在本实施方式中，所述业务对象可以是在在线旅游平台中出售的旅游产品。所述旅游产品可以是实体产品。例如机票、门票等。所述旅游产品还可以是虚拟产品。例如在目的城市做spa的资格、专车接送服务等。当然，有些旅游产品既可以通过实体产品的形式出现，也可以通过虚拟产品的形式出现。例如，对于客运公司出售的车票而言，可以是纸质的实体产品，也可以是类似二维码、序列号等形式的虚拟产品。
在本实施方式中，所述业务对象可以具备聚合规则。所述聚合规则可以用于限定所述业务对象的商家关注的用户群体。例如，对于提供专车接送服务的商家而言，其对应的聚合规则可以是出行费用超过指定数值。这样，该专车接送服务的聚合规则则可以表明，该专车接送服务的商家在众多用户中仅关注消费能力较高的用户群体。
在本实施方式中，各个业务对象的聚合规则可以由业务对象的商家预先指定。例如，对于提供专车接送服务的商家而言，其指定的聚合规则可以是出行费用在两万以上。这样，各个业务对象的商家在指定了聚合规则之后，可以将指定的聚合规则存储于用于执行业务信息的提供方法流程的服务器中。
在本实施方式中，业务对象的聚合规则还可以由服务器通过分析购买该业务对象的用户的信息得到。具体地，用户的信息中可以包含用户在进行账号注册时填写的信息以及用户在在线旅游平台中购买的旅游产品的信息。服务器在分析用户的信息时，可以统计用户信息中相似的信息，以生成聚合规则。例如，对于购买头等舱机票的用户而言，其年龄层基本都在30岁至60岁之间，并且用户的平均月消费均在2万元以上。因此，服务器根据对购买头等舱机票的用户的信息进行分析之后，可以将年龄在30岁至60岁之间并且平均月消费大于或者等于2万元作为头等舱机票的聚合规则。在服务器分析得到各个业务对象的聚合规则后，可以在本地保存各个业务对象的聚合规则。
在本实施方式中，业务对象可以具备聚合规则，并且各个用户可以具备绑定的标签。其中，聚合规则可以限定业务对象的商家关注的用户群体。标签则可以表征用户的行程。因此，可以基于所述聚合规则，将各个用户聚合至业务对象的用户集合中。
在本实施方式中，所述用户集合可以由业务对象的聚合规则决定。例如，所述业务对象的聚合规则为“年龄在18至30岁之间，性别为男性”，那么根据该聚合规则得到的用户集合中的各个用户的年龄均可以在18至30岁之间并且性别为男性。
在本实施方式中，将用户聚合至业务对象的用户集合中的方式可以包括遍历为用户绑定的各个标签，当存在满足所述业务对象的聚合规则的标签时，将该用户加入所述业务对象的用户集合中。例如，某个业务对象的聚合规则为“抵达城市为曼谷”，那么可以将具备标签“目的城市：曼谷”的用户划分至该业务对象的用户集合中。
需要说明的是，所述业务对象的聚合规则可能不止一个，那么在将所述目标用户群中标签符合所述聚合规则的用户聚合至所述业务对象的用户集合中时，可以针对每个聚合规则，若在用户的各个标签中均具备满足每个所述聚合规则的标签，将所述用户加入所述业务对象的用户集合中。例如，某个业务对象的聚合规则为“目的地为三亚并且消费水平为中上”，该聚合规则中实际包含了两个聚合规则，一个是“目的地为三亚”，另一个是“消费水平为中上以上”。那么当前有两个用户，这两个用户均具备标签“目的地：三亚”，但是其中一个用户还具备标签“购买力：中上”，而另一个用户在具备标签“购买力：低”，那么只有同时具备“目的地：三亚”和“购买力：中上”这两个标签的用户才能被聚合至该业务对象对应的用户集合中。
在本实施方式中，在将用户聚合至业务对象的用户集合中后，可以为处于同一个用户集合中的用户分配该业务对象的标识。所述标识可以是所述业务对象在服务器中预先设置的编号。需要说明的是，同一个用户可能同时具备多个业务对象的标识，原因在于，同一个用户可能同时满足多个业务对象的聚合规则，而被聚合至不同的用户集合中。
在本申请一个实施方式中，在对目标用户群中的用户进行聚合之后，还可以将所述业务对象的业务信息提供给所述用户集合中的用户。具体地，所述业务信息可以由业务对象的商家预先设置，并存储于服务器中。所述业务信息可以是业务对象的促销信息、推广信息等。所述业务信息在服务器中可以与业务对象的标识进行关联存储。同时，在服务器中，各个用户的账号也可以与业务对象的标识相关联。这样，当服务器需要向用户提供业务信息时，可以将业务对象的业务信息提供给具备所述业务对象的标识的用户。
在本申请一个实施方式中，所述行程数据可以用于表明用户的出行计划。所述出行计划中通常会包括出发地点、目标地点或者中转地点中的至少一个。因此，所述属性信息可以包含地理位置信息。所述地理位置信息可以包括目的地信息、中转站信息、起始地信息中的至少一种。所述地理位置信息可以是地理位置的实际名称，也可以是用于表征地理位置的编码。例如，用户的行程数据中包含目的地为三亚的数据，那么所述地理位置信息可以是“三亚”，也可以是用于表征三亚的地理位置编码“sy”。
由以上本申请实施方式提供的技术方案可见，本申请实施方式通过对用户的行程数据进行分析，从而可以为各个用户设定相适配的标签。针对指定的业务对象，其可以预先设置用于限定用户群体的聚合规则。针对行程数据中具备相同地理位置信息的目标用户群，可以通过该聚合规则以及用户的标签，进一步地将目标用户群中的用户聚合至业务对象的用户集合中，从而可以向用户集合中的用户提供业务对象的业务信息。本申请公开的业务信息的提供、接收、用户聚合方法、服务器及客户端，不仅仅对用户的订单数据进行分析，而是对能够对用户的行程数据进行分析，从而扩大了参考的用户群体，进而提高了业务信息的推广效率。
在20世纪90年代，对于一个技术的改进可以很明显地区分是硬件上的改进(例如，对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件(programmablelogicdevice,pld)(例如现场可编程门阵列(fieldprogrammablegatearray，fpga))就是这样一种集成电路，其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片pld上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片2。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器(logiccompiler)”软件来实现，它与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代码也得用特定的编程语言来撰写，此称之为硬件描述语言(hardwaredescriptionlanguage，hdl)，而hdl也并非仅有一种，而是有许多种，如abel(advancedbooleanexpressionlanguage)、ahdl(alterahardwaredescriptionlanguage)、confluence、cupl(cornelluniversityprogramminglanguage)、hdcal、jhdl(javahardwaredescriptionlanguage)、lava、lola、myhdl、palasm、rhdl(rubyhardwaredescriptionlanguage)等，目前最普遍使用的是vhdl(very-high-speedintegratedcircuithardwaredescriptionlanguage)与verilog2。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中，就可以很容易得到实现该逻辑方法流程的硬件电路。
本领域技术人员也知道，除了以纯计算机可读程序代码方式实现服务器以外，完全可以通过将方法步骤进行逻辑编程来使得服务器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种服务器可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。
通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如rom/ram、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施方式或者实施方式的某些部分所述的方法。
本说明书中的各个实施方式均采用递进的方式描述，各个实施方式之间相同相似的部分互相参见即可，每个实施方式重点说明的都是与其他实施方式的不同之处。尤其，针对服务器和客户端的实施方式来说，均可以参照前述方法的实施方式的介绍对照解释。
本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。
虽然通过实施方式描绘了本申请，本领域普通技术人员知道，本申请有许多变形和变化而不脱离本申请的精神，希望所附的权利要求包括这些变形和变化而不脱离本申请的精神。