从数据到产品——爱飞狗背后的故事

这篇文章基于最近整理的一份演讲的Slide,由于报名太晚错过了截止日期,所以只好写成文章,一起来看看爱飞狗背后的一些故事。

几年前我和家人会经常往返于成都和广州两个城市,从平时的观察中可以看到机票价格从400人民币到全价接近1500人民币,机票产生的波动有时候会高达100元以上,如果没有看好时间,一家人出行就会增加几百元的成本。

买机票的时候,我应该和大家差不多,会在买机票前进行一番观察。主要是观察未来几天起飞的机票价格,用来选择哪天出行。然后手工记录一下近期的价格变化,看看是不是在涨价还是跌价中。当然这个纯属体力活也容易错过最佳购票时期。我当时在想,如果我能知道去年的机票的价格和变化趋势,或许可以用来预测今年的价格的波动和判断是否需要购买机票。

我提出了两个问题,近期的价格的趋势是什么?决定好起飞时间后,我应该提前多少天购票?

我查了一下目前我们有的一些服务和APP,看是不是有人已经做过了类似的事情。

  • Farecast是最早做机票预测服务的一家公司,后来被微软收购后并入了Bing,此后Google收购了Farecast所依赖的数据源后,Bing的这项业务也停止了,所以现在Farecast已经关闭,无法使用。
  • Kaya这家网站提供了机票的近期价格曲线以及购票建议,十分切合我的需要,但遗憾的是中国的数据源非常少,几乎没有可参考性。
  • Hopper也是最近两三年比较好的一款App,提供了出行的建议以及是否购票的提示。但Hopper不会提供去年的曲线图,也没有近期的票价情况,一切看你是否相信它的AI预测了。和Kaya类似,这个App也没有中国区域足够的数据,没有什么参考价值。

面对这样的情况,作为一个程序员,我觉得是时候出手了。

由于我没有运营机票代理业务,所以无法获得机票信息的一手资源。对于我来讲唯一能够获取到数据的方式就是采用爬虫,通过模拟人工的搜索来获得票价信息,存储到数据库中。

为了分析一整年的数据,我在给自己定了一些目标:

  • 至少要连续采集1年的数据
  • 更新频率大概在1小时左右
  • 低成本
  • 容忍爬虫或者数据源的失败

根据这些目标结合当时的情况,我将这个任务分解成了以下几个部分:

  • 机票采集的范围:中国范围内2800个航线的直飞的价格数据
  • 采集的数据:每条航线起飞前45天的票价信息
  • 数据源:4个数据源做互补,一来是为了检查数据的准确性,二来是为了防止数据源失效
  • 全年无休连续爬取

在数据爬虫的架构上,我需要一个低成本的方案,毕竟要干上一年以上的时间(其实到现在已经2年多了)。我并没有使用各种爬虫的框架,而是自己写了一个轻量级的爬虫来处理代理的筛选逻辑和爬取数据的验证。这些爬虫将会运行在DigitalOcean或者Linode的$5的服务器上,这些服务器上只有1个CPU和1G的内存。自定义的爬虫能够尽可能的根据性能进行针对性的调优,从而增加性能。每个爬虫之间互相独立,部署在单独的机器上,也是为了减少爬虫之间的相互干扰。

在存储上我是用了tar.xz的文件将所有的爬取到的原始文件按照每一轮爬取进行打包压缩,然后在本地里面的一台PC机负责将所有的数据拉回来,放到一个4T的硬盘上。同时这些数据也会存储到百度云上面进行备份。目前这些压缩包已经达到2T左右了,解压下来大约有20T的数据量,大约有380亿条数据。

在数据处理上,首先是实时数据流的处理。使用了kafka来进行队列管理,一个Parser来进行实时的处理原始数据,将处理好的结果放到redis缓存中,供小程序的后端使用。

在数据的分析上,我使用Java手写了一个高性能的ETL,直接读取压缩包然后进行数据解析。在这里也是使用了轻量的原则,没有使用更多框架,从而达到非常高的性能。

在PC机上也使用了Postgres中进行数据存储,每一天的数据存储到一个表中。

