CN110765367A - 信息推送方法、装置、电子设备及计算机存储设备 - Google Patents

Abstract

本申请实施例提供了一种信息推送方法，其中，该方法包括：根据用户的历史出行数据或日历行程数据，确定所述用户需要到达的目的地信息；根据所述用户需要到达的目的地信息和所述用户的出发地信息，确定为所述用户提供的出行服务信息；所述出行服务信息中包括所述目的地信息和服务车辆类型；向所述用户的客户端推送所述出行服务信息。本申请实施例提供的信息推送方法，可以为用户推送出行服务信息，提高用户打车的效率。本申请实施例还提供了一种信息推送装置、电子设备及计算机存储介质。

Description

信息推送方法、装置、电子设备及计算机存储设备

技术领域

本申请涉及计算机网络技术领域，尤其是涉及一种信息推送方法、装置、电子设备及计算机存储设备。

背景技术

随着交通工具的普及，使用打车软件打车越来越受到大众的青睐。打车软件是一种智能手机应用，乘客可以通过打车软件提交订单，司机可以通过乘客提交的订单，根据乘客设置的位置接送乘客，大大提高了打车效率，节约司机与乘客沟通成本，降低空驶率，最大化节省司乘双方资源与时间。因此，打车软件逐渐得到普及。

目前，打车软件可以通过乘客的输入获取订单的内容，再将获取的订单的内容发布给司机。但是，当前的打车软件仅可以按照乘客输入的信息确定订单的内容，乘客需要手动输入乘车位置及目的地，这种方式不够便捷。

发明内容

有鉴于此，本申请实施例的目的在于提供一种信息推送方法、装置、电子设备及计算机存储介质，以为用户推送出行服务信息，提高用户打车的效率。

第一方面，本申请实施例提供了一种信息推送方法，所述方法包括：

根据用户的历史出行数据或日历行程数据，确定所述用户需要到达的目的地信息；

根据所述用户需要到达的目的地信息和所述用户的出发地信息，确定为所述用户提供的出行服务信息；所述出行服务信息中包括所述目的地信息和服务车辆类型；

向所述用户的客户端推送所述出行服务信息。

结合第一方面，本申请实施例提供了第一方面的第一种可能的实施方式，其中，

根据以下步骤确定推送的服务车辆类型：

基于与所述用户的出发地距离预设范围的不同服务车辆类型的应答率和所述用户的历史偏好车辆类型，确定为所述用户推送的服务车辆类型。

结合第一方面的第一种可能的实施方式，本申请实施例提供了第一方面的第二种可能的实施方式，其中，

基于与所述用户的出发地距离预设范围的不同服务车辆类型的应答率和所述用户的历史偏好车辆类型，确定为所述用户推送的服务车辆类型，包括：

判断所述用户的历史偏好车辆类型的应答率是否大于设定阈值；

若是，则将所述用户的历史偏好车辆类型确定为向所述用户推送的服务车辆类型；若不是，则选择应答率最高的服务车辆类型作为向所述用户推送的服务车辆类型。

结合第一方面，本申请实施例提供了第一方面的第三种可能的实施方式，其中，

所述出行服务信息还包括以下信息中的一种或多种：

预估价格；预计到达时间；建议出行时间；出行距离；天气信息；路况信息。

结合第一方面的第三种可能实施方式，本申请实施例提供了第一方面的第四种可能的实施方式，其中，

若所述出行服务信息包括建议出行时间，根据以下步骤确定所述建议出行时间：

根据所述用户的历史出行数据或日历行程数据，确定所述用户到达目的地的规定时间；

根据所述用户需要到达的目的地信息和出发地信息、出行时的拥堵情况和天气情况、以及所述用户到达目的地的规定时间，确定所述建议出行时间。

结合第一方面的第四种可能的实施方式，本申请实施例提供了第一方面的第五种可能的实施方式，其中，

向所述用户的客户端推送所述出行服务信息，包括：

根据所述建议出行时间，向所述用户的客户端推送所述出行服务信息。

结合第一方面，本申请实施例提供了第一方面的第六种可能的实施方式，向所述用户的客户端推送所述出行服务信息之前，还包括：

确定所述客户端符合预设的推送条件。

结合第一方面的第六种可能的实施方式，本申请实施例提供了第一方面的第七种可能的实施方式，所述推送条件包括以下条件中的一种或多种：

客户端版本在设定版本级别以上；在最近设定时长内针对所述客户端的推送频次低于设定阈值；所述客户端为非企业支付客户端；与所述用户的出发地距离预设范围内存在应答率大于设定阈值的服务车辆类型；客户端的服务界面为预设服务车辆类型的服务界面。

结合第一方面，本申请实施例提供了第一方面的第八种可能的实施方式，根据用户的历史出行数据，确定所述用户需要到达的目的地信息之前，还包括：

通过将所述用户的历史出行订单中的各个出行地址进行聚类，得到所述用户的家庭住址和办公地址；以及，通过将所述用户的历史出行订单中的各个出行时间进行聚类，得到所述用户的上班时间和下班时间，或者根据所述用户的历史出行订单中记录的所述用户打车去往所述办公地址的时间确定所述上班时间，根据所述用户打车去往所述家庭地址的时间确定所述下班时间；

所述根据用户的历史出行数据，确定所述用户需要到达的目的地信息，包括：

根据用户当前所在位置和当前时间信息，以及聚类得到的所述的家庭住址和办公地址、上班时间和下班时间，确定所述用户需要到达的目的地信息。

结合第一方面，本申请实施例提供了第一方面的第九种可能的实施方式，向所述用户的客户端推送所述出行服务信息，包括：

向所述用户的客户端推送携带有所述出行服务信息的通知栏消息，所述通知栏消息用于在所述客户端的通知栏中进行展示。

结合第一方面，本申请实施例提供了第一方面的第十种可能的实施方式，向所述用户的客户端推送所述出行服务信息，包括：

向所述用户的客户端推送携带有所述出行服务信息的发单页面信息，所述发单页面信息用于在所述客户端的发单页面中展示所述出行服务信息。

结合第一方面，本申请实施例提供了第一方面的第十一种可能的实施方式，其中，

根据用户的日历行程数据，确定所述用户需要到达的目的地信息之前，还包括：

获取所述用户的日历行程读取权限。

结合第一方面的第十一种可能的实施方式，本申请实施例提供了第一方面的第十二种可能的实施方式，其中，

获取所述用户的日历行程读取权限之后，还包括：

向所述用户的客户端推送权限修改提醒信息，用于提醒用户能够在设置功能中修改平台的日历行程读取权限。

结合第一方面的第十一种可能的实施方式，本申请实施例提供了第一方面的第十三种可能的实施方式，其中，

获取所述用户的日历行程读取权限，包括：

在所述用户的客户端首次注册时，向所述客户端发送日历行程读取权限请求；或者，

在平台未具有用户的日历行程读取权限的情况下，周期性向所述客户端发送日历行程读取权限请求；或者，

接收所述客户端发送的用户主动设置由平台享有日历行程读取权限的通知消息。

结合第一方面，本申请实施例提供了第一方面的第十四种可能的实施方式，其中，

所述日历行程数据包括以下信息中的一种或多种：

会议安排的时间和地点；

航班对应的出发时间、出发地和目的地；

火车班次对应的出发时间、出发地和目的地。

第二方面，本申请实施例还提供一种信息推送装置，包括：第一确定模块、第二确定模块和推送模块；其中，

所述第一确定模块，用于根据用户的历史出行数据或日历行程数据，确定所述用户需要到达的目的地信息；

所述第二确定模块，用于根据所述用户需要到达的目的地信息和所述用户的出发地信息，确定为所述用户提供的出行服务信息；所述出行服务信息中包括所述目的地信息和服务车辆类型；

所述推送模块，所述向所述用户的客户端推送所述出行服务信息。

结合第二方面，本申请实施例提供了第二方面的第一种可能的实施方式，其中，

所述第二确定模块具体用于根据以下步骤确定推送的服务车辆类型：

基于与所述用户的出发地距离预设范围的不同服务车辆类型的应答率和所述用户的历史偏好车辆类型，确定为所述用户推送的服务车辆类型。

