一种基于精确推送的通勤服务系统及实现方法与流程

文档序号:11778509阅读:270来源:国知局
一种基于精确推送的通勤服务系统及实现方法与流程

本发明涉及通勤服务领域和计算机软件领域,特别涉及一种基于精确推送的通勤服务系统及实现方法。



背景技术:

随着城市面积逐日扩张,城市居民的出行目的更加多元化,出行范围也日渐扩大,出行结构趋向复杂化,这几乎是每个人生活中正在发生的变化。为节约时间与费用,人们希望出行效率的最大化,针对一天出行的起点与终点,形成有效的决策机制。在这样的市场背景下,诞生了众多的通勤公司,这些通勤公司普遍与各个大公司、企业以及园区合作,为它们的员工提供上下班接送服务。企业根据员工的住宿位置,设定通勤线路,交由通勤公司,通勤公司按照这个线路在规定的时间内为公司员工提供上下班接送服务。

传统的通勤市场存在着车辆运转率低、单驾成本高,承受着较大的开支压力,此外通勤车的缺点如下:

通勤车采取单班行驶制、需求采集机制不够灵活,时常有8小时闲置时间,资源无法合理配置;

每年年检、保养、司机工资等支出庞大,运维成本较高;

以上各种原因导致通勤车成本居高难下,各方收益较低。

为了实现资源分配,现有技术中的解决方法有中比如,中国申请号:201620618205.0,一种用于通勤车预约规划的信息系统,包括用于发送上下车位置和显示乘坐班次的手持终端、用于验证用户身份的nfc标签以及用于根据用户上下车位置为用户分配班次的业务服务器,手持终端和工牌共设有多个,且一一对应,分别由各用户携带,手持终端中设有用于连接nfc标签的nfc读卡器,业务服务器与所有手持终端连接;nfc读卡器建立与nfc标签的连接并验证用户身份后,手持终端向业务服务器发送该用户的上下车位置,并接收及显示由业务服务器为用户分配的班次。虽然实现了班次预约规划,但是缺少基于用户的针对性。为了有效识别通勤需求,现有技术中的解决方法有中比如,申请号:201610197051.7,通勤订单识别方法和装置,包括:获取用户的轨迹数据,其中,所述轨迹数据包括多个轨迹点的位置信息;针对各个轨迹点的位置信息利用聚类算法对轨迹点进行聚类,生成轨迹点的簇集合;将所述轨迹点的簇集合导入预先训练的通勤位置识别模型进行识别,得到第一位置信息和第二位置信息;根据获取到的所述用户的多个历史订单的位置信息、所述第一位置信息和所述第二位置信息,识别出所述历史订单中的通勤订单。虽然能够识别用户的订单号,缺点在于:无法精准推送,从而无法进行增值服务。



技术实现要素:

本发明要解决的技术问题是,。

解决上述技术问题,本发明提供了一种基于精确推送的通勤服务系统,包括:用户客户端和服务器端,

在所述服务器端接收所述用户客户端上的出行需求,

用以提供通勤路线的所述服务器端,包括:用户画像单元和规划单元,

所述用户画像单元,用以建立用户画像,

所述规划单元,用以根据所述出行需求规划通勤线路,

还包括:服务商客户端,用以制定营销策略并输入到所述用户画像单元中,将上述通勤线路在用户客户端进行响应。

更进一步,所述服务商客户端包括:策略执行单元、产品营销单元,

所述策略执行单元,用以根据用户画像匹配出对应的执行策略,

所述产品营销单元,用以按照所述执行策略提供产品体验接口。

更进一步,通过所述用户客户端上的web浏览器向所述服务器端发出访问请求,所述服务器端的web服务器查找对应页面并转交给所述服务器端的应用程序服务器,所述应用程序服务器定位并完成在所述页面的指令,并将完成的页面回传至web服务器,通过所述web服务器完成页面访问请求的响应,

所述访问请求至少包括:出行类别、上/下车点以及对应上/下时间的访问窗口。

更进一步,所述服务器端还包括:用户画像数据库和出行需求数据库,

所述用户画像数据库,用以组织并储存从所述用户客户端提交的身份信息,