在近两年的时间中我积累了以下一些经验:

  • 在长时间的爬取中证明了简单的爬虫的可变性非常好,在针对特殊场景调优的时候非常有针对性。
  • 存储原始文本也为了应对数据结构的变化,当数据结构变化后,本地的Parser失败以后,可以重复的调用之前的数据,从而保证数据不丢失。
  • 多个数据源进行备份的设计非常好。目前依然有两个数据源在持续爬取。针对两个数据源我也可以进行数据的对比,发现数据对比后数据较为相似,说明没有爬取到脏数据。

拿到这些数据后,就要开始数据分析了。

分析的结论在我的简书的前几篇文章中都有提到。这里不再赘述,请参看:
https://www.jianshu.com/p/3b22fb101189
https://www.jianshu.com/p/366e839af3ea

在分析完这些数据后,我们再回头看一下最初问题的定义:针对某一条航线,给定历史价格和近期的价格,现在看到当前的价格是P和距离起飞还有N天,我们应该是买还是等待?

我使用了以下一些算法来分析,包括决策树、支持向量机、Q-learning和神经网络。

在准备数据时,提取了以下一些基本特征,当然针对不同的算法还是用不同的特征。

在数据的分割上,考虑到这个是时间序列相关的数据,将数据集分为1年的训练数据,2个月的测试数据和2个月的验证数据集。当然实际数据比这个多,可以尝试更多的组合。

但这些算法算出来的结果还并不令人特别满意,达到的准确率也只能超过人工根据一些简单的规则推导出来的准确率,可能和我所用的数据训练方式有关。所以在线上计算的时候,我目前还是采用专家系统的做法,将数据分析的结果整理成规则,根据这些规则还是能够得到较高的预测准确率,其他的指标例如Recall等可能会比较差。

那么为什么专家系统能够行得通呢?我从一些内部人士了解到,原因在于这些机票都是来源于中航信,而这个系统比较老旧,针对价格的调整也不够灵活,大多数都是给予一些人工的规则来进行。收益管理员基本上都是从这里学到一些规则然后进行调价,所以学到的规则其实比较相近,所以会产生大家都有差不多一样的规则。

有了数据之后,想到可以来造福大众,便产生了做一个小产品的想法。

这时候正直小程序比较火的年代,小程序比较简单,而且受益于微信的用户群可以很方便的进行推广。所以设计了几个简单的功能,能够选择出发、到达和起飞日期,然后会显示出实时的价格和历史最低的价格,点进去后可以看到预测、近期的价格波动和去年的价格波动。这能够更好的指导大家进行机票的选择。

下面来看看产品背后的架构:

  • 前端当然是用微信提供的一套进行开发,这个和其他的小程序没有什么两样。
  • 后端使用Flask进行开发,简单快捷。
  • 数据提供方面有之前提到的实时数据的显示,来自Redis缓存,当然还有离线历史数据数据。这些数据每天从离线的PC机上同步到云端,然后由API进行展示。
  • 还有用户行为数据的存储及分析。这些数据都存在ElasticSearch服务器中以便进行快速的搜索,借助Kibana可以对用户行为进行在线的分析,非常的方便。当然还有一些和用户相关的需要实时更新的数据(例如session值和飞币的信息)也放在EleasticSearch中,主要是利用了NoSQL数据库没有Schema的特点,增加数据使用的灵活性。
  • 基础设施方面小程序相关的部分全部在阿里云的服务器上。所有的服务都使用Kubernetes进行管理,Rancher进行可视化管理,爬虫等服务放在DigitalOcean一遍节约成本。

小程序也发布了9个多月了,目前积累了大约4.3万的用户,数量还相对较少,这个小程序的未来如何考虑呢?

首先是继续将机器学习应用到价格的预测,毕竟积累了2年的多的数据是一笔不小的财富。
然后是提供更好用的界面提升用户的使用满意度。
最后就是找到一套可行的商业模式进行变现。目前小程序还只能依靠广告有一点收益,完全是入不敷出的情况。

如果您对这个小程序感兴趣,请试试微信搜索“爱飞狗旅行”和关注微信公众号“爱飞狗”,或者扫一扫下面的二维码。您的支持将是我进步的最大的动力。

小心!我正在偷窥你的运营