结合第二方面的第一种可能的实施方式，本申请实施例提供了第二方面的第二种可能的实施方式，其中，

所述第一确定模块，具体用于根据以下步骤确定为所述用户推送的服务车辆类型：

判断所述用户的历史偏好车辆类型的应答率是否大于设定阈值；

若是，则将所述用户的历史偏好车辆类型确定为向所述用户推送的服务车辆类型；若不是，则选择应答率最高的服务车辆类型作为向所述用户推送的服务车辆类型。

结合第二方面，本申请实施例提供了第二方面的第三种可能的实施方式，其中，

所述出行服务信息还包括以下信息中的一种或多种：

预估价格；预计到达时间；建议出行时间；出行距离；天气信息；路况信息。

结合第二方面的第三种可能实施方式，本申请实施例提供了第二方面的第四种可能的实施方式，其中，

所述第二确定模块，具体用于根据以下步骤确定所述建议出行时间：

根据所述用户的历史出行数据或日历行程数据，确定所述用户到达目的地的规定时间；

根据所述用户需要到达的目的地信息和出发地信息、出行时的拥堵情况和天气情况、以及所述用户到达目的地的规定时间，确定所述建议出行时间。

结合第二方面的第四种可能的实施方式，本申请实施例提供了第二方面的第五种可能的实施方式，其中，

所述推送模块，具体用于根据以下步骤向所述用户的客户端推送所述出行服务信息：

根据所述建议出行时间，向所述用户的客户端推送所述出行服务信息。

结合第二方面，本申请实施例提供了第二方面的第六种可能的实施方式，其中，

所述第二确定模块，还用于确定所述客户端符合预设的推送条件。

结合第二方面的第六种可能的实施方式，本申请实施例提供了第二方面的第七种可能的实施方式，其中，

所述推送条件包括以下条件中的一种或多种：

客户端版本在设定版本级别以上；在最近设定时长内针对所述客户端的推送频次低于设定阈值；所述客户端为非企业支付客户端；与所述用户的出发地距离预设范围内存在应答率大于设定阈值的服务车辆类型；客户端的服务界面为预设服务车辆类型的服务界面。

结合第二方面，本申请实施例提供了第二方面的第八种可能的实施方式，其中，所述装置还包括：

聚类模块，用于通过将所述用户的历史出行订单中的各个出行地址进行聚类，得到所述用户的家庭住址和办公地址；以及，通过将所述用户的历史出行订单中的各个出行时间进行聚类，得到所述用户的上班时间和下班时间，或者根据所述用户的历史出行订单中记录的所述用户打车去往所述办公地址的时间确定所述上班时间，根据所述用户打车去往所述家庭地址的时间确定所述下班时间；

所述第一确定模块，具体用于根据以下步骤确定所述用户需要到达的目的地信息：

根据用户当前所在位置和当前时间信息，以及聚类得到的所述的家庭住址和办公地址、上班时间和下班时间，确定所述用户需要到达的目的地信息。

结合第二方面，本申请实施例提供了第二方面的第九种可能的实施方式，其中，

所述推送模块，具体用于根据以下步骤向所述用户的客户端推送所述出行服务信息：

向所述用户的客户端推送携带有所述出行服务信息的通知栏消息，所述通知栏消息用于在所述客户端的通知栏中进行展示。

结合第二方面，本申请实施例提供了第二方面的第十种可能的实施方式，其中，

所述推送模块，具体用于根据以下步骤向所述用户的客户端推送所述出行服务信息：

向所述用户的客户端推送携带有所述出行服务信息的发单页面信息，所述发单页面信息用于在所述客户端的发单页面中展示所述出行服务信息。

结合第二方面，本申请实施例提供了第二方面的第十一种可能的实施方式，其中，

所述装置还包括：

获取模块，用于获取所述用户的日历行程读取权限。

结合第二方面的第十一种可能的实施方式，本申请实施例提供了第二方面的第十二种可能的实施方式，其中，

所述推送模块，还用于向所述用户的客户端推送权限修改提醒信息，用于提醒用户能够在设置功能中修改平台的日历行程读取权限。

结合第二方面的第十一种可能的实施方式，本申请实施例提供了第二方面的第十三种可能的实施方式，其中，

所述获取模块，具体用于根据以下步骤获取所述用户的日历行程读取权限：

在所述用户的客户端首次注册时，向所述客户端发送日历行程读取权限请求；或者，

在平台未具有用户的日历行程读取权限的情况下，周期性向所述客户端发送日历行程读取权限请求；或者，

接收所述客户端发送的用户主动设置由平台享有日历行程读取权限的通知消息。

结合第二方面，本申请实施例提供了第二方面的第十四种可能的实施方式，其中，

所述日历行程数据包括以下信息中的一种或多种：

会议安排的时间和地点；

航班对应的出发时间、出发地和目的地；

火车班次对应的出发时间、出发地和目的地。

第三方面，本申请实施例还提供一种电子设备，包括：处理器、存储器和总线，所述存储器存储有所述处理器可执行的机器可读指令，当电子设备运行时，所述处理器与所述存储器之间通过总线通信，所述机器可读指令被所述处理器执行时执行上述任一种可能的实施方式中的步骤。

第四方面，本申请实施例还提供一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行上述任一种可能的实施方式中的步骤。

本申请实施例提供的信息推送方法、装置、电子设备及计算机存储介质，可以根据用户的历史出行数据或日历行程数据，确定用户需要到达的目的地信息，并根据用户需要到达的目的地信息和用户的出发地信息，确定为用户提供包括目的地信息和服务车辆类型的出行服务信息，从而可以向用户的客户端推送确定的出行服务信息。这样，可以直接根据用户的历史出行数据或日历行程数据，为用户推送出行服务信息，无需用户手动操作即可以向用户推送目的地信息及服务车辆类型，从而可以提高用户打车的效率，节省用户订单输入的时间，为用户打车提供便利。

为使本申请的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1示出了本申请实施例一所提供的一种信息推送的流程图；

图2示出了本申请实施例一所提供的客户端在通知栏展示通知栏消息的界面图；

图3示出了本申请实施例二所提供的向用户的客户端推送出行服务信息过程的示意图；

图4示出了本申请实施例四所提供的为用户提供出行服务信息过程的示意图；

图5示出了本申请实施例五所提供的基于用户的日历行程数据为用户提供出行服务信息过程的示意图；

图6示出了本申请实施例五所提供的客户端向用户提示获取日历权限的服务界面的示意图；

图7示出了本申请实施例五所提供的客户端向用户展示日历行程读取成功的服务界面的示意图；

图8示出了本申请实施例五所提供的客户端向用户展示日历行程读取成功的服务界面的示意图；

图9示出了本申请实施例五所提供的客户端的发单页面为用户展示出行服务信息的界面图；

图10示出了本申请实施例六所提供的一种信息推送的流程图；

图11示出了本申请实施例七所提供的一种信息推送方法的流程图；

图12示出了本申请实施例八所提供的一种信息推送装置的示意图；

图13示出了本申请实施例九所提供的一种电子设备的结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。

本申请实施例下述方法、装置、电子设备或计算机存储介质可以应用于任何需要对出行信息进行推荐的场景，比如，可以应用于打车软件、出行消息提醒等。本申请实施例并不对具体的应用场景作限制，任何使用本申请实施例提供的方法对信息推送的方案均在本申请保护范围内。

本申请实施例中，可以根据用户的历史出行数据或日历行程数据，确定用户需要到达的目的地信息，这里无需用户手动输入即可以为用户确定需要到达的目的地，进一步，可以根据确定的目的地信息以及用户的出发地信息，确定为用户提供的服务车辆类型等出行服务信息，并将出行服务信息推送给用户的客户端，这样，用户可以直接根据推送的出行服务信息一键发单，进而节省用户打车的时间，提高用户打车的效率，为用户提供便利，增强用户体验。下述实施例将会对信息推送过程作详细说明。

实施例一

如图1所示，本申请实施例一提供的一种出行信息推荐的方法，包括：

S101：根据用户的历史出行数据或日历行程数据，确定所述用户需要到达的目的地信息。