所述出行需求数据库,用以组织并储存从所述用户客户端提交的需求信息。

更进一步,所述服务器端还包括:预约单元,

所述预约单元,用以将唯一验证信息推送至所述用户客户端,

所述预约单元从所述所述规划单元中获取预约线路,并将所述唯一验证信息与所述预约线路绑定。

更进一步,所述用户客户端还用以提供:一第三方辅助单元,所述第三方辅助单元包括:

提交反馈接口,用以提供对产品的是否有意向的反馈信息,

下单购买接口,用以提供对意向产品的购买通道。

更进一步,所述服务商客户端还包括:

后台订单处理单元,用以根据所述购买通道中的意向产品,生成对应的订单,

产品优化单元,用以根据提交反馈接口同步的信息,更换/去除产品,

服务商供应单元,用以根据产品优化单元或后台订单处理单元,调整供应产品或接收后台订购需求。

更进一步,系统还包括配置多个有用以灭火的消防设备和一用以验证用户身份的身份验证设备的通勤交通工具。

基于上述,本发明提供了一种基于精确推送的通勤服务方法,用于通勤班车,包括如下步骤:

接收出行需求和制定营销策略,

根据所述出行需求和/或营销策略建立用户画像,

按照所述用户画像规划通勤线路,

在所述通勤班车验证用户身份并判断是否提供免费通勤服务,以及是否提供产品体验服务。

更进一步,方法还包括:用户通过智能终端注册并进行身份验证,同时提交出行需求,

用户通过出行需求选择通勤班车,

用户通过智能终端在上车时,验证身份,

用户通过智能终端在下车前,提交产品反馈信息和/或购买需求。

本发明的有益效果:

本发明中的基于精确推送的通勤服务系统,由于包括:用户客户端和服务器端,在所述服务器端接收所述用户客户端上的出行需求,用以提供通勤路线的所述服务器端,包括:用户画像单元和规划单元,所述用户画像单元,用以根据所述出行需求建立用户画像,所述规划单元,用以按照用户画像规划通勤线路,系统中还包括:服务商客户端,用以制定营销策略并输入到所述用户画像单元中,将上述通勤线路在用户客户端进行响应。若在用户客户端身份验证成功,则通勤服务系统中所有通勤服务均为免费的,且通勤班车均是零排放、超静音、超舒适的绿色班车,比如电动班车、新能源班车等。从所述用户客户端提交的通勤需求均来自真实、有效的出行用户,并基于后台大数据运算,从而能够规划出的合理的、最优化的通勤线路,进一步有效的提升通勤班车的上座率、运转率。进一步地,所述用户画像单元中基于动态的、成长性的画像分析的通勤系统,载体为通勤班车,此外通过在服务商客户端制定营销策略,使得通勤班车上的产品与乘客关联度非常高,所以通勤服务系统中的服务商也能够获得可观的收益。

此外,获得免费服务的用户均通过了真实身份验证,且在上车时再次通过车载身份验证设备的验证。

同时,所述通勤服务系统中的通勤班车均配置了自动灭火系统,提供系统的整体安全性能。

附图说明

图1是本发明一实施例中的系统结构示意图;

图2是图1中的服务商客户端优选实施方式示意图;

图3是图1中用户客户端与服务器端交互方式示意图;

图4是图1中的服务器端优选实施方式示意图;

图5是图1中的服务器端另一优选实施方式示意图;

图6是图1中的用户客户端优选实施方式示意图;

图7是图1中的服务商客户端另一优选实施方式示意图;

图8是本发明一实施例中的方法流程示意图;

图9是图8中的优选实施方式流程示意图;

图10是本发明中具体流程示意图。

具体实施方式

现在将参考一些示例实施例描述本公开的原理。可以理解,这些实施例仅出于说明并且帮助本领域的技术人员理解和实施例本公开的目的而描述,而非建议对本公开的范围的任何限制。在此描述的本公开的内容可以以下文描述的方式之外的各种方式实施。

如本文中所述,术语“包括”及其各种变体可以被理解为开放式术语,其意味着“包括但不限于”。术语“基于”可以被理解为“至少部分地基于”。术语“一个实施例”可以被理解为“至少一个实施例”。术语“另一实施例”可以被理解为“至少一个其它实施例”。