首先,问一个很简单的问题考考你——在上海,摩拜单车出行的高峰时段是什么?这个问题相对比较容易回答,根据普通人上下班的时段应该是早上七八点左右,下午六七点左右。恭喜,你答对了。

现在问一个稍微更难一点的问题:在上海,摩拜单车使用次数的分布是什么情况?对于我而言,基本上每天就从地铁站骑到公司,然后下班从地铁站骑回公司,就算做是两次吧,通常这部分人应该不少。而这道题问的是分布,那么得知道0次骑行的车的数量,骑行一次、两次、n次的车的数量。我们可以做个小范围的采样,在单车密集的区域架设几个摄像机,然后分析一下哪些车没有被骑走即可。但是,骑行两次、三次以及更多次数的车的数量如何得知呢?我们很难知道,或许我们可以通过发放调查问卷来得知,但如果样本太少会得到打的偏差。同样的道理,回答“摩拜单车的骑行距离的分布式什么情况”,也相对较难。

要知道共享单车的运营情况,我们通常只能通过官方或者研究机构的各种报告来获取到。然而这些报告可能缺少一些时效性,对某些研究来讲并不能产生任何作用:例如在城市规划时研究OD线、叠加图层分析更多因素的结合时,就显得无能为力。最后的渠道也是最正规的渠道是通过和共享单车企业合作,然而由于涉及到商业机密,通常很难获得。

OD线(Origin-Destination Line),是指连接“起点”(origin)和“终点”(destination)的线,通常用于在地图上直观表示某两个地理位置之间的联系,如车辆的行驶轨迹、飞机的航线和人口的迁徙等。

回到单车的APP上来,既然能够帮我们显示出车辆的信息,那么我们能不能把一个区域的范围的车的信息都抓取下来,然后进行分析呢?这个思路非常的有趣,在我之前写的摩拜单车爬虫解析——找到API 中已经有所涉及。在这里我们不谈技术细节,通过对爬取的上海市2018年5月29日星期二(晴天)的数据进行分析我们迅速地得出上面问题的答案:

  • 单车的分布图和部分热力图。可以明显的看到上海城市的发展规模以及人口密集区域的分布。

单车分布图

单车热力图

  • 单车使用次数类似一个正则分布,2次的次数最多,符合人们的直觉。
    使用次数直方图

  • 骑行的直线距离分布在2千米之类,以1千米范围为最多,这通常也是单车解决“最后一公里”问题的证据。
    骑行距离分布

  • 出行的时段的分布在早上7点左右达到高峰,然后晚上7点左右达到高峰,这和人们的出行习惯是密切相符的。有趣的是夜间22点以后到第二天凌晨5点左右,也有单车在移动,但这时候骑行的人相对很少,所以这些单车的移动很有可能是摩拜单车的运营人员在批量的挪单车。如果将这些数据加以分析应该可以知道这些车从哪里挪到哪里,进而更深层的分析单车企业的运营策略。

骑行时段分布

同样的道理,让我们来看看共享汽车的运营情况。我们抓取了去年GoFun从10月到1月的数据,得出了以下一些运营状况的分析:

  • GoFun绝大多数车型都是奇瑞的车。两座和四座的车是主流,车身小巧一方面比较节能,另一方面比较容易操作。这主要是因为奇瑞投资了GoFun。

车辆信息

  • 截止2018年1月26日,GoFun目前在全国总共有10327辆车。下图是车辆增长的情况。可见运营一直在持续,并且缓慢增长。

增长

  • 三个月内车的使用次数的分布。横坐标是使用的次数,纵坐标是次数对应的车的数量。近似一个正态分布,大约70%的车都在24到72的区间。平均起来每天0.3次到1次左右,这对于共享汽车企业来讲并不是一个好事,太低的使用率可能会导致入不敷出。

image

  • 使用时长的分布。横坐标代表停车的时长(小时)最长统计到70小时,纵坐标代表有多少车次。对比停车时长的分布,使用时长的分布比较明显的集中在0到6小时之间,这也是共享出行的特点。由于GoFun有包天的租车服务,所以长期的出行的费用也是可以接受,长达70小时以上的使用时间也有1700多车次。

image

由于篇幅所限,更多的分析结果可以参见大数据看共享汽车一文。