这里，可以在用户的历史出行订单中获取预设历史时间段内用户的历史出行数据，或者，可以查询用户的日历行程，在日历行程中获取用户的日历行程数据。其中的历史出行数据可以包括出行的出发地信息和目的地信息、出行时间和到达时间、出行时的拥堵情况、出行时的天气情况中的一种或多种，其中的日历行程数据可以包括会议安排的时间和地点、航班对应的出发时间、出发地和目的地、火车班次对应的出发时间、出发地和目的地中的一种或多种。

在具体实施中，软件平台(比如打车软件平台)检查用户是否设置有日历行程，如果设置有日历行程，则可以在日历行程中提取日历行程数据，并根据日历行程数据确定用户需要到达的目的地信息。或者，软件平台可以针对预设历史时间段内每一个历史出行订单中的目的地信息，通过对历史出行订单中的各个出行地址进行聚类的方式，确定用户需要到达的目的地信息。具体如，软件平台可以检查用户是否设置有常用目的地，如果设置有常用目的地，则可以将设置的常用目的地确定为用户需要到达的目的地信息；如果用户没有设置的常用目的地，则可以获取过去3个月内工作日的历史出行订单，统计获取的历史出行订单中各个出行地址及出行时间，根据用户当前所在位置和当前时间，以及历史出行订单中各个出行地址及出行时间，确定用户需要到达的目的地信息。

S102：根据所述用户需要到达的目的地信息和所述用户的出发地信息，确定为所述用户提供的出行服务信息；所述出行服务信息中包括所述目的地信息和服务车辆类型。

在具体实施中，在确定用户需要到达的目的地信息之后，可以根据用户需要到达的目的地信息和用户的出发地信息，确定为用户提供的出行服务信息，进而可以向用户推送确定的出行服务信息，不仅可以提醒用户马上启动的出行行程，还可以通过出行服务信息进行一键发单，为用户提供便利。

上述出行服务信息中包括目的地信息和服务车辆类型。在确定服务车辆类型时，可以基于与用户的出发地距离预设范围的不同服务车辆类型的应答率和用户的历史偏好车辆类型，确定为用户推送的服务车辆类型。在确定不同服务车辆类型的应答率时，打车软件可以获取预设历史应答时间内与用户的出发地距离预设范围的、不同服务车辆类型分别对应的乘客发单数量，并统计在该预设历史应答时间内不同服务车辆类型对应的司机接单数量，根据统计的每种服务车辆类型对应的乘客发单数量和司机接单数量，确定不同服务车辆类型的应答率，这里的不同服务车辆类型的应答率即为服务车辆类型对应的司机接单数量与乘客发单数量的比值。例如，如果过去5分钟距离清华大学10公里范围内乘客发起快车订单的数量为100单，快车司机接单数量为80单，则快车的应答率为80％。上述用户的历史偏好车辆类型可以根据用户的历史出行订单进行确定，例如，可以将历史出行订单中最常用的车辆类型确定为历史偏好车辆类型。

在具体实施中，在确定为用户推送的服务车辆类型时，可以先获取用户的历史偏好车辆类型的应答率，进而可以判断用户的历史偏好车辆类型的应答率是否大于设定阈值，若是，则将该用户的历史偏好车辆类型确定为向用户推送的服务车辆类型；若不是，则选择应答率最高的服务车辆类型作为向用户推送的服务车辆类型。通过这种方式，可以使用户及时乘坐合适的车辆类型到达目的地。

上述出行服务信息，还可以包括以下信息中的一种或多种：预估价格；预计到达时间；建议出行时间；出行距离；天气信息；路况信息。进而软件平台可以将预估价格、预计到达时间、建议出行时间、出行距离、天气信息、路况信息中的一种或多种与目的地信息及服务车辆类型一同推送给用户的客户端。

S103：向所述用户的客户端推送所述出行服务信息。

这里，在向用户的客户端推送出行服务信息时，可以向用户的客户端推送携带有所述出行服务信息的通知栏消息，所述通知栏消息用于在客户端的通知栏中进行展示，从而用户可以在客户端的通知栏处对出行服务信息进行查看。这里的通知栏是指客户端对应的终端设备的桌面上显示的通知消息栏，开启锁屏通知后，用户在锁屏状态下也可以接收到该出行服务信息。通知栏消息还可以与打车软件关联，例如，通知栏消息中携带有界面跳转指令或一键下单指令，当用户点击通知栏消息的预设消息位置时，可以触发该界面跳转指令或一键下单指令，从而客户端可以跳转到出行订单确认界面对相应的出行订单进行确认，或者，直接根据出行服务信息提交出行订单，从而用户不需要手动输入目的地址以及选择偏好车辆类型，就可以一键发单，节省用户提交出行订单的时间，提高用户打车的效率。

客户端在通知栏展示通知栏消息的界面如图2所示，假设软件平台根据用户的历史出行数据或日历行程数据，确定用户需要到达的目的地信息为“未名视通”对应的位置，则客户端可以根据软件平台推送的出行服务信息，在通知栏处显示如下通知栏消息“今日路况良好，当前呼叫快车去[未名视通]，预计20分钟内到达”。这样，用户可以根据客户端推送的通知栏消息触发客户端提交到达[未名视通]的出行订单。

采用上述信息推送方法，一方面，避免了用户在打车时需要手动输入出行订单信息，不够便捷的问题，通过对用户的历史出行数据或日历行程数据的提取，确定为用户提供的出行服务信息，从而可以向用户推送包括目的地和服务车辆类型的出行服务信息，用户可以一键发单；另一方面，可以对用户即将到来的出行行程进行预测和提醒，提升用户体验。

实施例二

在上述实施例一的S102中，根据用户需要到达的目的地信息和所述用户的出发地信息，可以确定为用户提供的出行服务信息。进一步地，这里的出行服务信息，还包括以下信息中的一种或多种：预估价格；预计到达时间；建议出行时间；出行距离；天气信息；路况信息。

有鉴于此，如图3所示，本申请实施例二提供了根据建议出行时间向用户的客户端推送出行服务信息的过程，包括：

S301：根据所述用户的历史出行数据或日历行程数据，确定所述用户到达目的地的规定时间。

在具体实施中，软件平台可以通过对历史出行订单中的各个出行地址进行聚类得到目的地信息以及用户到达目的地的规定时间。例如，规定时间可以为用户平时上下班出行对应的时间。需要说明的是，这里对历史出行订单中的各个出行地址进行聚类，也即基于出行地址将各个历史出行订单进行聚类，最终聚类后的得到两类出行地址，每类出行地址对应的历史出行订单的数量大于设定阈值；一类对应办公地址，规定时间即为上班时间，一类对应家庭住址，规定时间即为下班时间。

软件平台还可以通过日历行程数据确定用户到达目的地的规定时间，这时，软件平台可以在日历行程数据中提取用户到达目的地的规定时间。例如，日历行程数据中记录用户需要在10:00去[未名视通]开会，则软件平台可以将10:00确定为用户达目的地[未名视通]的规定时间。

S302：根据所述用户需要到达的目的地信息和出发地信息、出行时的拥堵情况和天气情况、以及所述用户到达目的地的规定时间，确定所述建议出行时间。

在具体实施中，在确定用户到达目的地的规定时间之后，可以根据用户需要到达的目的地信息和出发地信息，出行时的拥堵情况和天气情况、以及所述用户到达目的地的规定时间，确定向用户推荐的建议出行时间。这里，建议出行时间为建议用户出行的时间。具体如，可以根据用户达到的目的地信息和出发地信息，为用户规划由出发地到达目的地的至少一条出行路线，并根据出行时至少一条出行路线的拥堵情况和天气情况，在至少一条出行路线中选择一条出行路线，并确定选择的出行路线对应的耗时，再根据确定的耗时以及用户到达目的地的规定时间，确定建议出行时间。

例如，根据历史出行数据，统计得到用户平时上班时间为9点，路上耗时1小时，用户最晚8点出发，则默认提前10分钟(7点50)提醒用户呼叫快车，这里的7点50可以为建议出行时间。如果出行时的道路处于拥堵状态，或者，出行时为下雨天，则可以提前30分钟(7点半)提醒用户呼叫快车，这样可以预防用户在到达目的地的路上花费的时间比计划时间长，或者呼叫快车时需要等待的情况，进而可以将建议出行时间确定为7点半。