在本申请中的用户画像(userprofile)是指完美地抽象出一个用户的信息全貌。

图1是本发明一实施例中的系统结构示意图,本实施例中的一种基于精确推送的通勤服务系统,包括:用户客户端100和服务器端200,在所述服务器端接收所述用户客户端上的出行需求,用以提供通勤路线的所述服务器端,包括:用户画像单元和规划单元,所述用户画像单元,用以根据所述出行需求建立用户画像,所述规划单元,用以按照用户画像规划通勤线路,还包括:服务商客户端300,用以制定营销策略并输入到所述用户画像单元中,将上述通勤线路在用户客户端进行响应。本领域技术人员能够明了,用户客户端100包括但不限于,pc、安卓、iphone、wp、ipad、mac等客户端。所述服务器端200被配置为,web服务器、应用程序服务器以及相应的后台数据库。在本实施例中的用户画像单元,作为一种勾画目标用户、联系用户诉求与设计方向的有效工具,作为实际用户的虚拟代表,用户画像所形成的用户角色并不是脱离产品和市场之外所构建出来的,形成的用户角色需要有代表性能代表产品的主要受众(通勤人员)和目标群体(与营销策略相关)。在本实施例中的规划单元,具体是指两点之间的路线规划过程。所述规划单元能够基于大数据运算,规划出的合理的、最优化的通勤线路。大数据运算无需预先进行数据建模,通过多维度的分析、数据透视、数据筛选等方式。

若在用户客户端身份验证成功,则通勤服务系统中所有通勤服务均为免费的,且通勤班车均是零排放、超静音、超舒适的绿色班车,比如电动班车、新能源班车等。从所述用户客户端提交的通勤需求均来自真实、有效的出行用户,并基于后台大数据运算,从而能够规划出的合理的、最优化的通勤线路,进一步有效的提升通勤班车的上座率、运转率。进一步地,所述用户画像单元中基于动态的、成长性的画像分析的通勤系统,载体为通勤班车,此外通过在服务商客户端制定营销策略,使得通勤班车上的产品与乘客关联度非常高,所以通勤服务系统中的服务商也能够获得可观的收益。

作为本实施例中的优选,系统还包括配置多个有用以灭火的消防设备和一用以验证用户身份的身份验证设备的通勤交通工具。

作为本实施例中的优选,所述规划单元的输入包括,目的地、当前位置,输出包括,最优路径,或多条备选路径。

作为本实施例中的优选,所述规划单元中采用dijkstra算法。采用dijkstra算法保证能找到一条从初始点到目标点的最短路径,只要所有的边都有一个非负的代价值。

作为本实施例中的优选,所述规划单元中采用bfs算法。最佳优先搜索(bfs)算法按照类似的流程运行,不同的是它能够评估(称为启发式的)任意结点到目标点的代价。与选择离初始结点最近的结点不同的是,它选择离目标最近的结点。bfs不能保证找到一条最短路径。然而,它比dijkstra算法快的多,因为它用了一个启发式函数(heuristic)快速地导向目标结点。

作为本实施例中的优选,所述规划单元中采用a*算法。

在一些实施例中,若地图api为网格地图,则在网格地图中,所述规划单元中采用标准的启发式函数是曼哈顿距离(manhattandistance)。

在一些实施例中,所述规划单元中采用欧几里得距离计算。

作为本实施例中的优选,所述用户画像单元,基于alencooper的“七步人物角色法”、lenenielsen的“十步人物角色法”等建立用户画像。具体在web服务器端,可以通过选择窗口的方式显示。

作为本实施例中的优选,所述用户画像单元包括但不限于:姓名、照片、个人信息、经济状况、工作信息、计算机互联网背景。

作为本实施例中的优选,所述用户画像单元包括但不限于:居住地、工作地点、公司、爱好、家庭生活、朋友圈、性格、个人语录等等。

在一些实施例中,消防设备部署在通勤交通工具内,提升通勤交通工具的安全性能。

在一些实施例中,身份验证设备包括但不限于,nfc识别设备。

在一些实施例中,身份验证设备包括但不限于,二维码识别设备。