保护我们的数据

以共享单车为例,当我们手工的小范围的采集数据时,并不能产生很大的作用,当我们收集到的数据越来越多时,甚至通过自动化爬虫这种手段获取到足够多的数据以后,大数据就开始展现量变到质变的过程。共享单车、共享汽车的案例中,虽然我们没有得到订单的数据、没有用户信息,但通过对海量数据分析、结合多种维度,我们依然可以窥探企业的运营。我在2017自由职业大数据分析一文中爬取到Freelancer网站的所有公开信息并进行了自由职业的分析;在机票大数据分析,揭示购票的秘密 中,通过一年多的机票价格数据采集得到多个机票购票的建议。所有的数据都来自于公开的API,而主要的获取方式则是爬虫。

网络爬虫(又被称为网页蜘蛛,网络机器人,在FOAF社区中间,更经常的称为网页追逐者),是一种按照一定的规则,自动地抓取万维网信息的程序或者脚本。另外一些不常使用的名字还有蚂蚁、自动索引、模拟程序或者蠕虫。

爬虫获取信息的方式可以通过爬取页面,也可以通过分析APP的请求来得到API。所以一切返回数据的地方都是可以通过一些手段获取到,而主要的区别在于获取数据的难度的大小,这也通常是爬虫和反爬虫的较量之一。当爬虫的成本高到一定水平以后,反爬虫就胜利了。

通常来讲,反爬虫的手段无外乎对IP限制、验证码、要求登录等,可以参考关于反爬虫,看这一篇就够了一文。固然这些方式都可以较好的保护应用,但会给适用方带来不便,除此之前我们可以考虑一些建议来减小数据被大规模爬取的可能,增加爬虫的成本:

从业务上进行考虑,不需要客户感知的数据不提供或者少提供

以单车应用来看,ofo单车并没有提供摩拜单车的预定的功能,所以在界面上也没有必要展示出单车的编号信息。在去年9月份左右,ofo单车对API进行了调整,将所有的单车编号进行随机化处理,导致ofo单车的数据目前无法爬取。哈罗单车在未登陆的情况下只提供几台单车的数据,登陆后能够展示附近所有的单车。由于需要登录,爬虫的成本会变得很高也非常的脆弱。
反观某大型旅游OTA网站的API,调用后返回了相当数量的额外信息,甚至在价格方面包含了两种价格,而其中一种价格并不会在界面上进行显示,这种信息非常值得怀疑是不是内部的价格。

盘点所有的API的使用方,谨慎一切以JavsScript开发的客户端

目前手机APP层面的保护措施已经相对较多,而且大多数应用受到加密外壳的保护很难破解,想得到URL里面的签名信息的生成方式变得非常困难。然而仔细盘点一款产品的各种渠道,会发现有些产品可能会提供HTML5、公众号、小程序等入口,而这些以JavsScript生态圈的应用并未收到很好的保护。
以某款快递软件为例,该查询软件中提供了sign信息,基本无法知道如何生成,但在小程序中调用了类似的API并带上了sign信息,通过一个Root的安卓手机可以将小程序解包,分析JavaScript很容易的发现了sign的生成方式。另外某单车软件登陆的签名信息eption也是经过了加密处理,在小程序中也能够发现其生成的方式,马奇诺防线就这样轻松的被越过了。
当然小程序端的防止爬取的方式比较简单,小程序的后端可以通过微信的接口生成动态的token的方式进行用户验证,防止数据泄露。

做好后台的监控

道高一尺魔高一丈,后台API调用的日志和监控手段要重视。对于异常数量的API调用要及时分析出原因减少被利用的可能。

大数据看共享汽车——EVCard篇

去年2月份我做过共享单车的数据分析,也分析出一些有意思的点。从2017年10月1日开始,历时3个多月,我收集了EVCard和GoFun共享汽车的公开数据。下面整理成一个动态的报告,一起看一下共享汽车的现状。

注:该数据分析及报告仅代表个人意见,仅供参考,数据来自于API请求的结果,只包含公开的信息,不涉及用户信息。引用、使用该报告引起的任何后果(包括但不限于版权、侵犯法律法规)等,由使用方承担。

基本信息