S303：根据所述建议出行时间，向所述用户的客户端推送所述出行服务信息。

在具体实施中，在确定用户的建议出行时间之后，可以在建议出行时间向用户的客户端推送出行服务信息；还可以在建议出行时间之前的预设出行提醒时间，向用户的客户端推送出行服务信息。这里，预设出行提醒时间可以根据出行时的拥堵情况和天气情况进行设置，例如，若出行时的道路处于严重拥堵状态，或者，出行时的天气为暴雨、大雪等恶劣天气情况，则可以将比最晚出行时间(基于规定时间和出行路线的耗时确定)提前n分钟的时间作为建议出行时间，并在比建议出行时间提前m分钟的时间向用户的客户端推送出行服务信息，以便用户提前对出行时的交通状况或天气状况做好准备工作。例如，用户需要到B地10：00开会，预估由用户的出发地A至目的地B需要30分钟的车程，最晚出行时间为9:30，如果道路畅通，建议出行时间默认提前10分钟，为9:20，则可以在9：15提醒乘客在9：20前打车，如道路拥堵或天气恶劣，建议出行时间默认提前30分钟，为9:00，则可以在8：55提醒乘客在9：00前打车。

本申请实施例二提供的根据建议出行时间向用户的客户端推送出行服务信息的过程，可以根据出行时道路的拥堵情况和天气情况，为用户确定建议出行时间，从而可以在建议出行时间或建议出行时间之前向用户的客户端推送出行服务信息，使用户可以提前做好准备，并确保用户可以按时到达目的地，为用户的出行带来便利。

实施例三

在上述实施例一的S103之前，即在向所述用户的客户端推送所述出行服务信息之前，还可以确定客户端符合预设的推送条件。

这里的推送条件包括以下条件中的一种或多种：

客户端版本在设定版本级别以上；在最近设定时长内针对所述客户端的推送频次低于设定阈值；所述客户端为非企业支付客户端；与所述用户的出发地距离预设范围内存在应答率大于设定阈值的服务车辆类型；客户端的服务界面为预设服务车辆类型的服务界面。

在具体实施中，软件平台在向用户的客户端推送出行服务信息之前，可以检测客户端是否符合上述推送条件，例如，客户端版本为最新客户端版本，或者，针对该客户端在当天出行服务信息的推送频次低于1次，或者，客户端为非企业支付客户端，或者，与用户的出发地距离预设范围内存在应答率大于50％的服务车辆类型，或者，客户端的服务界面切换到快车服务车辆类型的服务界面(比如本平台只针对快车和优享进行出行服务信息推送)，如果用户的客户端符合上述推送条件，则可以为符合预设的推送条件的客户端推送出行服务信息。

通过确定客户端是否符合预设的推送条件，可以对不符合预设的推送条件的客户端进行过滤，从而可以针对符合预设的推送条件客户端推送出行服务信息，这样可以针对有需求的用户推送出行服务信息，提高用户体验。

实施例四

在上述实施例一中可以通过用户的历史出行数据或日历行程数据为用户提供出行服务信息，如图4所示，下面以实施例四对基于用户的历史出行数据为用户提供出行服务信息的过程进行说明，包括：

S401，获取预设历史时间段内用户的历史出行数据。

在具体实施中，软件平台获取预设历史时间段内用户的历史出行订单，并在历史出行订单中提取用户的历史出行数据。在一些实施方式中，软件平台还可以检查用户是否设置有常用目的地或常用服务车辆类型，如果存在用户设置的常用目的地或常用服务车辆类型，则可以将常用目的地或常用服务车辆类型作为候选的目的地信息和服务车辆类型。

S402，通过将所述用户的历史出行订单中的各个出行地址进行聚类，得到所述用户的家庭住址和办公地址。

在具体实施中，软件平台可以根据用户的历史出行数据，对预设历史时间段内用户的历史出行订单中的各个出行地址进行聚类，得到用户的家庭住址和办公地址，并且可以通过将用户的历史出行订单中的各个出行时间进行聚类，得到所述用户的上班时间和下班时间，或者，可以根据用户的历史出行订单中记录的用户打车去往办公地址的时间确定上班时间，根据用户打车去往所述家庭地址的时间确定下班时间。这里，在对用户的历史出行订单中的各个出行时间进行聚类时，可以与各个出行地址进行关联，从而可以确定与各个出行地址对应的出行时间。例如，可以将在工作日第一时间段聚类得到的目的地作为办公地址，将工作日第二时间段聚类得到的目的地作为家庭住址，其中第一时间段对应上午或白天，第二时间段对应下午或晚上。

S403，根据用户当前所在位置和当前时间信息，以及聚类得到的所述的家庭住址和办公地址、上班时间和下班时间，确定所述用户需要到达的目的地信息。

这里，可以获取用户当前所在位置和当前时间信息，并将用户当前所在位置和当前时间信息与聚类得到的家庭住址和办公地址、上班时间和下班时间进行对比，若用户当前所在位置和当前时间信息与聚类得到的家庭住址和办公地址、上班时间和下班时间相匹配，则可以根据聚类得到的所述的家庭住址和办公地址、上班时间和下班时间，确定用户需要的出行，如上班或下班，则可以根据聚类得到的家庭住址和办公地址、上班时间和下班时间，为用户确定需要到达的目的地信息。若用户当前所在位置和当前时间信息与聚类得到的家庭住址和办公地址、上班时间和下班时间不匹配，则可以根据用户当前所在位置和当前时间信息，为用户确定需要到达的目的地信息，例如，若用户当前时间信息在聚类得到的上班时间或下班时间之前，则将聚类得到的家庭住址或办公地址确定为需要到达的目的地信息。

S404，根据用户需要到达的目的地信息和用户的出发地信息，确定为所述用户提供的出行服务信息，其中的出行服务信息中包括目的地信息和服务车辆类型。

在具体实施中，在确定用户需要到达的目的地信息之后，可以根据用户需要到达的目的地信息和用户的出发地信息，确定为用户提供的出行服务信息。在确定为用户提供的出行服务信息时，可以基于与用户的出发地距离预设范围的不同服务车辆类型的应答率和用户的历史偏好车辆类型，确定为用户推送的服务车辆类型，并根据目的地信息和服务车辆类型生成出行服务信息。

S405，向用户的客户端推送出行服务信息。

在具体实施中，在向用户的客户端推送出行服务信息时，可以向用户的客户端推送携带有所述出行服务信息的通知栏消息，所述通知栏消息用于在客户端的通知栏中进行展示，从而用户可以在客户端的通知栏处对出行服务信息进行查看。进一步地，可以为这种出行服务信息推送的方式设置出行服务信息的推送频次，若所述推送频次大于设定阈值，则不向所述用户的客户端发送出行服务信息。例如，可以将推送频次设置为每天一次；再例如，若历史累计连续预设条数的出行服务信息用户均未接受，则在未来预设时间段内不再向该用户的客户端推荐出行服务信息。

在一些实施方式中，在向用户的客户端推送出行服务信息时，还可以向用户的客户端推送携带有出行服务信息的发单页面信息，该发单页面信息用于在客户端的发单页面中展示出行服务信息。这种出行服务信息推送的方式可以在用户打开客户端的情况下，通过在客户端的发单页面为用户展示出行服务信息，从而用户可以通过点击出行服务信息的操作进行一键发单。这里，在用户打开客户端的情况下为用户推送出行服务信息的方式，可以不对推送频次进行限制。

通过上述实施例四，可以利用聚类得到用户的家庭住址、办公地址以及用户的上班时间、下班时间，并可以根据用户的家庭住址、办公地址以及用户的上班时间、下班时间确定用户需要到达的目的地信息，从而可以针对用户上班或下班的出行为用户推送出行服务信息，提高用户体验。

实施例五

在上述实施例一中可以通过用户的历史出行数据或日历行程数据，为用户提供出行服务信息，如图5所示，本申请实施例五对基于用户的日历行程数据为用户提供出行服务信息的过程进行说明，包括：

