ITPub博客

首页 > 大数据 > 数据分析 > 大数据在快狗打车中的应用与实践

大数据在快狗打车中的应用与实践

原创 数据分析 作者:胡孟依 时间:2018-11-20 14:14:44 0 删除 编辑

本文根据胡显波老师在2018年5月12日【第九届中国数据库技术大会(DTCC)】现场演讲内容整理而成。

讲师简介:

胡显波 :快狗打车IT总部高级技术经理,2014年加入58到家,负责快狗打车后端整体业务和架构工作,专注智慧物流以及智能派单领域的探索和创新,有丰富的业务架构和团队管理经验。

分享大纲:

一、业务与系统架构简介

二、大数据应用场景

三、总结

正文:

一、 业务与系统架构简介

上图是快狗打车的发展史, 2014年快狗打车服务上线,2015年10月份快狗打车的企业服务板块上线,2016年平台日订单突破20万,2017年与海外同城物流平台GOGOVAN达成合作,建立覆盖中国及东南亚地区的同城货运平台,现阶段已有超300驻点城市,百万注册司机,服务货运用户超亿次。

上图是我们的订单调度系统架构图、用户下完单后,进入订单推送系统,系统会根据大数据分析订单和用户信息,来判断是否需要对该订单用户给予优惠、对接收该订单司机进行补助,判断完毕进入订单调度系统,通过距离、接单时间等来匹配最优司机完成。系统中的司机订单队列引擎,根据司机的服务质量来进行业务分配,优先服务质量好的司机,以此来正向引导司机为用户提供高质量服务。

二、 大数据应用场景

在大数据没有出现之前,我们是如何进行数据分析的呢?初创公司一般是没有自己大数据服务的,写个SQL或脚本查询够可以满足需求。随着业务的快速增长,在原来技术基础上无法快速解决数据需求了,开始引入大数据平台,进行数据分析整理。通过AI来进行用户画像,分析用户和司机使用习惯,实现高效的订单推送。

数据来源有很多,首先是APP上的用户日志,然后微信、浏览器等H5日志,以及服务Server在计算过程中产生的数据通过日志,这些数据统一通过日志组件上传到日志中心,在需要数据时由大数据平台抓取并进行分析。数据库信息我们采用的是阿里DTS同步实时同步。

数据收集之后,该如何应用这些数据呢?在上图可以看到,我们收集了用户、司机、订单等多维度的信息,另外还有用户与司机关系的信息。

信息收集后会进行特征处理,归一化距离、分桶化订单价格来减少碎片化信息,例如:订单始发地与司机距离是500米、300米等,统一划分到1000米的范围,订单价格是40元、45元等,划分到价格50的区间内,另外还有订单始发地与目的地的信息,对它们进行整合,建立相应的交易模型。快狗打车现阶段拥有约400万模型在线上运用。为了保证模型的准确性,模型建立完后,会使用历史数据进行特征回归,测试模型是否符合预期目标,同时对特征性能进行分流测试,要确保运用新模型后订单相关指标不会受到影响。

上图是大数据在计价场景上的应用,首先用户下单,确定订单预估价格,我们的用户群体包含一些小B客户,对价格比较敏感,他想运货的话,他会去关注不同平台的价格,他认为我就愿意出这么多钱,哪个平台能给我找个司机,那就选择哪个平台。

从司机的角度来讲,假如司机接了这个订单,需要先开车去发货地,拿到货物后再运到订单目的地之后返程,在这个过程中他需要考虑在目的地有没有可能接到别的订单,考虑自己的时间、油费成本,再有用户运的一般是体积大或者重量较重的货物,司机可能需要帮忙搬运,司机也会考虑自己的人力成本。

在货运领域,北京来说业务范围一般都是在五环、六环甚至在郊区的地方,订单目的地如果是比较偏的地方,司机的返程是存在空驶可能的,这个时候平台需要根据订单的特征属性去判定是否给这个订单一定的补贴,助力订单的完成。

数据关于算法的赋能,上图中的X和Y的差值需要平台计算确定,求A和B的最小值以及对应的C值,这些依赖于大数据对订单历史数据的分析和大量计算。平台如何制定价格,可以使用户下单意愿更强,司机的接单率要更高,订单完成率更高。

在保证用户活跃度的情况下,如果用户定价过高,平台一般会给用户优惠或者针对于用户特征进行折扣,让用户感受到平台在关注他,增加用户与平台的粘性。

在2015年,快狗打车拿到第一笔融资后,定下打补贴战的策略,平台初期给用户的优惠大概是每单15~20元,给司机的补贴是20~30元。每单的补贴可能在35块钱左右。按这个策略当时一天能砸出去上百万、一个月几千万,补贴持续了2到3个月,耗费的资金很多,但效果也十分显著,当时同领域的竞争对手基本都销声匿迹了。

到2016年,业务持续增长,公司考虑是否把补贴砍掉,但砍掉之后用户是否会离开、会不会转到竞争对手或者转为黑车。这个论题需要我们逐步去实验,如何在补贴减少过程中,对业务的影响最小。

首先在历史特征数据基础上建立模型,不断进行线上实验,在试点城市进行分流测试,对价值比较高的订单不给补贴,通过分配订单减少差单的补贴。司机加入平台是为了收入,司机一天拉黑车的收入大概在200元,如果平台可以保证司机每天收入在200元~300元,司机是愿意在没有补贴的情况下接单的 。