在一些实施例中,身份验证设备包括但不限于,射频id识别设备。

在一些实施例中,身份验证设备包括但不限于,生物特征识别设备。

在一些实施例中,身份验证设备包括但不限于,蓝牙识别设备。

请参考图2是图1中的服务商客户端优选实施方式示意图,所述服务商客户端300包括:策略执行单元3001、产品营销单元3002,所述策略执行单元3001,用以根据用户画像匹配出对应的执行策略,所述产品营销单元3002,用以按照所述执行策略提供产品体验接口。所述策略执行单元3001,其中基于内容和用户画像的个性化推荐,有两个实体:内容和用户。需要有一个联系这两者的东西,即为标签。内容转换为标签即为内容特征化,用户则称为用户特征化。

所述产品营销单元3002执行时,至少包括:标签库、内容特征化、用户特征化、隐语义推荐。

在本实施例中的标签库,标签是联系用户与物品、内容以及物品、内容之间的纽带,也是反应用户兴趣的重要数据源。标签库的最终用途在于对用户进行行为、属性标记。标签库则是对标签进行聚合的系统,包括对标签的管理、更新等。一般来说,标签是以层级的形式组织的,可以有一级维度、二级维度等。标签的来源主要有:已有内容的标签、网络抓取流行标签、对运营的内容进行关键词提取。

在一些实施例中,对于内容的关键词提取,使用结巴分词+tfidf即可。

在一些实施例中,对于内容的关键词提取可以使用textrank来提取内容关键词。

在本实施例中的内容特征化,本实施例中的内容特征化即给内容打标签。目前有两种方式:

人工打标签和机器自动打标签,针对机器自动打标签,需要采取机器学习的相关算法来实现,即针对一系列给定的标签,给内容选取其中匹配度最高的几个标签。

在一些实施例中,可以采取使用分词+word2vec来实现。

在本实施例中的用户特征化,用户特征化即为用户打标签。通过用户的行为日志和一定的模型算法得到用户的每个标签的权重。

在一些实施例中,所述用户对内容的行为包括但不限于:点击、不敢兴趣、浏览。

在一些实施例中,对内容发生的行为可以认为对此内容所带的标签的行为用户的兴趣是时间衰减的,即离当前时间越远的兴趣比重越低。时间衰减函数使用1/[log(t)+1],t为事件发生的时间距离当前时间的大小,要考虑到热门内容会干预用户的标签,需要对热门内容进行降权。同时,可以使用click/pv来降低热门内容的权重。

在一些实施例中,所述隐语义推荐,即使用隐语义模型进行推荐。

用户对于某一个内容的兴趣度

其中i=1…n是内容具有的标签,mci指的内容c和标签i的关联度(目前都为1),nui指的是用户u的标签i的权重值,qc指的是内容c的质量,用点击率表示。

所述策略执行单元3001,包括但不限于对产品、价格、广告、渠道、促销及立地条件,是一种为了达成销售目的之各种手段的最适组合而非最佳组合。所述策略执行单元3001中的销售策略包括但不限于,网络获得、策略数据库、策略专家库等。

请参考图3是图1中用户客户端与服务器端交互方式示意图,作为本实施例中的优选,通过所述用户客户端100上的web浏览器向所述服务器端发出访问请求,所述服务器端200的web服务器查找对应页面并转交给所述服务器端的应用程序服务器,所述应用程序服务器定位并完成在所述页面的指令,并将完成的页面回传至web服务器,通过所述web服务器完成页面访问请求的响应,所述访问请求至少包括:出行类别、上/下车点以及对应上/下时间的访问窗口。当web服务器接收到对静态web页的请求时,服务器直接将该页发送到请求浏览器,而不进行进一步的处理。当web服务器接收到对动态页的请求时,它将作出不同的反应:它将该页传递给一个负责完成页面的特殊软件扩展。这个特殊软件叫做应用程序服务器。应用程序服务器读取页上的代码,并解释执行这些代码,然后将代码从页上删除。所得的结果将是一个静态的html页,应用程序服务器将该页传递回web服务器,然后web服务器将该页发送到请求浏览器。当该页到达时,浏览器得到的全部内容都是纯html。用户客户端100的web应用程序是一个包含多个页的web站点,这些页可能是静态的html网页,也可能是动态的网页(如:asp.net、jsp、php等),所有这些web页均存储在web服务器上,用户通过这些web页与网站进行交互,从而获得自己需要的各种信息和服务。web服务器会调用对应的应用程序服务器执行其中的程序代码,最后生成一个标准的html文件发回给客户端的浏览器。asp、asp.net、php、jsp都是面向web服务器的技术,客户端浏览器不需要任何附加的软件支持。