S501：判断用户的日历行程读取权限是否为允许读取状态。

在具体实施中，软件平台在获取用户的日历行程数据之前，可以判断用户的日历行程读取权限是否为允许读取状态。

S502：若用户的日历行程读取权限未不允许读取状态，则获取所述用户的日历行程读取权限，并向所述用户的客户端推送权限修改提醒信息，用于提醒用户能够在设置功能中修改平台的日历行程读取权限。

在具体实施中，软件平台可以通过以下任一方式获取用户的日历行程读取权限：在用户的客户端首次注册时，向客户端发送日历行程读取权限请求，以获取日历行程读取权限；在平台未具有用户的日历行程读取权限的情况下，周期性向所述客户端发送日历行程读取权限请求；接收所述客户端发送的用户主动设置由平台享有日历行程读取权限的通知消息。这里，在平台未具有用户的日历行程读取权限的情况下，可以周期性向客户端发送日历行程读取权限请求，例如，软件平台按照一定的时间间隔向客户端发送日历行程读取权限请求，以获取日历行程读取权限，一旦获取日历行程读取权限，则不再发送日历行程读取权限请求，如果连续N次用户未同意，则可以停止发送日历行程读取权限请求，其中，N为正整数。软件平台还可以通过接收客户端发送的用户主动设置由平台享有日历行程读取权限的通知消息，获取日历行程读取权限，用户可以通过客户端的“设置功能”主动设置由平台享有日历行程读取权限。

软件平台向客户端发送日历行程读取权限请求，客户端的服务界面如图6所示，客户端的服务界面可以显示“想要获取您的日历权限”，用户可以通过客户端显示的“不允许”或“允许”功能对日历行程读取权限进行设置。

S503：读取日历行程数据，并根据用户的日历行程数据，确定所述用户需要到达的目的地信息及用户到达目的地的规定时间。

软件平台成功读取日历行程数据，客户端的服务界面的两种显示方式如图7和图8所示。在图7中的服务界面下方，客户端的服务界面为用户显示“开启日历行程”的服务消息，并提示用户通过获取日历权限，可以为用户推荐接下来的行程的出行服务信息。在图8中的服务界面下方，客户端的服务界面为用户显示“开启日历行程”的服务消息，并提示用户可以在“设置功能”中对读取日历行程的权限进行修改。

这里，日历行程数据可以包括以下信息中的一种或多种：会议安排的时间和地点；航班对应的出发时间、出发地和目的地；火车班次对应的出发时间、出发地和目的地。其中的会议安排地点可以为日历行程显示的地点，也可以为默认的地点，比如日历行程为部门会议，则默认的地点可以为办公地点。

S504：获取用户当前所在位置，为用户规划由当前所在位置达到用户需要到达的目的地的出行路线。

在具体实施中，可以根据用户达到的目的地信息和当前所在位置，为用户规划由当前所在位置到达目的地的至少一条出行路线，并在至少一条出行路线中选择一条出行路线作为出行时的出行线路。在选择一条出行路线作为出行时的出行线路，可以根据出行线路的交通状况、出行线路的路程或出行线路的耗时等因素，在至少一条出行路线中选择作为出行时的出行线路，如选择耗时最少的出行线路作为出行时的出行线路。

S505：根据出行时出行路线的拥堵情况、天气情况及用户到达目的地的规定时间，为用户确定建议出行时间。

在具体实施中，可以根据规划的出行线路的拥堵情况、天气情况及用户到达目的地的规定时间，为用户确定建议出行时间。例如，用户需要到B地10：00开会，预估由用户的出发地A至目的地B需要30分钟的时间，如果道路畅通则提醒乘客在9：20(建议出行时间)前打车，如道路拥堵或天气恶劣，则提醒乘客在9：00(建议出行时间)前打车。

S506：根据用户的历史出行数据，判断用户的历史偏好车辆类型的应答率是否大于设定阈值。

在具体实施中，可以在用户的历史出行订单中提取历史出行数据，并根据历史出行数据确定用户的历史偏好车辆类型，再获取出行时历史偏好车辆类型的应答率，并将历史偏好车辆类型的应答率与设定阈值进行比较，进而可以判断用户的历史偏好车辆类型的应答率是否大于设定阈值。

S507：若用户的历史偏好车辆类型的应答率大于设定阈值，则将用户的历史偏好车辆类型确定为向用户推送的服务车辆类型。

S508：若用户的历史偏好车辆类型的应答率小于或设定阈值，则选择应答率最高的服务车辆类型作为向用户推送的服务车辆类型。

S509：根据所述建议出行时间，向用户的客户端推送所述出行服务信息。

这里，所述出行服务信息包括以下信息中的一种或多种：预估价格；预计到达时间；建议出行时间；出行距离；天气信息；路况信息。

在具体实施中，在向用户的客户端推送出行服务信息时，可以向用户的客户端推送携带有所述出行服务信息的通知栏消息，所述通知栏消息用于在客户端的通知栏中进行展示，从而用户可以在客户端的通知栏处对出行服务信息进行查看。进一步地，可以为这种出行服务信息推送的方式设置出行服务信息的推送频次，若所述推送频次大于设定阈值，则不向所述用户的客户端发送出行服务信息。例如，可以将推送频次设置为每天一次；再例如，若历史累计连续预设条数的出行服务信息用户均未接受，则在未来预设时间段内不再向该用户的客户端推荐出行服务信息。例如，交通良好的情况下，向用户的客户端推送出行服务信息可以为：[日历行程]今日路况良好，您早上10：00去[未名视通]开会，建议在9：10前呼叫快车，可准时到达。再例如，交通拥堵的情况下，向用户的客户端推送出行服务信息为：[日历行程]今日道路拥堵，您早上10：00去[北京南站]乘坐高铁，建议在7：40前预约快车，以确保不误车。

在一些实施方式中，在向用户的客户端推送出行服务信息时，还可以向用户的客户端推送携带有出行服务信息的发单页面信息，该发单页面信息用于在客户端的发单页面中展示出行服务信息。这种出行服务信息推送的方式可以在用户打开客户端的情况下，通过在客户端的发单页面为用户展示出行服务信息，从而用户可以通过点击出行服务信息的操作进行一键发单。这里，在用户打开客户端的情况下为用户推送出行服务信息的方式，可以不对推送频次进行限制。例如，客户端的发单页面为用户展示出行服务信息如图9所示，在发单页面的目的地位置下方，可以展示出行服务信息：去[回龙观新村]优享约23.1元，预计21:17到达。

实施例六

如图10所示，本申请实施例六提供了一种信息推送方法，由客户端主动向软件平台的服务器发起出行信息推送请求，包括以下步骤：

S601：当用户打开客户端或者客户端的服务界面切换到快车服务界面时，客户端向软件平台的服务器发送出行信息推送请求，服务器根据出行信息推送请求获取用户的历史出行数据或日历行程数据。

S602：服务器判断所述客户端是否符合预设的推送条件，若符合，进入S603，否则结束操作。

这里，预设的推送条件可以包括以下一种或多种，客户端版本在设定版本级别以上；在最近设定时长内针对所述客户端的推送频次低于设定阈值；客户端的服务界面为预设服务车辆类型的服务界面；所述客户端为非企业支付客户端。例如，客户端版本在5.1.32以上，客户端的服务界面为预设服务车辆类型的服务界面，比如快车或优享服务界面。

S603：服务器根据历史出行数据确定用户需要到达的目的地信息。

这里，软件平台可以调用聚类服务模块的地址推荐接口获取用户需要到达的目的地信息。

S604：服务器获取出行信息推送请求中的服务车辆类型的应答率、服务车辆达到用户的出发地的时间、用户由出发地到达目的地的距离和时间、用户由出发地到达目的地的预估价格。

在具体实施中，出行信息推送请求中可以携带有用户默认的服务车辆类型，服务器可以并行确定该服务车辆类型的应答率、服务车辆达到用户的出发地的时间、由用户的出发地到达目的地的距离和时间、由用户的出发地到达目的地的预估价格。这里，如果用户的出发地距离预设范围内存在应答率小于或等于设定阈值的服务车辆类型，可以为用户选择应答率最高的服务车辆类型作为向所述用户推送的服务车辆类型。

