基于用户打车偏好的信息推送及装置
技术领域
本申请涉及计算机应用领域,尤其涉及一种基于用户打车偏好的信息推送及装置。
背景技术
随着移动互联网、O2O、大数据等越来越普及,对于怎么利用好数据对业务进行有效的支撑变得非常重要,越来越多的互联网公司都提出了大数据运营的概念,利用数据来指导业务,让数据真正成为一座“油田”。
作为一站式生活服务平台的支付宝(alipay),用户的信息界面最直观最大的一项变动,就是在用户首页输出下拉菜单。通过后台的数据分析对用户的日常行为进行理解,将用户在生活中开通过的、关注过的以及感兴趣的各类需求以信息卡片的形式在用户首页的“生活动态”板块中直接推送给用户;然而,在实际应用中,由于用户的线下需求各式各样,因此如何向用户首页中推送信息卡片,来及时的满足用户基本生活中“衣食住行”的各类需求,对于提升用户体验具有十分重要的意义。
发明内容
本申请提出一种基于用户打车偏好的信息推送,所述方法包括:
从用户打车出行的交易明细数据中采集打车行为数据样本;
基于预设的数据挖掘算法针对采集到的打车行为数据样本进行统计分析,以确定用户的打车行为偏好;其中,所述打车行为偏好包括用户偏好的目标打车时段,以及用户在所述目标打车时段内偏好的目标打车地点;
实时判断当前时间是否命中用户偏好的目标打车时段;
如果当前时间命中用户偏好的目标打车时段,进一步判断用户当前的定位位置是否命中用户在所述目标打车时段内偏好的目标打车地点;
如果是,向用户客户端推送对应于所述目标打车地点的第一打车提示信息;如果否,向用户客户端推送对应于所述目标打车时段的第二打车提示信息,以在所述用户客户端的用户首页展示。
本申请还提出一种基于用户打车偏好的信息推送装置,所述装置包括:
采集模块,从用户打车出行的交易明细数据中采集打车行为数据样本;
分析模块,基于预设的数据挖掘算法针对采集到的打车行为数据样本进行统计分析,以确定用户的打车行为偏好;其中,所述打车行为偏好包括用户偏好的目标打车时段,以及用户在所述目标打车时段内偏好的目标打车地点;
判断模块,实时判断当前时间是否命中用户偏好的目标打车时段;如果当前时间命中用户偏好的目标打车时段,进一步判断用户当前的定位位置是否命中用户在所述目标打车时段内偏好的目标打车地点;
推送模块,如果用户当前的定位位置命中用户在所述目标打车时段内偏好的目标打车地点,向用户客户端推送对应于所述目标打车地点的第一打车提示信息;如果用户当前的定位位置未命中用户在所述目标打车时段内偏好的目标打车地点,向用户客户端推送对应于所述目标打车时段的第二打车提示信息,以在所述用户客户端的用户首页展示。
本申请中,通过从用户打车出行的交易明细数据中挖掘出用户偏好的目标打车时段,以及用户在该目标打车时段内偏好的目标打车地点等打车行为偏好,并在基于挖掘出的用户的打车行为偏好,实时判断出用户具有打车需求时,及时的向用户客户端推送相应的打车提示信息,在用户客户端的用户首页进行展示;同时,针对用户不同的打车需求,可以分别推送不同的打车提示信息,从而可以以一种更加自然的推送方式,在预判出用户具有打车需求时,及时向用户推送相应的打车提示信息,因此可以优化用户体验,提升用户在通过用户客户端进行打车的使用率。
附图说明
图1是本申请一实施例示出的一种基于用户打车偏好的信息推送方法的流程图;
图2是本申请一实施例示出的用于挖掘用户偏好的打车时间段的数据挖掘算法的处理流程图;
图3是本申请一实施例示出的一种基于用户打车偏好的信息推送装置的逻辑框图;
图4是本申请一实施例示出的承载所述基于用户打车偏好的信息推送装置的服务端所涉及的硬件结构图。
具体实施方式
在相关技术中,用户在通过搭载了打车功能的用户客户端进行打车时,通常是在具有打车需求时,再通过手动触发用户客户端提供的打车界面的入口选项进入打车界面,然后在打车界面中手动输入打车目的地,由用户客户端生成相应的打车订单并提交订单来完成打车操作。
一方面,目前大多数搭载了打车功能的用户客户端,其打车界面的入口很深,不够直观且用户很难发觉,因此可能需要用户进行多次操作,才能够进入打车界面(比如可能需要点击多个菜单才能找到打车界面的入口),完成本次打车的目的地的输入,以及订单的提交等操作。
另一方面,目前的大多数搭载了打车功能的用户客户端,通常仅会在打车界面中的地址列表中,添加几个用户历史使用过的目的地址,供用户选择,并不会对用户的打车行为偏好进行主动挖掘,也并不会对用户的打车需求进行主动预测。
可见,现有的搭载了打车功能的用户客户端,由于打车入口较深,并且并不会主动的挖掘用户的打车行为偏好,以及对用户的打车需求进行预判,因此用户使用客户端进行打车的使用率很低,而且用户的体验不佳。
有鉴于此,本申请提出一种基于用户打车偏好的信息推送方法,通过从用户打车出行的交易明细数据中挖掘出用户偏好的目标打车时段,以及用户在该目标打车时段内偏好的目标打车地点等打车行为偏好,并在基于挖掘出的用户的打车行为偏好,实时判断出用户具有打车需求时,及时的向用户客户端推送相应的打车提示信息,在用户客户端的用户首页进行展示;同时,针对用户不同的打车需求,可以分别推送不同的打车提示信息;
一方面,在本申请中,可以基于用户打车出行的交易明细数据,来主动挖掘出用户的打车行为偏好;
另一方面,可以基于挖掘出的用户的打车行为偏好,预判用户的打车需求,并且可以以一种更加自然的推送方式,在预判出用户具有打车需求时,及时向用户推送相应的打车提示信息,在用户客户端的用户首页进行展示。
因此,不仅可以基于挖掘出的用户打车行为偏好,预判用户是否具有打车需求;而且可以在预判出用户具有打车需求时,及时向用户发出打车提示,从而可以优化用户体验,提升用户在通过用户客户端进行打车的使用率。
下面通过具体实施例并结合具体的应用场景对本申请进行描述。
请参考图1,图1是本申请一实施例提供的一种基于用户打车偏好的信息推送,应用于服务端,所述方法执行以下步骤:
步骤101,从用户打车出行的交易明细数据中采集打车行为数据样本;
上述服务端,具体可以是面向用户客户端提供服务的服务器、服务器集群或者基于服务器集群搭建的服务平台。上述用户客户端,具体可以包括搭载了打车功能的客户端软件;
例如,上述用户客户端可以是支付宝APP,在支付宝APP中可以搭载第三方打车客户端的入口选项;而上述服务端,则可以是面向支付宝APP提供服务器的支付宝服务平台。
在本申请中,服务端可以收集各用户日常打车出行的交易明细数据,然后按照固定的数据格式,从收集到的交易明细数据中采集相应的信息,来生成打车行为数据样本,然后结合预设的数据挖掘算法,对采集到的打车行为数据样本进行统计分析,得出各用户的打车行为偏好。
其中,在示出的一种实施方式中,上述打车行为数据样本的数据格式可以如表1所示:
user_id |
用户id |
city |
城市 |
has_take_taxi |
是否打车 |
time_date |
日期 |
time_hour |
小时 |
time_is_workday |
是否工作日 |
time_week |
星期一、二…日 |
start_longitude |
出发地经度 |
start_latitude |
出发地纬度 |
end_address |
目的地点 |
表1
由表1可知,上述打车行为数据样本的数据格式中,可以包括用户标识字段、打车城市字段、是否打车字段、打车日期字段、打车时段字段、是否为工作日字段、星期字段、出发地点经度字段、出发地点纬度字段、以及目的地点字段。当然,在实际应用中,上述打车行为数据样本所包含的具体字段,可以基于实际的数据挖掘需求进行自定义,在本申请中不进行特别限定。
其中,需要说明的是,如表1示出的打车行为数据样本中所包含的打车时段字段(即表1中示出的time_hour字段)所对应的单位时段,在实际应用中可以设置为一个较小的值;
例如,表1中示出的单位时段为1小时,即服务端在采集数据时,可以分别采集用户在每一个小时时段内的打车数据,来生成一条打车行为数据样本,从而最终采集到的每一条打车行为数据样本,将分别包含用户在该小时段内的打车行为数据。
通过将上述打车时段字段对应的单位时段的取值,设置为一个较小的值,可以确保在基于数据挖掘算法对采集到的打车行为数据样本进行统计分析时,能够保持一个较小的数据挖掘的时间间隔,从而提升最终数据挖掘结果的准确度。
当然,表1中仅以上述打车时段字段所对应的单位时段为1小时作为示例,在实际应用中,上述打车时间段所对应的单位时段,可以基于实际的需求进行自定义;例如,如果对最终数据挖掘的结果要求更高时,可以将上述打车时间段对应的单位时段设置为小于1小时的一个更小的单位时段(比如30分钟)。
可见,以表1所示出的标准格式采集数据,可以对最终采集到的打车行为数据样本的数据格式进行规范化,从而便于后续结合预设的数据挖掘算法进行统计分析。
步骤102,基于预设的数据挖掘算法针对采集到的打车行为数据样本进行统计分析,以确定用户的打车行为偏好;其中,所述打车行为偏好包括用户偏好的目标打车时段,以及用户在所述目标打车时段内偏好的目标打车地点;
对于采集完成并且按照归属的城市进行归类后的打车行为数据样本,服务端可以基于搭载的数据挖掘算法,进行统计分析计算,进而挖掘出用户在不同城市中的打车行为偏好。
在本申请中,上述打车行为偏好,具体可以包括用户偏好的目标打车时段,以及用户在该目标打车时段内偏好的目标打车地点。
以下将结合具体的例子分别介绍用户偏好的目标打车时段,以及用户偏好的目标打车地点的挖掘过程。
1)用户偏好的目标打车时段的挖掘
请参见图2,图2为本申请示出的一种用于挖掘用户偏好的打车时间段的数据挖掘算法的处理流程图。
服务端在基于该数据挖掘算法,对从采集完成的打车行为数据样本中筛选出的打车行为数据样本进行统计分析计算之前,可以预先对筛选出的打车行为数据样本按照打车时间的先后顺序进行排序,完成对待计算数据样本的预处理。
如图2所示,当预处理完成,服务端在基于该数据挖掘算法,对从采集完成的打车行为数据样本中筛选出的打车行为数据样本进行统计分析计算时:
一方面,可以基于打车行为数据样本,统计用户在各第一单位时段内的打车次数,并查找打车次数大于第一阈值的第一单位时段;
另一方面,还可以基于打车行为数据样本,统计用户在各第二单位时段内的打车次数;其中,上述第二单位时段由各第一单位时段内的任意两个连续的第一单位时段组成;
例如,以上述打车行为数据样本中的打车时段对应的单位时段为1小时为例,上述第一单位时间段可以是1小时,而上述第二单位时段可以是每一个1小时时段内的任意两个连续的1小时时段组成的2小时时段;即对于任意一个第二单位时段来说,可以是由两个连续的第一单位时段组成;而且,组成这两个第二单位时段的第一单位时段可以存在交集;比如,1点-2点,2点-3点、3点-4点以及4点到5点可以分别构成一个第一单位时段;而1点到3点,2点到4点以及3点到5点,可以分别构成3个第二单位时段,连续的第二单位时段可以在时间上存在交集。
当统计出用户在各第二单位时段内的打车次数后,可以查找打车次数大于第二阈值,并且用户在组成该第二单位时段的第一单位时段内的打车次数均大于第三阈值的第二单位时段;其中,上述第二阈值大于上述第一阈值;而上述第三阈值的具体取值,在本申请不进行特别限定,可以小于所述第一阈值,也可以大于所述第一阈值;比如,在一个例子中,上述第三阈值的取值可以为1。
请继续参见图2,当服务端查找到了打车次数大于第一阈值的第一时间单位时间,以及查找到了打车次数大于第二阈值,并且用户在组成该第二单位时段的第一单位时段内的打车次数均大于第三阈值的第二单位时段后,可以将查找到的该第一单位时间段和第二单位时间段进行时段拼接,生成对应的时段区间,然后将拼接得到的该时段区间作为用户偏好的目标打车时段。
在本例中,当统计出用户偏好的目标打车时段后,可以进一步基于在该目标打车时段内的打车总次数,来计算该目标打车时段的打车概率。
例如,在示出的一种实施方式中,可以计算该目标打车时段内的打车总次数,与输入的打车行为数据样本对应的总天数的目标比值,然后将该目标比值确定为对应于该目标打车时段的打车概率。
举例而言,假设服务端筛选出了用户在某个城市近N天的打车行为数据样本作为算法的输入数据,第一阈值为threshold,第二阈值可以为threshold+1,第三阈值为1;第一单位时段对应的单位时段为1小时,对应的打车次数用Ai来表示;第二单位时段为2小时时段,对应的打车次数用Bi来表示。
步骤1,服务端可以分别统计每一个第一单位时段内以及每一个第二单位时间段内用户的打车次数。
假设Ai时段的统计结果如下表所示:
时段编号 |
1 |
2 |
3 |
4 |
5 |
Ai |
0次 |
1次 |
2次 |
3次 |
1次 |
此时,Bi时段的统计结果将如下表所示:
步骤2,服务端可以找出打车次数的高频时段。
对于Ai,服务端查找出所有Ai>threshold的第一单位时间段。
对于Bi,服务端查找出所有Bi>threshold+1,且Bi对应的所有Ai>1的第二单位时间段。
步骤3,服务端可以将满足条件的Ai对应的第一单位时间段,Bi对应的第二单位时间段拼接成时间段区间。假设在该时间段区间内的打车次数为m,服务端还可以根据如下公式计算打车概率:
步骤4,当完成上述计算后,服务端可以输出用户偏好的时间段的挖掘结果,以便于后续可以基于该挖掘结果,来预判用户的打车需求;其中,该挖掘结果具体可以包括用户打车的偏好时间段和打车概率,格式为(user_id,city,interval,probability)。user_id表示用户的标识;city表示打车的城市;interval表示用户偏好的时间段;probability表示打车概率。
在本例中,上述用户偏好的目标打车时段,可以进一步细分为用户偏好的工作日打车时段、用户偏好的周末打车时段以及用户偏好的周规律打车时段。
其中,上述用户偏好的工作日打车时段,是指用户在日常的工作日进行打车时所偏好的时间段;该用户偏好的工作日打车时段,可以表达出用户在工作日打车时的时间规律;例如,假设用户偏好的工作日时段为17:30-18:00,则表明用户习惯于在工作日的下午17:30-18:00打车。
上述用户偏好的周末打车时段,是指用户在日常周末休息日进行打车时所偏好的时间段;该用户偏好的周末打车时段,可以表达出用户在周末休息日打车时的时间规律;例如,假设用户偏好的周末时段为12:30-13:00,则表明用户习惯于在周末休息日的下午12:30-13:00打车。
上述用户偏好的周规律打车时段,是指用户在每周打车的周期性的时间规律;该用户偏好的周规律打车时段,可以表达出用户偏好于在每周的某一个特定的自然日中的特定时间段打车;例如,假设用户偏好的周规律打车时段,为每周的星期五的12:30-13:00,则表明用户习惯于在每周五的下午12:30-13:00打车。
需要说明的是,服务端在基于图2示出的数据挖掘算法,对采集完成的打车行为数据样本进行统计分析计算时,所使用的打车行为数据样本的类型,可以基于服务端最终需要挖掘的用户偏好的目标打车时段的具体场景来决定。
在示出的一种实施方式中,在挖掘用户偏好的工作日打车时段的场景下,如果服务端需要挖掘出用户在某一个目标城市所偏好的工作日打车时段,则可以从采集到的打车行为数据样本中,筛选出对应于工作日时段,且打车城市均为该目标城市的打车行为数据样本;然后基于图2示出的数据挖掘算法对筛选出的打车行为数据样本进行统计分析,以得到用户在该目标城市所偏好的工作日打车时段;
例如,假设用户偏好在工作日的6:00-7:59打车,那么基于图2示出的数据挖掘算法,最终输出的挖掘结果可以如下表所示:
用户 |
偏好类型 |
是否工作日 |
城市 |
星期 |
时段 |
打车概率 |
XXX |
时间偏好 |
是 |
XX |
null |
6:00-7:59 |
XX |
在挖掘用户偏好的周末打车时段的场景下,如果服务端需要挖掘出用户在某一个目标城市所偏好的周末打车时段,可以从采集到的打车行为数据样本中,筛选出对应于周末时段,且打车城市均为该目标城市的打车行为数据样本;然后基于图2所示出的数据挖掘算法对筛选出的打车行为数据样本进行统计分析,以得到用户在该目标城市所偏好的周末打车时段。
例如,假设用户偏好在周末的12:00-12:30打车,那么基于图2示出的数据挖掘算法,最终输出的挖掘结果可以如下表所示:
用户 |
偏好类型 |
是否工作日 |
城市 |
星期 |
时段 |
打车概率 |
XXX |
时间偏好 |
否 |
XX |
null |
12:00-12:30 |
XX |
在挖掘用户偏好的周规律打车时段的场景下,如果服务端需要挖掘出用户在某一个目标城市所偏好的周规律打车时段,可以从采集到的打车行为数据样本中,分别筛选出对应于周时段的各自然日,且打车城市均为该目标城市的打车行为数据样本;
例如,假设需要挖掘出用户在每周五打车的周期性时间规律,可以在近N个周的打车行为数据样本,筛选出星期五的打车行为数据样本,并基于图2示出的数据挖掘算法,分别进行统计分析,以得到用户在每周五偏好的打车时间段。
然后可以基于图2所示出的数据挖掘算法对筛选出的打车行为数据样本进行统计分析,以得到用户在该目标城市所偏好的周末打车时段;
例如,假设用户习惯于在每周的星期五的17:00-17:59打车,那么按照图2示出的数据挖掘算法,最终输出的挖掘结果可以如下表所示:
另外,需要说明的是,服务端在基于图2示出的数据挖掘算法,挖掘用户偏好的目标打车时段时,在不同的场景下上述数据挖掘算法所采用的参数,可以互不相同,本领域技术人员可以基于需求,或者结合工程经验来进行赋值。
例如,在示出的一种实现方式中,以上示出的三个不同的场景下的参数可以如下表所示:
当然,需要说明的是,上表中示出的在不同的场景下上述数据挖掘算法所使用的参数,仅为示例性的,并不用于限定本申请的技术方案。
2)用户偏好的目标打车地点的挖掘
在本例中,由于用户偏好的每一个打车时间段,用户所处的打车地点通常具有差异性;例如,某用户在工作日的早晨打车时,起始地点可能是家里,目的地点可能是公司;而用户在工作日的傍晚打车时,起始地点可能是公司,目的地点可能是家里;而用户在每周五打车时,起始地点可能是公司,目的地点可能是火车站;因此,在本申请中,针对用户偏好的目标打车地点的挖掘,是在基于图2所示出的数据挖掘算法,挖掘出用户偏好的打车时间段的基础上完成的,服务端需要针对按照图2示出的数据挖掘算法所挖掘出的每一个用户偏好的目标打车时间段,分别进一步挖掘出用户在该目标打车时间段内偏好的目标打车地点。
其中,用户偏好的目标打车地点,可以进一步细分为用户偏好的打车起始地点、用户偏好的打车目的地点以及用户偏好的打车位置范围。
当服务端需要针对某一个已经挖掘出的用户偏好的目标打车时间段,进一步挖掘出用户在在该目标打车时间段内偏好的目标打车地点时,首先可以统计出用户在该目标时段内的所有打车出发地点的位置信息;比如,打车出发的起始位置的经纬度;
然后,服务端可以基于统计出的用户在该目标时段内的所有打车出发地点的位置信息进行聚类分析,并基于聚类分析的结果查找包含的打车出发地点最多,且包含的打车出发地点的数量大于预设阈值的目标类簇。
最后,服务端可以计算该目标类簇的中心点,并将该目标类簇的中心点对应的目标地点,确定为用户偏好的打车起始地点;相似的,服务端还可以进一步计算该目标类簇的半径,并将与该目标类簇的半径对应的位置范围,确定为用户偏好的打车位置范围;以及,还可以进一步统计与该目标类簇中各打车出发地点对应的打车行为数据样本中,使用频率最高的目的地点,然后该目的地点确定为用户偏好的打车目的地点。
当完成上述计算后,服务端可以输出用户在该目标打车时间段内偏好的目标打车地点的挖掘结果,以便于后续可以基于该挖掘结果,来预判用户的打车需求;其中,该挖掘结果具体可以包括用户在该目标打车时间段内偏好的起始地点、用户偏好的打车位置范围以及用户偏好的打车目的地点。
例如,假设上述目标类簇的中心点经度为120.13,维度为30.2,该目标类簇的半径为110米,用户偏好的打车目的地点为西溪河东,那么最终输出的用户在该目标打车时间段内偏好的目标打车地点的挖掘结果,可以如下表所示:
步骤103,实时判断当前时间是否命中用户偏好的目标打车时段;如果当前时间命中用户偏好的目标打车时段,进一步判断用户当前的定位位置是否命中用户在所述目标打车时段内偏好的目标打车地点;
在本例中,各用户所使用的用户客户端,可以实时的向服务端上传对应于当前时间的时间戳,以及用户的定位位置(比如基于GPS模块采集到的用户的经纬度数据),而服务端在基于采集到的用户的打车行为数据样本,最终挖掘出了该用户偏好的打车时间段,以及在该打车时间段内的偏好的打车地点后,可以基于用户客户端实时上传的时间戳,实时的判断该时间戳是否命中该用户客户端的使用用户所偏好的目标打车时间段。
如果该时间戳命中了该用户所偏好的目标打车时间段,此时可以基于该用户客户端上传的该用户的定位位置,来进一步判断该用户当前的定位位置是否命中该用户在上述目标打车时间段内偏好的目标打车地点;
例如,可以将该用户的定位位置的经纬度信息,与挖掘出的该用户偏好的起始地点的经纬度信息,以及该用户偏好的打车位置范围进行匹配,来确认该用户的定位位置是否命中了该用户偏好的起始地点,或者该用户的定位位置是否在该用户偏好的打车位置范围之内。
步骤104,如果用户当前的定位位置命中用户在所述目标打车时段内偏好的目标打车地点,向用户客户端推送对应于所述目标打车地点的第一打车提示信息,以在所述用户客户端的用户首页展示。
步骤105,如果用户当前的定位位置未命中用户在所述目标打车时段内偏好的目标打车地点,向用户客户端推送对应于所述目标打车时段的第二打车提示信息,以在所述用户客户端的用户首页展示。
如果经过确认得知该用户当前的定位位置,命中了该用户在上述目标打车时间段内偏好的目标打车地点时,此时服务端将预判出该用户在当前时段可能存在前往该目标打车地点的打车需求;在这种情况下,可以向上述用户客户端推送对应于上述目标打车地点的第一打车提示信息。
当然,如果经过确认得知该用户当前的定位位置,未命中该用户在上述目标打车时间段内偏好的目标打车地点时,此时服务端将预判出该用户在当前时段可能存在打车需求;此时可以向上述用户客户端推送对应于上述目标打车时段的第二打车提示信息。
在实际应用中,由于上述上述第一打车提示信息和第二打车提示信息,分别对应于用户不同的打车需求,因此可以基于用户具体的打车需求,因此上述第一打车提示信息和第二打车提示信息,可以分别对应不同的文案;当用户客户端接收到服务端推送的上述第一打车提示信息或者第二打车提示信息后,可以将接收到的打车提示信息在用户首页展示;
例如,以上述用户客户端为支付宝客户端为例,假设服务端预判出用户的打车需求为在工作日的下午17:30-18:00打车回家,那么服务端需要推送至用户客户端的第一打车提示信息的文案内容具体可以是“下班啦,叫辆车回家吧”;支付客户端在接收到服务端推送的该第一打车提示信息后,可以在用户首页的“生活动态”板块中向用户呈现一条文案为“下班啦,叫辆车回家吧”的出行卡片,从而使得用户可以更加直观的查看到由服务端预判出的打车需求。
又如,假设服务端预判出用户的打车需求为在工作日的上午8:30-9:00打车去公司,那么服务端需要推送至用户客户端的第一打车提示信息的文案内容具体可以是“早上好,叫辆车上班吧”;支付客户端在接收到服务端推送的该第一打车提示信息后,可以在用户首页的“生活动态”板块中向用户呈现一条文案为“早上好,叫辆车上班吧”的出行卡片,从而使得用户可以更加直观的查看到由服务端预判出的打车需求。
其中,需要说明的是,由于服务端面向用户客户端推送的上述第一打车提示信息或者第二打车提示信息,某种程度上反映了服务端对于用户打车需求的预判结果,因此为了进一步提升打车需求预判结果的精准度,服务端在基于以上描述的用户打车需求的实时判断过程的基础上,还可以进一步引入打车概率的判断。
在这种情况下,当服务端通过以上示出的打车需求的实时判断过程,判断出客户端上传的时间戳命中了该用户偏好的打车时间段,此时可以进一步判断对应于该目标打车时段的打车概率是否大于预设阈值;如果该目标打车时间段的打车概率大于该预设阈值,此时服务端再向上述用户客户端推送上述第一打车提示信息或者上述第二打车提示信息。
通过这种方式,服务端在预判出用户在当前时间段内存在打车的需求,在向上述用户客户端推送上述第一打车提示信息或者上述第二打车提示信息之前,进一步引入打车概率的判断,只有当该打车概率大于预设阈值,再推送上述第一打车提示信息或者上述第二打车提示信息;而如果该打车概率小于该预设阈值时,此时可以停止向用户客户端输出上述打车提示信息或者上述第二打车提示信息,从而可以进一步降低服务端误判的概率,可以提升打车需求预判的准确度。
在示出的一种实施方式中,上述第一打车提示信息以及第二打车提示信息,具体可以是打车界面的入口选项。用户客户端在接收到上述第一打车提示信息以及第二打车提示信息后,可以基于接收到的打车提示信息在用户首页中展示相应的打车界面的入口选项,并输出相应的提示文案。此时,用户可以在用户首页中直接出发该入口选项,进入到打车界面,快捷的完成目的地点的输入,打车订单的生成以及提交等操作。
其中,由于第一打车提示信息与第二打车提示信息分别对应不同的打车需求,因此当用户通过触发第一打车提示信息与第二打车提示信息后,打车界面中所展示的内容,也可以略有不同。
在示出的一种实施方式中,当用户触发了在用户首页展示的第一打车提示信息后,此时用户客户端可以向服务端发送一个数据获取请求;而服务端在收到该数据获取请求后,可以将与打车界面对应的页面数据,推送至该用户客户端;用户客户端在收到页面数据后,可以基于接收到的该页面数据,跳转至打车界面。
在示出的另一种实施方式中,当用户触发了在用户首页展示的第二打车提示信息后,此时用户客户端也可以向服务端发送一个数据获取请求;而服务端在收到该数据获取请求后,由于服务端预先已经挖掘出用户在当前时间段内偏好的打车目的地点,因此可以将与打车界面对应的页面数据,以及预先挖掘出的该用户偏好的打车目的地点推送至该用户客户端;用户客户端在收到页面数据和用户偏好的打车目的地点后,可以基于接收到的该页面数据,跳转至打车界面,并在该打车界面中的打车目的地点列表中,输出用户偏好的该打车目的地点;
例如,在一种实现方式中,可以对该打车目的地点列表中向用户推荐的目的地点进行排序,然后将用户在当前时段偏好的打车目的地点,在排序的首位向用户推荐。
可见,通过这种方式,当服务端预判出用户在当前时间段内具有前往任意一个目标地点的打车需求时,可以将该目标地点在打车界面的打车目的地点列表中的首位向用户推荐,从而可以方便用户快速的将该目标地点选定为本地打车操作的目的地点,完成打车订单的生成以及提交。
当然,在实际应用中,当服务端成功预判出用户在当前时段内具有打车需求,并且用户客户端在用户首页上也向用户输出了相应的打车提示信息后,在一段时间以后,如果预判出的用户的打车需求超时,用户仍然没有触发该打车提示信息进入到打车界面完成打车操作,那么用户客户端还可以将用户首页中已经显示的打车提示信息清除。
通过这种方式,可以在预判出的用户打车需求超时后,及时清除已经显示的打车提示信息,从而可以优化用户首页中所展示的信息,防止用户用户查看到与过期的打车需求所对应的打车提示信息,而影响用户的体验。
以上详细描述了服务端基于采集到的用户的打车行为数据样本,挖掘用户的打车行为偏好,以及服务端基于挖掘结果,实时预判用户的打车需求,向用户客户端推送打车提示信息的详细过程;需要说明的是,在另一种实施方式中,服务端在成功挖掘出用户的打车行为偏好后,也可以将挖掘结果推送给用户客户端,使得后续用户客户端可以基于本地的挖掘结果,自主的预判用户的打车需求,并通过用户首页输出相应的打车提示信息,具体的实施过程与由服务端预判用户的打车需求的实施过程相同,本申请不再进行赘述。
通过以上各实施例可知,本申请提出一种基于用户打车偏好的信息推送方法,通过从用户打车出行的交易明细数据中挖掘出用户偏好的目标打车时段,以及用户在该目标打车时段内偏好的目标打车地点等打车行为偏好,并在基于挖掘出的用户的打车行为偏好,实时判断出用户具有打车需求时,及时的向用户客户端推送相应的打车提示信息,在用户客户端的用户首页进行展示;同时,针对用户不同的打车需求,可以分别推送不同的打车提示信息;
一方面,在本申请中,可以基于用户打车出行的交易明细数据,来主动挖掘出用户的打车行为偏好;
另一方面,可以基于挖掘出的用户的打车行为偏好,预判用户的打车需求,并且可以以一种更加自然的推送方式,在预判出用户具有打车需求时,及时向用户推送相应的打车提示信息,在用户客户端的用户首页进行展示。
因此,不仅可以基于挖掘出的用户打车行为偏好,预判用户是否具有打车需求;而且可以在预判出用户具有打车需求时,及时向用户发出打车提示,从而可以优化用户体验,提升用户在通过用户客户端进行打车的使用率。
与上述方法实施例相对应,本申请还提供了装置的实施例。
请参见图3,本申请提出一种基于用户打车偏好的信息推送装置30,应用于服务端;其中,请参见图4,作为承载所述基于用户打车偏好的信息推送装置70的服务端所涉及的硬件架构中,通常包括CPU、内存、非易失性存储器、网络接口以及内部总线等;以软件实现为例,所述基于用户打车偏好的信息推送装置30通常可以理解为加载在内存中的计算机程序,通过CPU运行之后形成的软硬件相结合的逻辑装置,所述装置30包括:
采集模块301,从用户打车出行的交易明细数据中采集打车行为数据样本;
分析模块302,基于预设的数据挖掘算法针对采集到的打车行为数据样本进行统计分析,以确定用户的打车行为偏好;其中,所述打车行为偏好包括用户偏好的目标打车时段,以及用户在所述目标打车时段内偏好的目标打车地点;
判断模块303,实时判断当前时间是否命中用户偏好的目标打车时段;如果当前时间命中用户偏好的目标打车时段,进一步判断用户当前的定位位置是否命中用户在所述目标打车时段内偏好的目标打车地点;
推送模块304,如果用户当前的定位位置命中用户在所述目标打车时段内偏好的目标打车地点,向用户客户端推送对应于所述目标打车地点的第一打车提示信息;如果用户当前的定位位置未命中用户在所述目标打车时段内偏好的目标打车地点,向用户客户端推送对应于所述目标打车时段的第二打车提示信息,以在所述用户客户端的用户首页展示。
在本例中,所述打车行为数据样本包括:
用户标识字段、打车城市字段、是否打车字段、打车日期字段、打车时段字段、是否为工作日字段、星期字段、出发地点经度字段、出发地点纬度字段、以及目的地点字段。
在本例中,所述用户偏好的目标打车时段包括用户偏好的工作日打车时段、用户偏好的周末打车时段以及用户偏好的周规律打车时段;
所述分析模块302:
筛选出所述打车行为数据样本中对应于工作日时段,且打车城市相同的打车行为数据样本,基于预设的数据挖掘算法对筛选出的打车行为数据样本进行统计分析,以得到用户偏好的工作日打车时段;
筛选出所述打车行为数据样本中对应于周末时段,且打车城市相同的打车行为数据样本,基于预设的数据挖掘算法对筛选出的打车行为数据样本进行统计分析,以得到用户偏好的周末打车时段;
分别筛选出所述打车行为数据样本中对应于周时段中的各自然日,且打车地点相同的打车行为数据样本,基于预设的数据挖掘算法对筛选出的打车行为数据样本进行统计分析,以得到用户偏好的周规律打车时段。
在本例中,所述分析模块302进一步:
基于所述打车行为数据样本统计用户在各第一单位时段内的打车次数,并查找打车次数大于第一阈值的第一单位时段;
基于打车行为数据样本统计用户在各第二单位时段内的打车次数,并查找打车次数大于第二阈值,且用户在组成该第二单位时段的第一单位时段内的打车次数均大于第三阈值的第二单位时段;其中,所述第二单位时段由各第一单位时段内的任意两个连续的第一单位时段组成;所述第二阈值大于所述第一阈值;
针对查找到的第一单位时段和第二单位时段进行时段拼接,生成用户偏好的目标打车时段。
在本例中,所述分析模块302进一步:
计算该目标打车时段内的打车总次数,与所述打车行为数据样本对应的总天数的目标比值,将该目标比值确定为对应于所述目标打车时段的打车概率在本例中,所述用户偏好的目标打车地点包括用户偏好的打车起始地点、用户偏好的打车目的地点以及用户偏好的打车位置范围。
所述分析模块302进一步:
基于用户在所述目标时段内的所有打车出发地点进行聚类分析;
基于聚类分析的结果查找包含的打车出发地点最多,且包含的打车出发地点的数量大于预设阈值的目标类簇;
计算所述目标类簇的中心点,并与将所述目标类簇的中心点对应的目标地点确定为用户偏好的打车起始地点;
计算所述目标类簇的半径,并将与所述目标类簇的半径对应的位置范围确定为用户偏好的打车位置范围;
统计与所述目标类簇中各打车出发地点对应的打车行为数据样本中使用频率最高的目的地点,并将该目的地点确定为用户偏好的打车目的地点。
在本例中,所述判断模块303进一步:
在推送模块304向用户客户端推送所述第一打车提示信息或者所述第二打车提示信息之前,判断对应于所述目标打车时段的打车概率是否大于预设阈值;如果是,则由所述推送模块304向用户客户端推送所述第一打车提示信息或者所述第二打车提示信息。
在本例中,所述打车提示信息为打车界面的入口选项;
所述推送模块304进一步:
响应于所述用户客户端在检测到用户针对所述第一打车提示信息的触发操作后发出的数据获取请求,向所述用户客户端推送对应于打车界面的页面数据,以使所述用户客户端基于所述页面数据进入所述打车界面;
响应于所述用户客户端在检测到用户针对所述第二打车提示信息的触发操作后发出的数据获取请求,向所述用户客户端推送对应于打车界面的页面数据,以及用户偏好的打车目的地点,以使得所述用户客户端基于所述页面数据进入所述打车界面,并在所述打车界面中的打车目的地点列表中输出用户偏好的所述打车目的地点。
对于装置实施例而言,由于其基本对应于方法实施例,所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的,其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下,即可以理解并实施。
上述实施例阐明的系统、装置、模块或单元,具体可以由计算机芯片或实体实现,或者由具有某种功能的产品来实现。一种典型的实现设备为计算机,计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。
本领域技术人员在考虑说明书及实践这里公开的发明后,将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化,这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的,本申请的真正范围和精神由下面的权利要求指出。
应当理解的是,本申请并不局限于上面已经描述并在附图中示出的精确结构,并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求来限制。
以上所述仅为本申请的较佳实施例而已,并不用以限制本申请,凡在本申请的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本申请保护的范围之内。