EVCARD品牌是上海国际汽车城新能源汽车运营服务有限公司开展的电动汽车分时租赁项目。 EVCARD电动汽车分时租赁是借助物联网技术实现的一种新型汽车分时租赁服务模式,实现了用户任意时间自行预订,任意网点自助取还的用车需求。 上海国际汽车城 新能源汽车运营服务有限公司是上海市第一家面向新能源汽车开展租赁和共享的专业公司,主要开展面向集团用户(B2B、B2B2C模式)以及私人用户(B2C)的新能源汽车长短租服务

我们先来看一些关于车的基本的信息。

从上面图可以知道,EVCard的车品牌比较多,其中还是北汽、奇瑞、江淮的低端车型比较多,中端的较大的车型荣威E50也占据了11.03%的分量。高端的宝马i3也有,但极少。虽然EVCard官网上面虽然列出了车型,但可能更新较慢和数据中的车型不一致。

业务概况

根据采集的数据,截止2017年11月底,EVCard目前在全国总共有12152辆车。下图是车辆增长的情况。整体趋势来讲呈平稳上升趋势,说明目前发展状况稳定。

我们再来看看车辆的数量分布。可以看出来在上海以及附近的省份有很多的车辆,和GoFun正好是相反。

由于EVCard必须在指定地点借还,停车场的数量多少就直接影响到用户体验。随着车的增长,停车场的数量也应该有相应的增长才对,从图里面也看出停车场的增长较为平稳。截止2017年11月底,全国总共有5540个停车场,远超GoFun的2887个停车场。

在停车场各省的分布情况中,几乎是和车辆的分布接近。

我们再来看一下多少汽车共用一个停车场的情况。从图上看出,平均来看大致一个停车场目前有2辆车的规模。如果一个停车场容纳的车越多,那么用户能够拿到车的几率越大,从这方面看也是一个好事。如果停车场的数量较少,网点不密集,就会影响用户的到达性。从这张图可以看到出有几个省的比例到了4到5,分析看来是由于这些省份的停车场数量偏少。你可以在”停车场分布”图中,具体看看停车点的分布。

停车场分布

下图是停车场的分布图,图上标记了全国的停车场的位置,可以自由浏览。上海作为EVCard的大本营,有非常丰富的网点,可想上海的用户出行是非常的方便的。

image.png

车辆流转情况

下图是三个月内车的使用次数的分布。横坐标是使用的次数,纵坐标是次数对应的车的数量。0到70次占据了相当多的数量,然而130到170次之间也有一个小的起伏。平均下来有每天0.5到2次的使用频率还是不错了。

但使用次数只是运营情况的一种体现。如果每次使用时间比较短,停车时间比较长,对EVCard也不是一个好事。下图展示了停车时长的分布。横坐标代表停车的时长(小时)最长统计到70小时,纵坐标代表有多少车次。从图上看由于使用的频率比较高,停留时间集中在较短的一端比较多。

下图展示了使用时长的分布。横坐标代表停车的时长(小时)最长统计到70小时,纵坐标代表有多少车次。对比停车时长的分布,使用时长的分布比较明显的集中在0到6小时之间,这也是共享出行的特点。由于EVCard有包天的租车服务,所以长期的出行的费用也是可以接受,长达70小时以上的使用时间也有1300多车次。

车的轨迹

下面这个动画展示了一辆车的直线运动的轨迹。由于我们仅能得到出发、到达地无法获得中间的轨迹,所以只能这样按照直线标注。图上展示最近几个点,以及位置迁移情况。

电池电量

下面这张图展示某一辆车的电池变化情况,其中深色区域代表该车在停车场内没有被使用。

总结

根据以上的分析,EVCard目前比较集中上海附近的省份,尤其是在上海集中优势的力量建立非常密集的网点,对于用户的使用无疑是一个好事。长期来看,停车场和车在稳步的发展,从小型车到大型车的车型的多样化,也为用户的不同出行带来了方便。。

附件

互动网站:http://www.april1985.com/sharecar_report/evcard/report/index.html
源代码:http://www.april1985.com/sharecar_report/

大数据看共享汽车——GoFun篇