S605，服务器根据服务车辆类型的应答率、服务车辆达到用户的出发地的时间、用户由出发地到达目的地的距离和时间、用户由出发地到达目的地的预估价格，向用户的客户端推送出行服务信息。

这里，出行服务信息中可以包括预估价格、预计到达时间、建议出行时间、出行距离、天气信息、路况信息中的一种或多种。这里，如果在S604获取的应答率小于设定阈值，可以考虑不用向客户端推送出行服务信息。

在具体实施中，软件平台的服务器在为用户提供出行服务信息时，可以调用预设接口对用户的客户端进行出行服务信息推荐。

实施例七

如图11所示，本申请实施例七提供了一种信息推送方法，由软件平台的服务器主动向客户端发送出行服务信息，包括以下步骤：

S701：服务器根据用户的历史出行数据或日历行程数据，确定用户需要到达的目的地信息和建议出行时间。

在具体实施中，软件平台可以周期性根据历史出行数据或日历行程数据，确定用户的家庭住址、办公地址及建议出行时间，并可以将确定的家庭住址、办公地址及建议出行时间等出行信息存储于目标文件中。

S702：服务器根据确定的目的地信息和建议出行时间，确定提供出行服务信息的客户端。

在具体实施中，可以在目标文件中存储的用户的建议出行时间，将建议出行时间为同一预设时间段内的用户的出行信息放在一个集合，并将该集合中的客户端确定为提供出行服务信息的客户端。

S703：服务器判断所述客户端是否符合预设的推送条件，若符合，进入S704，否则结束操作。

这里，预设的推送条件可以包括以下一种或多种，客户端版本在设定版本级别以上；在最近设定时长内针对所述客户端的推送频次低于设定阈值；客户端的服务界面为预设服务车辆类型的服务界面；与用户的出发地距离预设范围内存在应答率大于设定阈值的服务车辆类型、服务车辆的排队数量小于设定排队数量。例如，客户端版本在5.1.32以上，客户端的服务界面为预设服务车辆类型的服务界面为快车或优享服务界面。

S704：服务器获取服务车辆类型的应答率、用户由出发地到达目的地的距离和时间、服务车辆的排队情况。

在具体实施中，服务器可以并行确定服务车辆类型的应答率、用户由出发地到达目的地的距离和时间、服务车辆的排队情况。这里，如果用户的出发地距离预设范围内存在应答率小于或等于设定阈值的服务车辆类型，可以为用户选择应答率最高的服务车辆类型作为向所述用户推送的服务车辆类型。

S705：服务器根据获取服务车辆类型的应答率、用户由出发地到达目的地的距离和时间、服务车辆的排队情况，向用户的客户端推送出行服务信息。

这里，出行服务信息中可以包括预估价格、预计到达时间、建议出行时间、出行距离、天气信息、路况信息中的一种或多种。

采用上述信息推送方法，一方面，避免了用户在打车时需要手动输入出行订单信息不够便捷的问题，通过对用户的历史出行数据或日历行程数据的提取，确定为用户提供的出行服务信息，从而可以向用户推送出行服务信息，使用户可以根据选择进行一键发单；另一方面，可以对用户即将到来的出行行程进行预测和提醒，提升用户感受。

实施例八

如图12所示，本申请实施例八提供了一种信息推送装置80，包括第一确定模块81、第二确定模块82和推送模块83；其中，

所述第一确定模块81，用于根据用户的历史出行数据或日历行程数据，确定所述用户需要到达的目的地信息；

所述第二确定模块82，用于根据所述用户需要到达的目的地信息和所述用户的出发地信息，确定为所述用户提供的出行服务信息；所述出行服务信息中包括所述目的地信息和服务车辆类型；

所述推送模块83，所述向所述用户的客户端推送所述出行服务信息。

采用上述信息推送装置80，可以避免了用户在打车时需要手动输入出行订单信息不够便捷的问题，通过对用户的历史出行数据或日历行程数据的提取，确定为用户提供的出行服务信息，从而可以向用户推送出行服务信息，使用户可以根据选择进行一键发单；此外，还可以对用户即将到来的出行行程进行预测和提醒，提升用户感受。

在具体实施中，所述第二确定模块82，具体用于根据以下步骤确定推送的服务车辆类型：

基于与所述用户的出发地距离预设范围的不同服务车辆类型的应答率和所述用户的历史偏好车辆类型，确定为所述用户推送的服务车辆类型。

所述第一确定模块81，具体用于根据以下步骤确定为所述用户推送的服务车辆类型：

判断所述用户的历史偏好车辆类型的应答率是否大于设定阈值；

若是，则将所述用户的历史偏好车辆类型确定为向所述用户推送的服务车辆类型；若不是，则选择应答率最高的服务车辆类型作为向所述用户推送的服务车辆类型。

所述出行服务信息还包括以下信息中的一种或多种：

预估价格；预计到达时间；建议出行时间；出行距离；天气信息；路况信息。

所述第二确定模块82，具体用于根据以下步骤确定所述建议出行时间：

根据所述用户的历史出行数据或日历行程数据，确定所述用户到达目的地的规定时间；

根据所述用户需要到达的目的地信息和出发地信息、出行时的拥堵情况和天气情况、以及所述用户到达目的地的规定时间，确定所述建议出行时间。

所述推送模块83，具体用于根据以下步骤向所述用户的客户端推送所述出行服务信息：

根据所述建议出行时间，向所述用户的客户端推送所述出行服务信息。

所述第二确定模块82，还用于确定所述客户端符合预设的推送条件。

所述推送条件包括以下条件中的一种或多种：

客户端版本在设定版本级别以上；在最近设定时长内针对所述客户端的推送频次低于设定阈值；所述客户端为非企业支付客户端；与所述用户的出发地距离预设范围内存在应答率大于设定阈值的服务车辆类型；客户端的服务界面为预设服务车辆类型的服务界面。

所述装置还包括：

聚类模块84，用于通过将所述用户的历史出行订单中的各个出行地址进行聚类，得到所述用户的家庭住址和办公地址；以及，通过将所述用户的历史出行订单中的各个出行时间进行聚类，得到所述用户的上班时间和下班时间，或者根据所述用户的历史出行订单中记录的所述用户打车去往所述办公地址的时间确定所述上班时间，根据所述用户打车去往所述家庭地址的时间确定所述下班时间；

所述第一确定模块81，具体用于根据以下步骤确定所述用户需要到达的目的地信息：

根据用户当前所在位置和当前时间信息，以及聚类得到的所述的家庭住址和办公地址、上班时间和下班时间，确定所述用户需要到达的目的地信息。

所述推送模块83，具体用于根据以下步骤向所述用户的客户端推送所述出行服务信息：

向所述用户的客户端推送携带有所述出行服务信息的通知栏消息，所述通知栏消息用于在所述客户端的通知栏中进行展示。

所述推送模块83，具体用于根据以下步骤向所述用户的客户端推送所述出行服务信息：

向所述用户的客户端推送携带有所述出行服务信息的发单页面信息，所述发单页面信息用于在所述客户端的发单页面中展示所述出行服务信息。

所述装置还包括：

获取模块85，用于获取所述用户的日历行程读取权限。

所述推送模块83，还用于向所述用户的客户端推送权限修改提醒信息，用于提醒用户能够在设置功能中修改平台的日历行程读取权限。

所述获取模块85，具体用于根据以下步骤获取所述用户的日历行程读取权限：

在所述用户的客户端首次注册时，向所述客户端发送日历行程读取权限请求；或者，

在平台未具有用户的日历行程读取权限的情况下，周期性向所述客户端发送日历行程读取权限请求；或者，

接收所述客户端发送的用户主动设置由平台享有日历行程读取权限的通知消息。

所述日历行程数据包括以下信息中的一种或多种：

会议安排的时间和地点；

航班对应的出发时间、出发地和目的地；

火车班次对应的出发时间、出发地和目的地。

