共享单车数据分析范文文档格式.docx
- 文档编号:18508574
- 上传时间:2022-12-18
- 格式:DOCX
- 页数:12
- 大小:26.91KB
共享单车数据分析范文文档格式.docx
《共享单车数据分析范文文档格式.docx》由会员分享,可在线阅读,更多相关《共享单车数据分析范文文档格式.docx(12页珍藏版)》请在冰豆网上搜索。
从这些使用行为,把这两组会员和客户分别称为通勤者和游客应该是公平的。
共享单车系统旨在用于短骑:
旅行在半小时不承担任何额外的费用。
骑手是用预期的方式使用这个系统吗
他们是的。
右边的图显示最常见的长度是5到10分钟。
会员显然是精明的价格构建。
很少有超过半小时的用户。
在大多数情况下,客户也是精明的。
他们的行程平均更长一点,但大多不到30分钟。
骑行时间在大于一个小时的地方有一点反弹,让我们再多了解一点
骑着持久的通常1到超过一个小时2个小时,几乎总是由客户。
这可能是由于混淆了“24小时通过”或许多其他因素包括盗窃,健忘,或者迷路。
“24-hourpass”规则通过目前的定价结构,客户购买“24-hourpass”,持续2小时,59分钟将支付总计41美元。
乘车2小时29分钟仅仅是34美元。
有几个自行车租赁公司在旧金山提供3小时租金约32美元。
客户旅行不到三个小时可能不懂共享单车系统和发生不必要的加时费用,或者他们认为便利的自动化系统比起其他租赁产品是值得支付溢价的。
人们在哪里使用共享单车?
我们之前看到90%的共享单车发生在旧金山。
下面以天为单位,检验每个城市使用数量
嗯。
雷德伍德城和帕洛阿尔托看不到太多的日常使用,但没有多少有趣的。
让我们看一个图。
让我们来看一个交互式图表。
在这里,我们看到每日总骑为每个类别的用户绘制整个时间间隔,类似的图表页面的顶部。
使用单选按钮上面来检查不同的城市和下面的复选框突出天数可能与一个影响骑行的因素。
如果我们把用户分为通勤者和游客的划分是对的,我们可以预测当通勤使用者不去上班的时候,会员的使用频次会降低;
当游客型的使用者在小镇时,会员的使用频次会上升。
图表中的重合覆盖部分可以表示这种关联是对的。
会员的骑行在周末在所有城市都是减少的,在感恩节,在圣诞节和新年之间。
客户的骑行在周末增加明显,以及在假期,在美洲杯决赛期间。
雨似乎是一个在自行车使用中很大的威慑,在雨天,系统的使用下降,犹如预期中的周末和假期。
温度,但是似乎并没有对骑行产生重大影响。
海湾地区的温度是出了名的温和,缺乏相关性并不奇怪。
我们不能得出任何结论的影响由49人队主场,巨人,或者鲨鱼。
前往巨人游戏似乎是一个理想的使用自行车的理由,但在此期间唯一巨人的主场比赛重叠的美洲杯比赛。
有几个日期,鲨鱼游戏与略有上升高于平均使用有关,但这种偏离平均水平在这个时期是正常的。
有趣的是,联邦政府关门10月和10月两巴特工人罢工,12月似乎并没有产生重大影响。
骑士在罢工期间仍类似几周之前和罢工之后的数量。
这带来了一个有趣的问题,巴特上班族使用共享单车系统开始寻找一个答案,让我们来看看这些骑行的数字和个人站点。
这里我们看到前十站在整个系统开始或结束一程。
有趣的是,Caltrain和附近的车站渡轮大厦在的顶部。
哈利桥广场和斯提尔德在市场接近渡轮大厦。
圣旧金山Caltrain1和2显然是Caltrain服务线。
车站在内河码头Sansome码头旁边是27,美洲杯馆位于的地方。
十大名单上的自行车分享站步行距离之内巴特停止Sansome市场,市场在4日,斯提尔德在市场。
请记住,所有这些停止也在靠近很多的兴趣点在旧金山市中心。
当然,其他车站服务巴特上班族都是前十种最常借用的物品外,。
让我们看一看所有车站乘坐的列表。
巴特站用蓝色标识文本,Caltrain站用红色文本。
而巴特站的确是所有车站最繁忙的港口之一,他们都是在旧金山,和他们的numbers不与旧金山任何其他站分开。
这些站都集中到一个旧金山市中心的景点,我们期望他们会有高度流量。
自行车分享骑手停靠在车站不一定是转去巴特或者从巴特转。
如果有一个大的应变巴特的通勤者使用共享单车,我们期望看到骑与巴特站的numbers高于其他目的地。
我们看到这里,似乎认为巴特乘客不占大比例的共享单车骑行。
有哪些证据支持这个假设吗?
让我们看看服务于不同形式的从旧金山来或者去旧金山的通勤者的站点
这些数据在一定程度上是有误导性的,因为有4个站点在巴特的站点距离之内,但只有两个在Caltrain和Ferry建筑附近。
所以,我们看看这些站点之间的距离
巴特的共享单车站似乎并不比旧金山的其他站点流量多。
当然,我们会犯了一个巨大的错误,如果我们假设所有游乐设施或从这些站开始相关的通勤系统上或继续旅行。
渡轮大厦是一个主要的旅游目的地,每个巴特站是步行距离内众多餐馆、博物馆、商业、市政铁路和公交车站。
Caltrain站,另一方面,只有步行距离内少数其他的兴趣点。
当我们比较Caltrain站的平均站的数字在旧金山,发现Caltrain通勤者是伟大的利用自行车分享系统。
每个自行车分享系统记录下旅行在始发站和结束站,所以除了检查受欢迎的站台,我们可以检查个别航线的受欢迎程度。
在下面的热图,电台开始行和结束站列中列出。
骑的总数至少对大多数沿着路线由细胞表示颜色,轻的黑暗。
系统骑的热图图我们看到活动往往被分成方块。
这些都是旅行发生在城市范围内,我们不注意,许多车手超越他们的城市开始。
一个例外之间旅行山景和帕洛阿尔托,这191年之间从一个城市去另一个。
在车站的热图寻找旧金山,我们注意到乘客离开最受欢迎的电台,科幻小说Caltrain,分散在整个系统。
乘客前往旧金山Caltrain同样倾向于来自整个系统。
Tips1)两个受欢迎的路线似乎构成了往返汤森在7日科幻Caltrain2,反之亦然。
靠近汤森在7日世博会中心和一些有影响力的科技公司,包括AdobeHeroku,Citrix,出现,Zynga。
这可能反映了一个公司会员计划在上下班的员工,由peninsula-dwellers有很多人参加的会议,或者更多简单,缺乏其他形式的交通工具。
2)最骑路线,哈利桥广场(轮渡建筑)在Sansome内河码头,没有返回路线与伟大的数字,表明骑手倾向于骑在Sansome内河码头并继续他们的旅程在其他地方而不是返回到轮渡建筑。
内河码头在Sansome是最北端接近tourism-heavy沿着内河码头车站,码头39和渔人码头。
自行车道标题北沿内河码头也是bicyclefriendly得多比南部路线。
结论
我们看到这里的自行车共享使用主要在旧金山,上班族,不是下雨,下的游乐设施15分钟。
它看起来像巴特通勤者不使用系统Caltrain通勤者做的程度。
在周末和节假日,游客到旧金山使用系统骑在城里。
一维不探索分析每个车站的流行在用户和客户。
与我们看到的客户和用户的行为我们可以确定车站与游客或更受欢迎与城市的通勤者和潜在的识别区域未来的需求。
一个建议,可以是站在SOMA增长。
用户已经证明是上班族前往工作,SOMA是旧金山的一个区域进行了高密度的全业务,靠近现有的车站,目前没有任何自行车分享站。
第二篇共享单车数据分析:
数据分析实战如果我为共享单车类产品做数据分析
很多人都在问如何提高数据分析能力?
笔者(申悦)认为一方面要掌握基本的分析框架和分析思路,另一方面就要不断实践。
一种很好的实践方式就是分析行业内典型产品的设计、运营思路,假设自己就是该公司的数据产品经理,你会如何对其进行分析。
前一阵在“在行”上就遇到一个案例,学员想了解共享单车类产品的数据分析思路,本文就针对这个案例整理一二,供读者参考。
如果读者中有摩拜或ofo的同学,麻烦帮我参谋下思路是否靠谱哈^_^。
步骤一明确用户是谁
以摩拜为例,其产品可能的目标用户有2类用车方、维护方。
用车方就是车辆使用者,维护方则是车辆提供者。
用车方的诉求是随时随地有车骑,且付费后骑行体验要良好。
维护方的诉求则是以最少的车辆服务最多的用车方,并从用车中得到收益。
步骤二明确用户使用场景
从维护方角度看,其简单场景如下图
从用车方角度看,其场景如下图
明确使用场景、使用流程的原因在于第一,我们的数据都来源于这些场景中;
第二,我们需要通过分析这些数据,让用户每一步过程都顺利进行,避免流失;
第三,还要让企业利益最大化,从而进一步让利用户。
步骤三明确分析目标
经过人群定义和流程梳理,针对共享单车,我们可简单将分析目标定义为
提高成功骑行次数——用户利益最大化
提高毛收入——企业利益最大化
步骤四拆解目标
数据分析的思路就是将目标层层拆解,从每个子指标中发现问题。
基于以上目标,可拆解为
成功骑行次数=app启动次数x每启动扫码开锁率x成功开锁率x成功结束率
成功骑行次数=每人每日行程次数x人数
毛收入=充值收入–投入成本=((每充值金额–欠费金额)x充值次数)–((每车成本+维护费用)x车辆数量)
注以上拆解因人而异,因经验而异,从不同角度可得出不同公式,具体要根据实际运营目标进行调整。
步骤五明确数据观察者角色
拆解出的子指标,需要呈献给不同角色的人群查看,以此来进行不同维度的分析,因此在分析前也要明确这些角色,例如
决策层关注核心指标、交易指标、时段趋势
维护组关注车辆状态、位置、轨迹、故障率、用户反馈
运营组关注骑行次数、充值情况、押金情况、欠费情况、信用积分
产品组关注骑行流程、交互路径、用户反馈
开发组关注请求失败率、App崩溃数
步骤六明确数据度量
依据不同角色,可将拆解出的子指标进一步汇总整合,组成不同的统计度量值。
这一过程中有一点要注意每产出一份度量值,都要给出目的。
也就是说看这个度量值能得出什么结论。
没有结论的数值是没有意义的。
如下所示
核心数据
评估推广效果——注册用户数
评估活跃程度——启动次数、活跃用户数
评估业务健康程度——成功骑行次数、每启动骑行率(用车密度)
评估现金流健康程度——总入账、总出账、充值金额、欠费金额、车辆总成本
评估车辆健康程度——车辆总数量、故障车数量
运营数据
评估推广效果——注册用户数、下载点击数
评估活动运营效果——充值用户数、邀请注册用户数、成功骑行次数、积分增长/消耗量
评估用户质量——行程次数排行、骑行距离排行、信用积分排行、充值排行、欠费人数、认证人数
维护数据
车辆使用总览——车辆总数+车辆位置实时呈现——未使用/使用中/故障中/预约中
评估车辆使用率——使用车辆数/总车辆数
评估车辆故障率——故障车辆数/总车辆数
评估车辆闲置率——连续N日未使用车辆数/总车辆数,以及闲置车辆位置
产品数据
评估需求满足程度/车辆调度效果——每启动骑行率
评估产品使用情况——成功骑行次数、异常骑行次数、平均骑行里程、平均骑行时长、日骑行频率、启动次数、平均骑行天数、预约操作成功率
评估产品操作效果——充值路径、注册路径
评估产品使用异常情况——平均每次开锁成功率
评估用户骑行习惯——骑行轨迹聚合,为调度路线做参考
评估用户满意度——用户反馈好评数/用户反馈数
财务数据
用户金额充值流水、充值次数、充值金额、充押金金额、余额不足金额、押金退款金额
维修金额车辆生产成本、车辆维修成本
注以上数据仅为举例,要根据实际需求调整。
步骤七明确数据维度
有了度量值,就要思考可以通过哪些维度查看这些值,也就是要定义数据维度。
常见的维度包括
按时间小时、日、周、月、季度、年度……
按地区按省、按市、按区……
按渠道邀请注册、扫码注册、广告点击注册……
按类型已认证/未认证、已充值/未充值……
按位置GPS地图定位
以上维度也要再根据需求不断调整、扩展、优化。
总结
以上七步进行完毕,一个基本的共享单车数据分析框架就搭建完毕了。
作为数据产品经理,一方面可基于此设计统计系统功能;
另一方面可依此对不同人群定期产出数据分析报告了。
但以上步骤只是完成了冰山一角,如何在观察数据后,对数据的变化合理归因,并对产品、运营策略的优化提出改进意见,才是真正需要深入研究的!
作者申悦6年产品人前网易新闻产品经理,现红演圈公司产品VP
本文由@申悦原创发布于人人都是产品经理。
未经许可,XX。
本文为头条号作者发布,不代表今日头条立场。
第三篇共享单车数据分析:
我是怎样爬下6万共享单车数据并进行分析的(附代码)
共享经济的浪潮席卷着各行各业,而出行行业是这股大潮中的主要分支。
如今,在城市中随处可见共享单车的身影,给人们的生活出行带来了便利。
相信大家总会遇到这样的窘境,在APP中能看到很多单车,但走到那里的时候,才发现车并不在那里。
有些车不知道藏到了哪里;
有些车或许是在高楼的后面,由于有GPS的误差而找不到了;
有些车被放到了小区里面,一墙之隔让骑车人无法获得到车。
那么有没有一个办法通过获得这些单车的数据,来分析这些车是否变成了僵尸车?
是否有人故意放到小区里面让人无法获取呢?
带着这些问题,笔者开始了研究如何获取这些数据。
01从哪里获得数据
如果你能够看到数据,那么我们总有办法自动化的获取到这些数据。
只不过获取数据的方式方法决定了获取数据的效率。
对于摩拜单车的数据分析这个任务而言,这个爬虫要能够在短时间内(通常是10分钟左右)获取到更多的数据,对于数据分析才有用处。
那么数据来源于哪里?
最直接的来源是摩拜单车的APP。
现代的软件设计都讲究前后端分离,而且服务端会同时服务于APP、网页等。
在这种趋势下我们只需要搞清楚软件的HTTP请求就好了。
一般而言有以下一些工具可以帮忙
直接抓包
Wireshark(在路由器或者电脑)
SharkforRoot(Android)
用代理进行HTTP请求抓包及调试
Fiddler4
Charles
PacketCapture(Android)
由于我的手机没有root,在路由器上抓包又太多的干扰,对于https也不好弄。
所以只能首先采用Fiddler或者Charles的方式试试。
挂上Fiddler的代理,然后在手机端不停的移动位置,看有没有新的请求。
但遗憾的是似乎请求都是去拿高德地图的,并没有和摩拜车相关的数据。
那怎么一回事?
试试手机端的。
换成PacketCapture后果然就有流量了,在请求中找到了我最关心的那个
这个API请求一看就很显然了,在postman中试了一下能够正确的返回信息,看来就是你了!
高兴得太早。
连续爬了几天的数据,将数据进行一分析,发现摩拜单车的GPS似乎一直在跳动,有时候跳动会超过几公里的距离,显然不是一个正常的值。
难道是他们的接口做了手脚返回的是假数据?
我观察到即便在APP中,单车返回的数据也有跳动。
有某一天凌晨到第二天早上,我隔段时间刷新一下我家附近的车,看看是否真的如此。
图片我找不到了,但是观察后得出的结论是,APP中返回的位置确实有问题。
有一台车放在一个很偏僻的位置,一会儿就不见了,待会儿又回来了,和我抓下来的数据吻合。
而且这个跳动和手机、手机号、甚至移动运营商没有关系,说明这个跳动是摩拜接口的问题,也可以从另一方面解释为什么有时候看到车但其实那里没有车。
这是之前发的一个朋友圈的视频截图,可以看到在营门口附近有一个尖,在那里其实车是停住的,但是GPS轨迹显示短时间内在附近攒动,甚至攒动到很远,又回到那个位置。
这样的数据对于数据分析来讲根本没法用,我差点就放弃了。
随着微信小程序的火爆,摩拜单车也在第一时间出了小程序。
我一看就笑了,不错,又给我来了一个数据源,试试。
用PacketCapture抓了一次数据后很容易确定API。
抓取后爬取了两三天的数据,发现出现了转机,数据符合正常的单车的轨迹。
剩下事情,就是提高爬虫的效率了。
02其他尝试
有时候直接分析APP的源代码会很方便的找到API入口,将摩拜的Android端的APP进行反编译,但发现里面除了一些资源文件有用外,其他的文件都是用奇虎360的混淆器加壳的。
网上有文章分析如何进行脱壳,但我没有太多时间去钻研,也就算了。
摩拜单车的API之所以很容易抓取和分析,很大程度上来讲是由于API设计的太简陋
仅使用http请求,使得很容易进行抓包分析
在这些API中都没有对request进行一些加密,使得自己的服务很容易被人利用。
另外微信小程序也是泄露API的一个重要来源,毕竟在APP中request请求可以通过native代码进行加密然后在发出,但在小程序中似乎还没有这样的功能。
如果大家有兴趣,可以试着看一下小蓝单车APP的request,他们使用https请求,对数据的request进行了加密,要抓取到他们的数据难度会增加非常多。
当然了,如果摩拜单车官方并不care数据的事情的话,这样的API设计也是ok的。
声明
此爬虫仅用于学习、研究用途,请不要用于非法用途。
任何由此引发的法律纠纷自行负责。
03目录结构
\analysis-jupyter做数据分析\influx-importer-导入到influxdb,但之前没怎么弄好\modules-代理模块\web-实时图形化显示模块,当时只是为了学一下react而已,效果请见这里crawler.py-爬虫核心代码importToDb.py-导入到postgres数据库中进行分析sql.sql-创建表的sqlstart.sh- 持续运行的脚本
04思路
核心代码放在crawler.py中,数据首先存储在sqlite3数据库中,然后去重复后导出到csv文件中以节约空间。
摩拜单车的API返回的是一个正方形区域中的单车,我只要按照一块一块的区域移动就能抓取到整个大区域的数据。
left,top,right,bottom定义了抓取的范围,目前是成都市绕城高速之内以及南至南湖的正方形区域。
offset定义了抓取的间隔,现在以0.002为基准,在DigitalOcean5$的服务器上能够15分钟内抓取一次。
defstart(self):
left=30.7828453209top=109213455517right=30.4781772402bottom=102178123382offset=0.002ifos.path.isfile(self.db_name):
os.remove(self.db_name)try:
withsqliteconnect(self.db_name)asc:
c.execute("
"
CREATETABLEmobike(TimeDATETIME,bikeIdsVARCHAR(12),bikeTypeTINYINT,distIdINTEGER,distNumTINYINT,typeTINYINT,xDOUBLE,yDOUBLE)"
)exceptExceptionasex:
pass然后就启动了250个线程,至于你要问我为什么没有用协程,哼哼~~我当时没学~~~其实是可以的,说不定效率更高。
由于抓取后需要对数据进行去重,以便消除小正方形区域之间重复的部分,最后的group_data正是做这个事情。
executor=ThreadPoolExecutor(max_workers=250)print("
Start"
)self.total=0lat_range=np.arange(left,right,-offset)forlatinlat_range:
lon_range=np.arange(top,bottom,offset)forloninlon_range:
self.total+=1executor.submit(self.get_nearby_bikes,(lat,lon))executor.shutdown()self.group_data()最核心的API代码在这里。
小程序的API接口,搞几个变量就可以了,十分简单。
defget_nearby_bikes(self,args):
try:
url="
payload="
latitude=%s&
longitude=%s&
errMsg=getMapCenterLocation"
%(args[0],args[1])headers={"
charset"
:
"
utf-8"
"
platform"
4"
referer"
content-type"
application/x-"
user-agent"
MicroMessenger/1000NetType/WIFILanguage/zh_CN"
host"
connection"
Keep-Alive"
accept-encoding"
gzip"
cache-control"
no-cache"
}self.request(headers,payload,args,url)exceptExceptionasex:
print(ex)最后你可能要问频繁的抓取IP没有被封么?
其实摩拜单车是有IP的访问速度限制的,只不过破解之道非常简单,就是用大量的代理。
我是有一个代理池,每天基本上有8000以上的代理。
在ProxyProvider中直接获取到这个代理池然后提供一个p
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 共享 单车 数据 分析 范文