滴滴运营A/Btest城市运营分析
背景
隨著企業日常經營活動的進行,企業內部必然產生了各式各樣的數據,如何利用這些數據得出有益的見解,并支持我們下一步的產品迭代以及領導決策就顯得尤為重要。
A/B測試是互聯網企業常用的一種基于數據的產品迭代方法,它的主要思想是在控制其他條件不變的前提下對不同(或同一、同質)樣本設計不同實驗水平(方案),并根據最終的數據變現來判斷自變量對因變量的影響;A/B測試的理論基礎主要源于數理統計中的假設檢驗部分,此部分統計學知識讀者可自行探索。
數據說明
數據包括test.xlsx和city.xlsx兩個數據集,test.xlsx為某次A/B test的數據集,利用該數據集判斷實驗條件對此次測試效果的影響是否顯著。
city.xlsx為某城市的運營數據,利用該數據集探討某高峰時間段的乘客需求得不到滿足的原因,根據結論輔助決策
1.A/B test
1.1 計算投資回報率ROI
#計算優惠券投入相對gmv的ROI(投資回報率ROI = 收回價值/成本投入 *100%,這里的“收回價值”所表達的是收回了多少而非利潤) test['ROI']=test['gmv']/(test['coupon per trip']*test['trips']) test.head()1.2 requests檢驗
test.shaperequests方差齊次檢驗
1.記兩組requests方差分別為c1,c2
2.零假設H0:c1 = c2,備擇假設H1:c1 != c2
3.顯著性水平取 0.05
認為requests_A,requests_B近似服從正態分布
這里說一下什么是方差分析:
方差分析就是方差齊性的檢驗
什么是方差齊性,方差齊性是指不同組間的總體方差是一樣的。
那為什么方差分析的前提是要組間的總體方差保持一致呢?先想想方差分析是做什么呢?
方差分析是用來比較多組之間的均值 是否存在顯著差異的!!!!
也就是說,假如多組之間方差不一致,也就意味著值的波動是不一樣的,如果此時均值之間存在顯著差異,不一定能夠說明這種顯著差異是不同組之間帶來的,而有可能是方差較大帶來的;
如果多組之間的方差保持一致,也就意味著組與組之間的值的波動程度差不多,這時候在方差波動程度相同的情況下,如果不同組之間的均值存在顯著差異,那么可以認為是不同組間處理帶來的。
這里用的levene檢驗,它適用于總體非正態的數據。
requests均值檢驗
1.該數據為同一樣本實驗前后的不同水平,因此選用配對樣本t檢驗。
2.記兩組requests均值分別為u1,u2
3.零假設H0:u1=u2;備選假設H1:u1≠u2
4.顯著性水平取0.05
1.3 gmv檢驗
同理對gmv進行方差和均值檢驗
gmv方差齊次性檢驗
gmv_A = test[test.group =='control'].gmv gmv_B = test[test.group =='experiment'].gmv import scipy.stats as st st.normaltest(gmv_A) print('gmv_A的正態性檢驗結果為:',st.normaltest(gmv_A)) st.normaltest(gmv_B) print('gmv_B的正態性檢驗結果為:',st.normaltest(gmv_B)) # st.levene(requests_A,requests_B) #gmv_A值接近0.05,近似認為正態分布; #gmv_B大于0.05,服從正態分布
1.記兩組gmv方差分別為d1,d2
2.零假設H0:d1 = d2,備擇假設H1:d1 != d2
3.顯著性水平取 0.05
gmv均值檢驗
1.該數據為同一樣本實驗前后的不同水平,因此選用配對樣本t檢驗。
2.記兩組gmv均值分別為v1,v2
3.零假設H0:v1=v2;備選假設H1:v1≠v2
4.顯著性水平取0.05
1.4 ROI檢驗
同理對ROI進行齊方差和均值檢驗。
ROI方差檢驗
1.記兩組gmv方差分別為e1,e2
2.零假設H0:e1 = e2,備擇假設H1:e1 != e2
3.顯著性水平取 0.05
ROI均值檢驗
1.該數據為同一樣本實驗前后的不同水平,因此選用配對樣本t檢驗。
2.記兩組ROI均值分別為w1,w2
3.零假設H0:w1=w2;備選假設H1:w1≠w2
4.顯著性水平取0.05
2.城市運營分析
city #數據預處理 #有無缺失值 city.info() #有無重復值 city.duplicated().sum()
無冗余值
2.1 數據探索
2.1.1單數最多的時間點
req_hour = city.groupby('hour').agg({'requests':sum},inplace = True) req_hour.reset_index(inplace = True) req_hour import seaborn as sns sns.set_style('white') plt.figure(figsize = (8,5),dpi = 200) plt.bar(req_hour.hour,req_hour.requests,width = 0.35,label = 'requests') plt.xticks(req_hour.hour) plt.legend()
午高峰出現在12點,訂單需求量達到了8530,其次是13點,最后是11點平臺在該時段需考慮增大車輛供應。
2.1.2 單量最多日期
req_day= city.groupby('date').agg({'requests':sum}).reset_index() req_day mpl.rcParams['font.sans-serif'] = ['SimHei'] plt.rcParams['axes.unicode_minus']=False fig,axes = plt.subplots(dpi = 200,figsize = (9,6)) plt.plot(req_day['date'],req_day['requests'],label = 'requests') plt.xticks(size =15,rotation = 90) plt.title('每日訂單請求變化趨勢') plt.legend()
1.請求訂單數呈現周期性規律變化,周末出行需求旺盛,是訂單需求高峰且12時為每日需求高峰,平臺需要考慮在周末或者節假日增大車輛供應,
2.考慮到部分司機周末休息的情況,因此可健全給予周末接單的滴滴司機額外獎勵的機制,激發司機的接單意愿,同時保障乘客的出行需求
2.1.3 各時間段的訂單完成率
com_hour = city.groupby(['hour'],as_index=False).agg({'requests':sum,'trips':sum},inplace=True) com_hour['rate']=com_hour['trips']/com_hour['requests'] com_hour
13時的訂單完成率僅為47%,即超過一半的訂單未得到及時接應,運營部門需重點關注13時低完成率的原因,進一步優化該時間段的訂單接受、派發機制
2.1.4每日訂單完成率
com_day = city.groupby(['date'],as_index=False).agg({'requests':sum,'trips':sum},inplace=True) com_day['rate'] = com_day['trips']/com_day['requests'] com_day fig,axes = plt.subplots(dpi = 200,figsize = (9,6)) plt.plot(com_day['date'],com_day['rate'],label = 'rate') plt.xticks(size =15,rotation = 90) plt.title('每日接單率變化趨勢') plt.legend()
1.9月的3,11,13號接單率均低于40%,尤其是9月11日的該時段內的接單率更是直接降到23.35%。
2.引起9-11接單率較低原因可能是受前一日訂單較少影響,許多司機擔心訂單數量依然較少,便沒有第二日出門的接單意愿。
3.引起9-13接單率較低原因可能是當日為周五,乘客出行需求旺盛,但受前幾日訂單需求較少的情緒影響,司機接單意愿不高。
4.當日的司機流失率較高,公司的獎勵機制、訂單派發邏輯以當日出行需求的預判不準確都可能導致接單率較低,這會極大影響乘客出行體驗,需要對這部分內容及時完善。
2.1.5 顧客等待時間
eta_hour = city.groupby(['hour'],as_index=True).agg({'pETA':np.mean,'aETA':np.mean},inplace=True) eta_hour plt.rcParams['figure.dpi']=200 #圖像分辨率 plt.rcParams['figure.figsize'] =(11,8)#圖像顯示大小 eta_hour.plot(kind = 'bar') plt.xticks(rotation = 0) plt.ylabel('ETA/h') plt.title('顧客各時段等待時間')
1.乘客的實際等待時間都長于預計等待時間,該時長預測算法有待改進,可以考慮結合司機的歷史到達時間以及實況路段信息對算法進行改進;
2.優化訂單派發的路徑規劃機制,保證乘客的等待時間不至于過長;
3.另一方面可以在11—13點的出行高峰設置接單獎勵機制,給予司機該時段訂單完成后的額外獎勵
2.1.6 司機各時間段平均在忙率
city['busy'] = city['supply hours'] *city['utiliz'] city busy_hour = city.groupby('hour').agg({'supply hours':sum,'busy':sum}) busy_hour['busy_rate'] = busy_hour['busy']/busy_hour['supply hours'] busy_hour
12點依舊是司機繁忙的高峰期,運營部門應考慮如何激勵該時段的司機接單意愿,以加大車輛的投入滿足該時段的出行需求。
總結:
1.接單率低原因
1)數據傳輸問題;
2)外部不可控因素:pest模型
3)內部因素:運營部門未及時意識到當日的訂單需求過大導致的車輛供應不足;
4)邏輯樹定位接單率低原因:三個維度:
(1)乘客出行需求相比以往,過于旺盛;
(2)司機接單意愿受前幾日的情緒影響,獎勵機制不足;
(3)系統的訂單派發系統問題
2.出行高峰考慮加大車輛投入,并設立該時段的訂單完成額外獎勵機制。
3.結合司機的歷史到達時間以及實況路段信息對算法進行改進,提升等待時長的預測算法性能,優化訂單派發邏輯。
4.優化出行的路徑規劃,避開繁忙、擁擠路段,降低訂單完成時間和司機在忙率。
注:全文參考https://www.heywhale.com/mw/project/5f06b0193af6a6002d0fa357
總結
以上是生活随笔為你收集整理的滴滴运营A/Btest城市运营分析的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: IDEA 操作指南 - 演出模式,注入语
- 下一篇: 车库系统服务器配置,标准停车场管理系统方