本申请实施例提供的信息推送装置80，可以根据建议出行时间向用户的客户端推送出行服务信息的过程，可以根据出行时道路的拥堵情况和天气情况，为用户确定建议出行时间，从而可以在建议出行时间或建议出行时间之前向用户的客户端推送出行服务信息，使用户可以提前做好准备，并确保用户可以按时到达目的地，为用户的出行带来便利。

实施例九

如图13所示，本申请实施例还提供了一种电子设备90，包括：处理器91、存储器92和总线93，所述存储器92存储有所述处理器可执行的机器可读指令，当电子设备90运行时，所述处理器91与所述存储器92之间通过总线通信，所述处理器执行所述计算机程序时执行如下处理：

根据用户的历史出行数据或日历行程数据，确定所述用户需要到达的目的地信息；

根据所述用户需要到达的目的地信息和所述用户的出发地信息，确定为所述用户提供的出行服务信息；所述出行服务信息中包括所述目的地信息和服务车辆类型；

向所述用户的客户端推送所述出行服务信息。

在具体实施中，上述处理器91执行的处理中，根据以下步骤确定推送的服务车辆类型：

基于与所述用户的出发地距离预设范围的不同服务车辆类型的应答率和所述用户的历史偏好车辆类型，确定为所述用户推送的服务车辆类型。

在具体实施中，上述处理器91执行的处理中，基于与所述用户的出发地距离预设范围的不同服务车辆类型的应答率和所述用户的历史偏好车辆类型，确定为所述用户推送的服务车辆类型，包括：

判断所述用户的历史偏好车辆类型的应答率是否大于设定阈值；

若是，则将所述用户的历史偏好车辆类型确定为向所述用户推送的服务车辆类型；若不是，则选择应答率最高的服务车辆类型作为向所述用户推送的服务车辆类型。

在具体实施中，上述处理器91执行的处理中，所述出行服务信息还包括以下信息中的一种或多种：

预估价格；预计到达时间；建议出行时间；出行距离；天气信息；路况信息。

在具体实施中，上述处理器91执行的处理中，若所述出行服务信息包括建议出行时间，根据以下步骤确定所述建议出行时间：

根据所述用户的历史出行数据或日历行程数据，确定所述用户到达目的地的规定时间；

根据所述用户需要到达的目的地信息和出发地信息、出行时的拥堵情况和天气情况、以及所述用户到达目的地的规定时间，确定所述建议出行时间。

在具体实施中，上述处理器91执行的处理中，向所述用户的客户端推送所述出行服务信息，包括：

根据所述建议出行时间，向所述用户的客户端推送所述出行服务信息。

在具体实施中，上述处理器91执行的处理中，向所述用户的客户端推送所述出行服务信息之前，还包括：

确定所述客户端符合预设的推送条件。

在具体实施中，上述处理器91执行的处理中，所述推送条件包括以下条件中的一种或多种：

客户端版本在设定版本级别以上；在最近设定时长内针对所述客户端的推送频次低于设定阈值；所述客户端为非企业支付客户端；与所述用户的出发地距离预设范围内存在应答率大于设定阈值的服务车辆类型；客户端的服务界面为预设服务车辆类型的服务界面。

在具体实施中，上述处理器91执行的处理中，根据用户的历史出行数据，确定所述用户需要到达的目的地信息之前，还包括：

通过将所述用户的历史出行订单中的各个出行地址进行聚类，得到所述用户的家庭住址和办公地址；以及，通过将所述用户的历史出行订单中的各个出行时间进行聚类，得到所述用户的上班时间和下班时间，或者根据所述用户的历史出行订单中记录的所述用户打车去往所述办公地址的时间确定所述上班时间，根据所述用户打车去往所述家庭地址的时间确定所述下班时间；

所述根据用户的历史出行数据，确定所述用户需要到达的目的地信息，包括：

根据用户当前所在位置和当前时间信息，以及聚类得到的所述的家庭住址和办公地址、上班时间和下班时间，确定所述用户需要到达的目的地信息。

在具体实施中，上述处理器91执行的处理中，向所述用户的客户端推送所述出行服务信息，包括：

向所述用户的客户端推送携带有所述出行服务信息的通知栏消息，所述通知栏消息用于在所述客户端的通知栏中进行展示。

在具体实施中，上述处理器91执行的处理中，向所述用户的客户端推送所述出行服务信息，包括：

向所述用户的客户端推送携带有所述出行服务信息的发单页面信息，所述发单页面信息用于在所述客户端的发单页面中展示所述出行服务信息。

在具体实施中，上述处理器91执行的处理中，根据用户的日历行程数据，确定所述用户需要到达的目的地信息之前，还包括：

获取所述用户的日历行程读取权限。

在具体实施中，上述处理器91执行的处理中，获取所述用户的日历行程读取权限之后，还包括：

向所述用户的客户端推送权限修改提醒信息，用于提醒用户能够在设置功能中修改平台的日历行程读取权限。

在具体实施中，上述处理器91执行的处理中，获取所述用户的日历行程读取权限，包括：

在所述用户的客户端首次注册时，向所述客户端发送日历行程读取权限请求；或者，

在平台未具有用户的日历行程读取权限的情况下，周期性向所述客户端发送日历行程读取权限请求；或者，

接收所述客户端发送的用户主动设置由平台享有日历行程读取权限的通知消息。

在具体实施中，上述处理器91执行的处理中，所述日历行程数据包括以下信息中的一种或多种：

会议安排的时间和地点；

航班对应的出发时间、出发地和目的地；

火车班次对应的出发时间、出发地和目的地。

本申请实施例所提供的进行信息推送的计算机程序产品，包括存储了处理器可执行的非易失的程序代码的计算机可读存储介质，所述程序代码包括的指令可用于执行前面方法实施例中所述的方法，具体实现可参见方法实施例，在此不再赘述。

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

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

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

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个处理器可执行的非易失的计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-OnlyMemory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上所述实施例，仅为本申请的具体实施方式，用以说明本申请的技术方案，而非对其限制，本申请的保护范围并不局限于此，尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化，或者对其中部分技术特征进行等同替换；而这些修改、变化或者替换，并不使相应技术方案的本质脱离本申请实施例技术方案的精神和范围，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应所述以权利要求的保护范围为准。

Claims (32)

1.一种信息推送方法，其特征在于，所述方法包括：

根据用户的历史出行数据或日历行程数据，确定所述用户需要到达的目的地信息；

根据所述用户需要到达的目的地信息和所述用户的出发地信息，确定为所述用户提供的出行服务信息，所述出行服务信息中包括所述目的地信息和服务车辆类型；

向所述用户的客户端推送所述出行服务信息。

2.如权利要求1所述的方法，其特征在于，根据以下步骤确定推送的服务车辆类型：

基于与所述用户的出发地距离预设范围的不同服务车辆类型的应答率和所述用户的历史偏好车辆类型，确定为所述用户推送的服务车辆类型。

3.如权利要求2所述的方法，其特征在于，基于与所述用户的出发地距离预设范围的不同服务车辆类型的应答率和所述用户的历史偏好车辆类型，确定为所述用户推送的服务车辆类型，包括：

判断所述用户的历史偏好车辆类型的应答率是否大于设定阈值；

若是，则将所述用户的历史偏好车辆类型确定为向所述用户推送的服务车辆类型；若不是，则选择应答率最高的服务车辆类型作为向所述用户推送的服务车辆类型。

4.如权利要求1所述的方法，其特征在于，所述出行服务信息还包括以下信息中的一种或多种：

预估价格；预计到达时间；建议出行时间；出行距离；天气信息；路况信息。

5.如权利要求4所述的方法，其特征在于，若所述出行服务信息包括建议出行时间，根据以下步骤确定所述建议出行时间：

根据所述用户的历史出行数据或日历行程数据，确定所述用户到达目的地的规定时间；

根据所述用户需要到达的目的地信息和出发地信息、出行时的拥堵情况和天气情况、以及所述用户到达目的地的规定时间，确定所述建议出行时间。

6.如权利要求5所述的方法，其特征在于，向所述用户的客户端推送所述出行服务信息，包括：

根据所述建议出行时间，向所述用户的客户端推送所述出行服务信息。

7.如权利要求1所述的方法，其特征在于，向所述用户的客户端推送所述出行服务信息之前，还包括：