作为本实施例中的优选,请参考图4是图1中的服务器端优选实施方式示意图,所述服务器端200还包括:用户画像数据库和出行需求数据库,所述用户画像数据库,用以组织并储存从所述用户客户端提交的身份信息,所述出行需求数据库,用以组织并储存从所述用户客户端提交的需求信息。上述身份信息包括但不限于,姓名、年龄、家庭状况、收入、工作、用户场景/活动、喜好等。上述需求信息包括但不限于,出行类别、上/下车点以及对应上/下时间。

所述用户画像数据库还用以储存用户的标签内容,一个标签通常是人为规定特征标识,比如,年龄段标签:25~35岁,地域标签:北京。通过标签所呈现出的语义化,能很方便地理解每个标签含义。比如,判断用户偏好。

在一些实施例中,用户画像数据库用以储存,通过分析用户行为最终为每个用户打上标签以及该标签的权重即用户画像。通过所述标签表征了内容,比如用户对该内容有兴趣、偏好、需求等等。通过所述权重,表征了指数,用户的兴趣、偏好指数,也可能表征用户的需求度或者是置信度、概率。

作为本实施例中的优选,请参考图5是图1中的服务器端另一优选实施方式示意图,所述服务器端200还包括:预约单元2003,所述预约单元2003,用以将唯一验证信息推送至所述用户客户端,所述预约单元2003从所述所述规划单元中获取预约线路,并将所述唯一验证信息与所述预约线路绑定。

作为本实施例中的优选,请参考图6是图1中的用户客户端优选实施方式示意图,所述用户客户端100还用以提供:一第三方辅助单元1001,所述第三方辅助单元包括:提交反馈接口,用以提供对产品的是否有意向的反馈信息,下单购买接口,用以提供对意向产品的购买通道。通过所述第三方辅助单元,在用户客户端100能够对产品提供优化意见或者建立下单购买通道。

作为本实施例中的优选,请参考图7是图1中的服务商客户端另一优选实施方式示意图,所述服务商客户端300还包括:后台订单处理单元3003,用以根据所述购买通道中的意向产品,生成对应的订单,产品优化单元3004,用以根据提交反馈接口同步的信息,更换/去除产品,服务商供应单元3005,用以根据产品优化单元或后台订单处理单元,调整供应产品或接收后台订购需求。通过所述后台订单处理单元3003能够及时处理后台的订单,通过所述产品优化单元3004能够及时反馈产品反馈信息,通过所述服务商供应单元3005能够根据产品优化单元或后台订单处理单元的反馈信息,从而调整供应产品或接收后台订购需求。

图8是本发明一实施例中的方法流程示意图,用于通勤班车,具体包括如下步骤:

步骤s800接收出行需求和制定营销策略,

步骤s801根据所述出行需求和/或营销策略建立用户画像,组织并储存从所述用户客户端提交的身份信息、组织并储存从所述用户客户端提交的需求信息。

步骤s802按照所述用户画像规划通勤线路,通过将唯一验证信息推送至用户,并获取预约线路,并将所述唯一验证信息与所述预约线路绑定

步骤s803在所述通勤班车验证用户身份并判断是否提供免费通勤服务,以及是否提供产品体验服务。此外,还提供对产品的是否有意向的反馈信息、提供对意向产品的购买通道。

优选地,根据用户画像匹配出对应的执行策略,按照所述执行策略提供产品体验接口。

优选地,通过web浏览器向所述服务器端发出访问请求,web服务器查找对应页面并转交给所述服务器端的应用程序服务器,所述应用程序服务器定位并完成在所述页面的指令,并将完成的页面回传至web服务器,通过所述web服务器完成页面访问请求的响应,所述访问请求至少包括:出行类别、上/下车点以及对应上/下时间的访问窗口。

