乾貨 | 滴滴 數據分析原來是這樣作的！

hi，我是 Rilke Yang

這是一篇我關於滴滴的數據實戰，以前首發在和鯨，此次投稿到凹凸數據，但願可以幫助到你們~

原文連接：https://www.kesci.com/home/project/5f06b0193af6a6002d0fa357

隨着企業平常經營活動的進行，企業內部必然產生了各式各樣的數據，如何利用這些數據得出有益的看法，並支持咱們下一步的產品迭代以及領導決策就顯得尤其重要。

A/B測試是互聯網企業經常使用的一種基於數據的產品迭代方法，它的主要思想是在控制其餘條件不變的前提下對不一樣（或同1、同質）樣本設計不一樣實驗水平（方案），並根據最終的數據變現來判斷自變量對因變量的影響；A/B測試的理論基礎主要源於數理統計中的假設檢驗部分，此部分統計學知識讀者可自行探索。

長話短說，本次實戰用到的數據集分爲兩個Excel文件，其中test.xlsx爲滴滴出行某次A/B測試結果數據，city.xlsx爲某城市運營數據。

數聽說明

test.xlsx	city.xlsx
date：日期	date：日期
group：組別（控制組/實驗組）	hour：時點
requests：訂單請求數	requests：請求數
gmv：成交總額	trips：訂單數
coupon per trip：每單優惠券金額	supply hours：可服務時長
trips：訂單數	average minutes of trips：平均訂單時長（分鐘）
canceled requests：取消請求數	pETA：顧客預計等待時長
	aETA：顧客實際等待時長
	utiliz：司機在忙率

test.xlsx 數據能夠用來判斷實驗條件對這次A/B測試的結果影響是否顯著；city.xlsx 數據能夠用來探索該城市運營中出現的問題，根據關鍵結論輔助決策。

在本文中，咱們將使用該數據來作A/B測試效果分析與城市運營分析。

1、A/B測試效果分析

一、數據導入

#A/B測試結果數據導入

import pandas as pd

test = pd.read_excel('/home/kesci/input/didi4010/test.xlsx')
test.head()

二、計算ROI

#計算優惠券投入相對gmv的ROI

test['ROI']=test['gmv']/(test['coupon per trip']*test['trips'])
test.head()

三、requests檢驗

數據共58條，對照組與實驗組各29條，樣本量<30。

3.1 requests方差檢驗

1. 記兩組requests方差分別爲從c1,c2

2. 零假設H0：c1=c2；備選假設：H1：c1≠c2

3. 顯著性水平取0.05

#levene檢驗requests是否齊方差

requests_A=test[test.group=='control'].requests
requests_B=test[test.group=='experiment'].requests

import scipy.stats as st
st.levene(requests_A,requests_B)

p值大於0.05，不拒絕原假設，所以可認爲兩組實驗requests齊方差。

3.2 requests均值檢驗

1. 該數據爲同同樣本實驗先後的不一樣水平，所以選用配對樣本t檢驗。

2. 記兩組requests均值分別爲從u1,u2

3. 零假設H0：u1=u2；備選假設：H1：u1≠u2

4. 顯著性水平取0.05

#配對樣本t檢驗（兩獨立樣本t檢驗以前需檢驗是否齊方差，此處不須要）

st.ttest_rel(requests_A,requests_B)

p值大於0.05，不拒絕原假設，所以可認爲實驗條件對requests影響不顯著。

四、gmv檢驗

4.1 gmv方差檢驗

#levene檢驗gmv是否齊方差

gmv_A=test[test.group=='control'].gmv
gmv_B=test[test.group=='experiment'].gmv

st.levene(gmv_A,gmv_B)

p值大於0.05，不拒絕原假設，所以可認爲兩組實驗gmv齊方差。

4.2 gmv均值檢驗

#配對樣本t檢驗（兩獨立樣本t檢驗以前需檢驗是否齊方差，此處不須要）

st.ttest_rel(gmv_A,gmv_B)

p值小於0.05，拒絕原假設，所以可認爲實驗條件對gmv有顯著影響。

五、ROI檢驗

5.1 ROI方差檢驗

#levene檢驗ROI是否齊方差

ROI_A=test[test.group=='control'].ROI
ROI_B=test[test.group=='experiment'].ROI

st.levene(ROI_A,ROI_B)

p值大於0.05，不拒絕原假設，所以可認爲兩組實驗ROI齊方差。