确定所述客户端符合预设的推送条件。

8.如权利要求7所述的方法，其特征在于，所述推送条件包括以下条件中的一种或多种：

客户端版本在设定版本级别以上；在最近设定时长内针对所述客户端的推送频次低于设定阈值；所述客户端为非企业支付客户端；与所述用户的出发地距离预设范围内存在应答率大于设定阈值的服务车辆类型；客户端的服务界面为预设服务车辆类型的服务界面。

9.如权利要求1所述的方法，其特征在于，根据用户的历史出行数据，确定所述用户需要到达的目的地信息之前，还包括：

通过将所述用户的历史出行订单中的各个出行地址进行聚类，得到所述用户的家庭住址和办公地址；以及，通过将所述用户的历史出行订单中的各个出行时间进行聚类，得到所述用户的上班时间和下班时间，或者根据所述用户的历史出行订单中记录的所述用户打车去往所述办公地址的时间确定所述上班时间，根据所述用户打车去往所述家庭地址的时间确定所述下班时间；

所述根据用户的历史出行数据，确定所述用户需要到达的目的地信息，包括：

根据用户当前所在位置和当前时间信息，以及聚类得到的所述的家庭住址和办公地址、上班时间和下班时间，确定所述用户需要到达的目的地信息。

10.如权利要求1所述的方法，其特征在于，向所述用户的客户端推送所述出行服务信息，包括：

向所述用户的客户端推送携带有所述出行服务信息的通知栏消息，所述通知栏消息用于在所述客户端的通知栏中进行展示。

11.如权利要求1所述的方法，其特征在于，向所述用户的客户端推送所述出行服务信息，包括：

向所述用户的客户端推送携带有所述出行服务信息的发单页面信息，所述发单页面信息用于在所述客户端的发单页面中展示所述出行服务信息。

12.如权利要求1所述的方法，其特征在于，根据用户的日历行程数据，确定所述用户需要到达的目的地信息之前，还包括：

获取所述用户的日历行程读取权限。

13.如权利要求12所述的方法，其特征在于，获取所述用户的日历行程读取权限之后，还包括：

向所述用户的客户端推送权限修改提醒信息，用于提醒用户能够在设置功能中修改平台的日历行程读取权限。

14.如权利要求12所述的方法，其特征在于，获取所述用户的日历行程读取权限，包括：

在所述用户的客户端首次注册时，向所述客户端发送日历行程读取权限请求；或者，

在平台未具有用户的日历行程读取权限的情况下，周期性向所述客户端发送日历行程读取权限请求；或者，

接收所述客户端发送的用户主动设置由平台享有日历行程读取权限的通知消息。

15.如权利要求1所述的方法，其特征在于，所述日历行程数据包括以下信息中的一种或多种：

会议安排的时间和地点；

航班对应的出发时间、出发地和目的地；

火车班次对应的出发时间、出发地和目的地。

16.一种信息推送装置，其特征在于，所述装置包括：第一确定模块、第二确定模块和推送模块；其中，

所述第一确定模块，用于根据用户的历史出行数据或日历行程数据，确定所述用户需要到达的目的地信息；

所述第二确定模块，用于根据所述用户需要到达的目的地信息和所述用户的出发地信息，确定为所述用户提供的出行服务信息；所述出行服务信息中包括所述目的地信息和服务车辆类型；

所述推送模块，所述向所述用户的客户端推送所述出行服务信息。

17.如权利要求16所述的装置，其特征在于，所述第二确定模块具体用于根据以下步骤确定推送的服务车辆类型：

基于与所述用户的出发地距离预设范围的不同服务车辆类型的应答率和所述用户的历史偏好车辆类型，确定为所述用户推送的服务车辆类型。

18.如权利要求17所述的装置，其特征在于，所述第一确定模块，具体用于根据以下步骤确定为所述用户推送的服务车辆类型：

判断所述用户的历史偏好车辆类型的应答率是否大于设定阈值；

若是，则将所述用户的历史偏好车辆类型确定为向所述用户推送的服务车辆类型；若不是，则选择应答率最高的服务车辆类型作为向所述用户推送的服务车辆类型。

19.如权利要求16所述的装置，其特征在于，所述出行服务信息还包括以下信息中的一种或多种：

预估价格；预计到达时间；建议出行时间；出行距离；天气信息；路况信息。

20.如权利要求19所述的装置，其特征在于，所述第二确定模块，具体用于根据以下步骤确定所述建议出行时间：

根据所述用户的历史出行数据或日历行程数据，确定所述用户到达目的地的规定时间；

根据所述用户需要到达的目的地信息和出发地信息、出行时的拥堵情况和天气情况、以及所述用户到达目的地的规定时间，确定所述建议出行时间。

21.如权利要求20所述的装置，其特征在于，所述推送模块，具体用于根据以下步骤向所述用户的客户端推送所述出行服务信息：

根据所述建议出行时间，向所述用户的客户端推送所述出行服务信息。

22.如权利要求16所述的装置，其特征在于，所述第二确定模块，还用于确定所述客户端符合预设的推送条件。

23.如权利要求22所述的装置，其特征在于，所述推送条件包括以下条件中的一种或多种：

客户端版本在设定版本级别以上；在最近设定时长内针对所述客户端的推送频次低于设定阈值；所述客户端为非企业支付客户端；与所述用户的出发地距离预设范围内存在应答率大于设定阈值的服务车辆类型；客户端的服务界面为预设服务车辆类型的服务界面。

24.如权利要求16所述的装置，其特征在于，所述装置还包括：

聚类模块，用于通过将所述用户的历史出行订单中的各个出行地址进行聚类，得到所述用户的家庭住址和办公地址；以及，通过将所述用户的历史出行订单中的各个出行时间进行聚类，得到所述用户的上班时间和下班时间，或者根据所述用户的历史出行订单中记录的所述用户打车去往所述办公地址的时间确定所述上班时间，根据所述用户打车去往所述家庭地址的时间确定所述下班时间；

所述第一确定模块，具体用于根据以下步骤确定所述用户需要到达的目的地信息：

根据用户当前所在位置和当前时间信息，以及聚类得到的所述的家庭住址和办公地址、上班时间和下班时间，确定所述用户需要到达的目的地信息。

25.如权利要求16所述的装置，其特征在于，所述推送模块，具体用于根据以下步骤向所述用户的客户端推送所述出行服务信息：

向所述用户的客户端推送携带有所述出行服务信息的通知栏消息，所述通知栏消息用于在所述客户端的通知栏中进行展示。

26.如权利要求16所述的装置，其特征在于，所述推送模块，具体用于根据以下步骤：

向所述用户的客户端推送携带有所述出行服务信息的发单页面信息，所述发单页面信息用于在所述客户端的发单页面中展示所述出行服务信息。

27.如权利要求16所述的装置，其特征在于，所述装置，还包括：

获取模块，用于获取所述用户的日历行程读取权限。

28.如权利要求27所述的装置，其特征在于，

所述推送模块，还用于向所述用户的客户端推送权限修改提醒信息，用于提醒用户能够在设置功能中修改平台的日历行程读取权限。

29.如权利要求27所述的装置，其特征在于，所述获取模块，具体用于根据以下步骤获取所述用户的日历行程读取权限：

在所述用户的客户端首次注册时，向所述客户端发送日历行程读取权限请求；或者，

在平台未具有用户的日历行程读取权限的情况下，周期性向所述客户端发送日历行程读取权限请求；或者，

接收所述客户端发送的用户主动设置由平台享有日历行程读取权限的通知消息。

30.如权利要求16所述的装置，其特征在于，所述日历行程数据包括以下信息中的一种或多种：

会议安排的时间和地点；

航班对应的出发时间、出发地和目的地；

火车班次对应的出发时间、出发地和目的地。

31.一种电子设备，其特征在于，包括：处理器、存储器和总线，所述存储器存储有所述处理器可执行的机器可读指令，当电子设备运行时，所述处理器与所述存储器之间通过总线通信，所述处理器执行所述计算机程序时实现如权利要求1至15任一所述方法的步骤。

32.一种计算机可读存储介质，其特征在于，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行如权利要求1至15任一所述方法的步骤。

Images