上图是补贴制定的流程,如果订单一直处于没有司机接单的状态,证明这个订单可能属于差单,有可能订单目的地太过偏远,运输的货物台中,路程耗费时间久,但如果我们能用补贴促使这个订单完成,这样补贴才是真正起到了作用。

一般用户下完订单后,平台会根据历史数据去预测抢单司机的数量:分析订单的相似历史发单,在这个地点或者附近,哪些司机接了哪些订单?哪些没接?为什么没接?去预估这个订单下单后有多少个司机接单。如果预计接单司机有两个以上,平台就不会进行补贴,如果接单人数少,就会给接这个订单的司机发放一定的补贴,促使这个订单的完成。

上图是优惠模型的流程,互联网用户的活跃是存在周期的,从用户的加入期开始,逐步进入成熟期,之后是衰减期,最终会出现流失的现象。如果平台想要留住用户就需要进行干预,在用户的热度流失时,平台及时给用户优惠,比如发放优惠券或者推行下单有折扣等活动,用户持续的保留在平台上的概率会提升。

上图是订单推送的流程,在下完订单后,平台将订单以一定的算法规则推给附近的司机,,并不是司机的距离近就先收到订单,平台会进行择优选取,比如:3公里以内有100个司机,平台会根据这100个司机历史订单完成概率、司机服务水平还有司机是否去过目的地等进行排序,排完序后进行订单推送,提升订单的匹配效率,同时降低订单用户等待时间。

上图是接单意愿的排序,通过订单和司机的距离、订单预估价格、小费补贴、起点终点等这些具体的数据进行大规模的数据回归,计算出来每一个司机的接单意愿,制定推送顺序。

上图是中单场景的应用,比如说订单推送给了50个司机,可能有10个司机都有接单的意愿,这个时候平台会选取一个最有可能完成这个订单的司机来接单,提升订单完成率。此外还有司机车型对订单的匹配度,如果用户运的是家居,那对车型的要求包括车后座是否拆除、车内空间是否足够都有需要求,如果司机的车不符,用户就会取消订单,降低了订单的完成率,影响用户满意度。

上图是我们对不同时期用户的定义,不同时期的用户采取不同的运营措施来提高用户与平台的粘性。1)留存期是用户存在下单行为,但最后一单距当前时间小于1.5乘以用户单均下单周期。2)沉睡期是超过平常下单周期而没有下单行为的用户。3)流失期的用户可能一段时期没有下单记录,但依旧有用车需求,不过可能转到了线下或者其他平台。面对不通阶段的用户,我们其会采用优惠活动、发放优惠券、发短信、广告的形式来去激活这部分用户。

还有一个是反作弊的判定,大数据在平台上运用的一部分是进行算法相关规则的计算,另一部分是收集用户和司机的信息进行作弊的判定。为防止作弊行为平台需要进行实时监测,首先会在大数据中根据用户下单的设备、订单数、历史下单行为,去判定是不是虚假设备或者恶意下单,同时会根据接单司机的运行轨迹等信息去统一判断是否有作弊行为、是否对司机或用户进行相关惩处。

上图是大数据提取的完整订单模型,用户下完单后,判定用户所在商圈,判断订单所在商圈运作力是否充足,这个订单所在商圈的价格是否能满足司机需求,如果不相符就触发调价策略,尤其在假期时商家要备货,运货需求比较高,有可能出现司机短缺状态,平台会进行调价或者通知其他区域司机。

接下来是系统预测司机接单意愿,确定推送司机范围,司机端进行抢单,在抢单过程中动态调整司机补贴,第四步预测订单完成概率,选择哪个司机接单更容易将订单完成,最后订单完成后,启动用户留存模型,预测用户是否会流失,基于预测结果来确定优惠的发放。

上图是业务监控的具体分布,首先技术上的业务监控,比如在推单时,如果附近司机的数量和往常司机数量产生比较大的波动,比如原来3公里内有50个司机,但今天只有10个司机,第一点需要排查是否系统存在问题?第二点需要和城市侧沟通司机侧是否出现什么变动,这些变动都需要实时的进行报警。

另外一个是订单的推单波动,比如一个订单推送时推送50个司机就会有司机接单,今天可能推了100个司机依旧没有司机接单,在推送过程中有可能出现了异常,有没有可能需要进行业务测试。还有优惠波动,优惠单数是否有较大的波动,补贴单数是否和往常不同,是否存在异动,该如何解决,这些都是需要实时监控来发现。

最后一个是算法方面的具体措施,比如平台更新一些新算法,我们需要监测算法在线上实际运行的效果,刚开始肯定不能进行全国更新,现在大数据的分析,基本上是一天一分析,如果线上出现了问题,影响是比较严重的,所以我们会进行实时储备,实时数据上报。对新算法的实验,采取线上用户的分流,比如用户采用的是哪一种算法,在这种算法下有没有下单,订单有没有完成,针对这种算法,我们会去做分流和监测,通过监测产生业务报表,如果这个新算法在业务上出现规模较大的影响,系统会自动关闭这种算法,不再进行分流。

三、 总结

最后一句话总结: 一切脱离业务的大数据应用都是耍流氓 ,希望大家注重业务与数据的结合,不要脱离实际运用场景。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/31545816/viewspace-2220725/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2018-07-12

  • 博文量
    47
  • 访问量
    76086