上述方法中还包括配置多个有用以灭火的消防设备和一用以验证用户身份的身份验证设备的通勤交通工具。

作为本实施例中的优选,如图9所示是图8中的优选实施方式流程示意图,还包括:

步骤s804用户通过智能终端注册并进行身份验证,同时提交出行需求,

步骤s805用户通过出行需求选择通勤班车,

步骤s806用户通过智能终端在上车时,验证身份,

步骤s807用户通过智能终端在下车前,提交产品反馈信息和/或购买需求。比如,根据所述购买通道中的意向产品,生成对应的订单、根据提交反馈接口同步的信息,更换/去除产品、用以根据产品优化单元或后台订单处理单元,调整供应产品或接收后台订购需求。

图10是本发明中具体流程示意图,s1用户通过在客户端完成应用程序的注册,完成真实身份验证,并提交出行需求,包括但不限于:出行类别、理想的上车点和下车点以及对应的时间;s2后台服务器在接收到大量用户出行需求后,基于大数据算法,规划出最优的通勤班车线路;s3后台服务器根据出行线路以及用户画像,为商家提供营销策略建议,与商家协商指定具体的产品营销策略,提供产品体验班车,并发布预约线路;s4用户通过终端登录应用程序并提前一日预约合理的绿色产品体验通勤班车,成功后获得乘坐班车的有效验证信息比如二维码;s5在出行当日,用户提前在指定的上车点等候通勤班车的到来,可以通过应用程序查看当前班车的位置以及预计到达上车点的时间;s6通勤班车到达指定上车点后,用户需要展示二维码,并需要通过通勤班车上的身份验证设备的验证,方可乘坐免费通勤班车;s7在通勤班车到达下车点前,用户可以体验产品,并可以提交反馈意见以及直接下单购买;s8当通勤班车达到下车点时,用户便可下车,对于该用户而言,即为一次有效的、免费的通勤服务。在本发明中的通勤服务,能够为用户提供免费的产品体验,首先需要注册以及完成真实身份验证,以及用户发布的出行需求,因而后台服务器可收集到大量的用户身份、行为数据,搭建动态的、可成长的画像分析系统,为每一个、每一趟通勤班车构建画像,基于此匹配精准的商家营销信息,提供有效的产品体验服务。

应当理解,本发明的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中,多个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。例如,如果用硬件来实现,和在另一实施方式中一样,可用本领域公知的下列技术中的任一项或他们的组合来实现:具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路,具有合适的组合逻辑门电路的专用集成电路,可编程门阵列(pga),现场可编程门阵列(fpga)等。

在本说明书的描述中,参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施例或示例中。在本说明书中,对上述术语的示意性表述不一定指的是相同的实施例或示例。而且,描述的具体特征、结构、材料或者特点可以在任何的一个或多个实施例或示例中以合适的方式结合。

总体而言,本公开的各种实施例可以以硬件或专用电路、软件、逻辑或其任意组合实施。一些方面可以以硬件实施,而其它一些方面可以以固件或软件实施,该固件或软件可以由控制器、微处理器或其它计算设备执行。虽然本公开的各种方面被示出和描述为框图、流程图或使用其它一些绘图表示,但是可以理解本文描述的框、设备、系统、技术或方法可以以非限制性的方式以硬件、软件、固件、专用电路或逻辑、通用硬件或控制器或其它计算设备或其一些组合实施。

此外,虽然操作以特定顺序描述,但是这不应被理解为要求这类操作以所示的顺序执行或是以顺序序列执行,或是要求所有所示的操作被执行以实现期望结果。在一些情形下,多任务或并行处理可以是有利的。类似地,虽然若干具体实现方式的细节在上面的讨论中被包含,但是这些不应被解释为对本公开的范围的任何限制,而是特征的描述仅是针对具体实施例。在分离的一些实施例中描述的某些特征也可以在单个实施例中组合地执行。相反对,在单个实施例中描述的各种特征也可以在多个实施例中分离地实施或是以任何合适的子组合的方式实施。

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1