去年2月份我做过共享单车的数据分析,也分析出一些有意思的点。从2017年10月1日开始,历时3个多月,我收集了GoFun和EVCard共享汽车的公开数据。下面整理成一个互动的报告(文后有链接及代码),一起看一下共享汽车的现状。

声明:该数据分析及报告仅代表个人意见,仅供参考,数据来自于API请求的结果,只包含公开的信息,不涉及用户信息。
引用、使用该报告引起的任何后果(包括但不限于版权、侵犯法律法规)等,由使用方承担。
未经许可禁止转载

基本信息

GoFun出行是首汽集团针对移动出行推出的一款新能源共享汽车产品,秉承首汽集团作为全国最大出行服务运营企业的多年经验和优势资源,响应政府号召,把握“新能源+车联网”的全趋势,致力于整合用户碎片化的用车需求,提供便捷、绿色、快速、经济的出行服务。 GoFun出行是共享行业新兴的一种租车模式,车辆无人值守,用车全程App操作,以“分钟+公里”计算并提供汽车的即取即用、分时租赁服务,消费者可按个人用车需求预订车辆。GoFun出行已相继完成全国20余个城市的布局,其中不乏北京、上海、武汉、成都、南京等一、二线城市,更有西安、青岛、昆明、桂林、三亚等重要旅游地。

我们先来看一些关于车的基本的信息。

从上面几幅图可以知道,GoFun绝大多数车型都是奇瑞的车。两座和四座的车是主流,车身小巧一方面比较节能,另一方面比较容易操作。


为什么是奇瑞的车占据绝大部分份额呢?从网络搜索到两条新闻可以知道奇瑞是GoFun的合作伙伴,这也不足为奇了:

#业务概况

根据采集的数据,截止2018年1月26日,GoFun目前在全国总共有10327辆车。下图是车辆增长的情况。注意,车辆数量有时候会变少,这是因为数据采集时只能采集到没在使用的汽车,所以会少一些。整体趋势来讲呈平稳上升趋势,说明目前发展状况稳定。

我们再来看看车辆的数量分布。可以看出来在四川、广东、陕西、福建等省有很多的车辆,属于比较正常的情况。比较奇怪的是上海的车辆数量很少,我猜测在上海早已有竞争对手占据了市场,还不如避而求其次。

由于GoFun必须在指定地点借还,停车场的数量多少就直接影响到用户体验。随着车的增长,停车场的数量也应该有相应的增长才对,从图里面也看出停车场的增长较为平稳。截止2018年1月26日,全国总共有2887个停车场。

在停车场各省的分布情况中,几乎是和车辆的分布接近。

我们再来看一下多少汽车共用一个停车场的情况。从图上看出,平均来看大致一个停车场目前有3辆车的规模。如果一个停车场容纳的车越多,那么用户能够拿到车的几率越大,从这方面看也是一个好事。如果停车场的数量较少,网点不密集,就会影响用户的到达性。从这张图可以看到出湖北省的比例最高,从之前的车辆数量排名看湖北省排名第5,但停车场数量排名第10,停车场数量偏少。你可以在”停车场分布”图中,具体看看武汉市的网站分布。

停车场分布

下图是停车场的分布图,图上标记了全国的停车场的位置,可以自由浏览。以成都市为例,作为西部重点城市,共享汽车的发展和共享单车一样的迅猛。目前GoFun的覆盖面还是比较广,主要集中在人口密集的三环境内、南边的高新区。在西边的郫都区和东边的工业区龙泉也有所分布。但从图中可以看出显然北边和东北方向都没有太多的分布,这也和城市的发展密切相关。在西边的旅游城市都江堰,GoFun也有大量的网点,这也给出行的人带来了丰富的选择。

车辆流转情况

下图是三个月内车的使用次数的分布。横坐标是使用的次数,纵坐标是次数对应的车的数量。近似一个正态分布,大约70%的车都在24到72的区间。平均起来每天0.3次到1次左右。

但使用次数只是运营情况的一种体现。如果每次使用时间比较短,停车时间比较长,对GoFun也不是一个好事。下图展示了停车时长的分布。横坐标代表停车的时长(小时)最长统计到70小时,纵坐标代表有多少车次。从图上峰值是在0到2小时之间。也有连续70小时,也有1000多车次有过这样长的停车时间。