5.2 ROI均值檢驗

#配對樣本t檢驗（兩獨立樣本t檢驗以前需檢驗是否齊方差，此處不須要）

st.ttest_rel(ROI_A,ROI_B)

p值小於0.05，拒絕原假設，所以可認爲實驗條件對ROI有顯著影響。

2、城市運營分析

一、數據導入

#導入該城市運營相關數據

city = pd.read_excel('/home/kesci/input/didi4010/city.xlsx')
city.head()

#查看數據有完好失值

city.info()

二、數據探索

2.1 單量最多的時間點

req_hour = city.groupby(['hour'],as_index=True).agg({'requests':sum},inplace=True)
req_hour

#繪製各時點訂單請求柱狀圖

import matplotlib.pyplot as plt

req_hour.plot(kind='bar')
plt.xticks(rotation=0)

plt.show()

可見，在十一、十二、13這三個時間點內，12點用戶發起訂單的需求是最大的，其次是13點，11點。

司機運營平臺應考慮加大該時點車輛供應。

2.2 單量最多的日期

req_date = city.groupby(['date'],as_index=True).agg({'requests':sum},inplace=True)
req_date.sort_values('date').head()

#繪製訂單請求數隨日期變化的折線圖

req_date.plot(kind='line')

plt.show()

單月訂單請求數隨日期的變化呈週期性變化，咱們猜想4個峯值分別對應4個週末，週末用戶出行需求較大。

經驗證發現猜測與數據吻合，所以司機運營平臺應考慮加大週末、節假日的車輛供給。

2.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.4 單月每日訂單完成率

com_date = city.groupby(['date'],as_index=True).agg({'requests':sum,'trips':sum},inplace=True)
com_date['rate']=com_date['trips']/com_date['requests']
com_date.sort_values('date').head()

#繪製訂單完成率隨日期變化的折線圖

com_date.rate.plot(kind='line')

plt.show()

單月每日訂單完成率規律不太明顯，但幾個谷值基本都出如今週末附近，說明客戶出行需求的提高可能致使響應率的下降。

2.5 顧客等待時間

import numpy as np

eta_hour = city.groupby(['hour'],as_index=True).agg({'pETA':np.mean,'aETA':np.mean},inplace=True)
eta_hour

#繪製顧客等待時長複合柱狀圖

eta_hour.plot(kind='bar')

以上可見，不管哪一個時點，用戶實際等待時長均明顯大於用戶預計等待時長。

各時點用戶等待時長差別不明顯，但13點最高。

客運部一方面應提高用戶預計等待時長的準確性，另外一方面優化平臺派單邏輯等。

2.6 司機在忙率

city['busy'] = city['supply hours']*city['utiliz']
city.head()

busy_hour = city.groupby(['hour'],as_index=False).agg({'supply hours':sum,'busy':sum})
busy_hour['utiliz'] = busy_hour['busy']/busy_hour['supply hours']
busy_hour

12點司機在忙總時長最長，在忙率也最高，用戶訂單請求也最多，說明車輛總數偏少。

2.7 訂單時長

trip_min = city.groupby(['hour'],as_index=False).agg({'average minutes of trips':np.mean})
trip_min

12點用戶訂單需求較多，同時訂單時長最長，說明這個時間點是一個很是重要的時間點。

supply_hour = city.groupby(['hour'],as_index=False).agg({'supply hours':np.mean})
supply_hour

13點訂單量也較大，此時點司機服務時長較短。

爲優化用戶出行體驗，司機運營平臺可聯合客運部可考慮此時段儘可能分配總服務時長較長的司機來接單（經驗較爲豐富）。

三、後續思考方向：

• 提高顧客預計等待時長預測準確度（須要歷史數據進行預測）

• 加大車輛投入（分車輛不一樣等級來看，所以可能須要車輛相關信息表）

• 優化用戶體驗（須要客訴相關數據）

• 優化平臺派單邏輯（須要訂單的位置相關數據）

• 個性化需求（須要用戶屬性、及其餘行爲數據）

 

本文相關代碼下載：

https://alltodata.cowtransfer.com/s/9bb9acdc15ae40

 

推薦一本書，本週末統一上架

感謝北京大學出版社的大力支持

PS  噹噹新用戶優惠碼：DPC3CX

滿60-20，親測能夠換手機號使用

本文分享自微信公衆號 - 凹凸數據（alltodata）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。