下图展示了使用时长的分布。横坐标代表停车的时长(小时)最长统计到70小时,纵坐标代表有多少车次。对比停车时长的分布,使用时长的分布比较明显的集中在0到6小时之间,这也是共享出行的特点。由于GoFun有包天的租车服务,所以长期的出行的费用也是可以接受,长达70小时以上的使用时间也有1700多车次。

车的轨迹

下面这个动画展示了一辆车的直线运动的轨迹。由于我们仅能得到出发、到达地无法获得中间的轨迹,所以只能这样按照直线标注。图上展示最近几个点,以及位置迁移情况。

#电池电量

下面这张图展示某一辆车的电池变化情况,其中深色区域代表该车在停车场内没有被使用。

#总结

根据以上的分析,GoFun目前的发展势头还是稳步增长。在路上我们也越来越多的看到共享汽车的身影。以成都为例,当停车场数量、车的数量越来越多以后,出行的局限性会变的更少,相信会俘获更多的用户。

#附件
互动报告:http://www.april1985.com/sharecar_report/report/index.html
报告源代码:https://github.com/derekhe/sharecar_report

我为什么要开发这款小程序?

2012年由于家庭的原因,我经常乘飞机往返于成都和广州。每次买机票前我都要观察一段机票的价格,然后再进行购买,但具体什么时候买很多时候都是靠拍脑袋。在买多几次机票后,我发现机票的价格变化还是有一定的规律可行。后来有一本叫做《大数据时代》的书提到了国外的一个Farecast产品,能够预测7天内的票价变化,给出买还是不买的建议。但很遗憾的是多年来国内一直没有相关的产品,这便触发了我做一款类似产品的想法。

这款产品叫做“爱飞狗旅行”(简称爱飞狗),这个名字来源于英文“aiflygo”。其中的AI也有人工智能的意思。产品的核心价值在于尽最大可能回答“什么时候买机票便宜”。买机票分为两个阶段,第一个阶段是选去哪里、什么时候去, 携程、去哪儿等旅游网站已经解决了这个问题。第二阶段是什么时候买票,各大网站也提供了低价提醒等功能,帮用户预定到更便宜的票。但这些产品的并没有告诉用户最低价位是什么,从而用户很难判断是否应该能够购买,除非多观察几天,但很有可能会错过最佳购票时间。

为了弥补最后的一环,这款产品首先要解决的问题的是当选定到达地点、出发日期和航班的前提下,什么时候买票最便宜。为免用户出现不会使用的情况,产品设计上我并没有标新立异,而是使用了传统的选择机票的流程。在用户选定了起降地点、时间,根据实时价格选定航班之后,传统的购票流程会显示订票的页面,而“爱飞狗”将会展示关于机票的一些购票提示。

首先展示的是运用人工智结合大数据预测出的购买建议。购票建议通过历史数据和近期价格波动综合考虑出一个结果,给予用户最快的提示。

然后是去年同期的最低价格。根据数据分析和航司的专业人士的告知,航空公司的价格定价会根据很大程度上根据去年价格,参考今年的运力波动进行定价。所以历史最低价位具有非常大的参考价值。同时,“爱飞狗”也给出最低票价出现的时间,方便用户决定今年什么时候买。在春节期间更是可以自动切换对齐到农历日期,这样更方便传统节日购票。

最后,“爱飞狗”会展示出该航班近期的购票价格的波动。注意这个价格并不是很多OTA上面展示的未来的价格,而是某一天起飞航班的历史购票价格。例如12月28日起飞的ZH9441航班,将会展示起飞前45天到今天的购票价格。

综合上述信息,用户可以根据波动情况决定是否购买。

在小程序还在开发的时候,我通过数据分析购买到了去广州的最便宜的票,一家人节约了400多元。小程序上线后不久,有朋友通过“爱飞狗”公众号告诉我他一家人出游选好了购票时间节约了600多元,也是对小程序的极大的肯定。

在未来,爱飞狗会继续优化用户体验和提高AI预测的准确性。由于产品目前还是个人开发,产品的更多的是靠口碑进行传播,由于个人力量所限,希望有志同道合的朋友能够一起将该产品做到更好,使得更多人受益。