在今天的文章中，您將學習：

• 如何合并和整理數(shù)據(jù)，
• 如何探索和分析數(shù)據(jù)，
• 如何創(chuàng)建漂亮的圖形以可視化您的發(fā)現(xiàn)

本文適用于誰：

• 經(jīng)常處理數(shù)據(jù)的人
• 對Python和Pandas有基本了解的人

情景再現(xiàn)：

你的任務是提高銷售團隊的績效。在我們假設的情況下，潛在客戶有相當自發(fā)的需求。當這種情況發(fā)生時，您的銷售團隊會在系統(tǒng)中放置一個訂單線索。然后，您的銷售代表會設法安排一次會議，會議將在訂單線索被注意到的時候舉行。有時在前，有時在后。你的銷售代表有一個把會議和餐費結(jié)合起來的開支預算。銷售代表花費他們的成本，并將發(fā)票交給會計團隊處理。在潛在客戶決定是否接受您的報價后，銷售代表會跟蹤訂單線索是否轉(zhuǎn)化為銷售。

對于分析，您可以訪問以下三個數(shù)據(jù)源：

• 訂單線索(包含所有訂單線索和轉(zhuǎn)換信息)
• 銷售團隊(包括公司和負責的銷售代表)
• 發(fā)票(提供發(fā)票和參與者的信息)

導入和安裝：

需要安裝標準庫，此外，通過使用以下命令,在你的Notebook上安裝seaborn.

!pip install seaborn 

下載數(shù)據(jù)：

您可以按照上周的說明下載并合并數(shù)據(jù)，也可以從此處下載文件并將其加載到 Notebook中。

開始探索

總轉(zhuǎn)化率發(fā)展：

事情似乎在2017年初走下坡路。經(jīng)過與首席銷售官核實，發(fā)現(xiàn)大約在那個時候有一個競爭對手進入了這個市場。很高興知道，但我們現(xiàn)在無能為力。

_ = order_leads.set_index(pd.DatetimeIndex(order_leads.Date)).groupby(    pd.Grouper(freq='D')     
 
)['Converted'].mean()    
ax = _.rolling(60).mean().plot(figsize=(20,7),title='Conversion Rate Over Time')      
vals = ax.get_yticks()      
ax.set_yticklabels(['{:,.0f}%'.format(x*100) for x in vals])   
 
sns.despine() 

1. 我們使用下劃線_作為臨時變量。對于以后不再使用的一次性變量，我通常會這樣做。
2. 我們在order_leads.Date上使用了pd.DateTimeIndex并將結(jié)果設置為索引，這使我們能夠
3. 使用pd.Grouped(freq ='D')按天對數(shù)據(jù)進行分組。 或者，您可以將頻率更改為W，M，Q或Y(每周，每月，每季度或每年)
4. 我們計算每天“轉(zhuǎn)換”的平均值，這將給出當天訂單的換算率。
5. 我們使用.roll(60)和.mean()來獲得60天的滾動平均值。
6. 然后我們格式化yticklables，使它們顯示一個百分號。

各銷售代表的轉(zhuǎn)化率：

各個銷售代表之間似乎存在很大的差異。 讓我們對此進行更多調(diào)查。

就所使用的功能而言，這里沒有太多新內(nèi)容。 但是請注意我們?nèi)绾问褂胹ns.distplot將數(shù)據(jù)繪制到軸上。

如果我們回顧sales_team數(shù)據(jù)，我們會記住并非所有的銷售代表都擁有相同數(shù)量的客戶，這肯定會產(chǎn)生影響! 讓我們檢查。

我們可以看到，轉(zhuǎn)換率數(shù)字似乎與分配給銷售代表的帳戶數(shù)量成反比。 那些降低的轉(zhuǎn)化率是有道理的。 畢竟，代表擁有的帳戶越多，他可以花在每個人身上的時間就越少。

在這里，我們首先創(chuàng)建一個輔助函數(shù)，該函數(shù)將垂直線映射到每個子圖中，并用數(shù)據(jù)的均值和標準差注釋該線。然后我們設置一些seaborn繪圖默認值，例如較大的font_scale和whitegrid設置為樣式。

進餐影響：

看來我們已經(jīng)確定了用餐的日期和時間，讓我們快速了解一下時間分布：

invoices['Date of Meal'] = pd.to_datetime(invoices['Date of Meal'])     
invoices['Date of Meal'].dt.time.value_counts().sort_index() 

out: 
07:00:00    5536 
08:00:00    5613 
09:00:00    5473 
12:00:00    5614 
13:00:00    5412 
14:00:00    5633 
20:00:00    5528 
21:00:00    5534 
22:00:00    5647 

總結(jié):

invoices['Type of Meal'] = pd.cut(     
    invoices['Date of Meal'].dt.hour,     
    bins=[0,10,15,24],     
    labels=['breakfast','lunch','dinner']     
) 

注意，這里我們是如何使用pd.cut為數(shù)字數(shù)據(jù)分配類別的，這很有意義，因為畢竟，早餐是在8點還是9點開始，都沒有關(guān)系。

另外，請注意我們?nèi)绾问褂?dt.hour，我們只能這樣做，因為我們將

invoices['Date of Meal']轉(zhuǎn)換為之前的日期時間。 .dt是所謂的訪問器，其中有三個cat，str和dt。 如果您的數(shù)據(jù)類型正確，則可以使用這些訪問器及其方法進行直接操作(計算有效且簡潔)。不幸的是，invoices ['Participants']是一個字符串，我們必須首先將其轉(zhuǎn)換為合法的JSON，以便我們 可以提取參與者的數(shù)量。

def replace(x):     
    return x.replace("\n ",",").replace("' '","','").replace("'",'"')     
invoices['Participants'] = invoices['Participants'].apply(lambda x: replace(x))     
invoices['Number Participants'] = invoices['Participants'].apply(lambda x: len(json.loads(x))) 

現(xiàn)在，我們合并數(shù)據(jù)。 為此，我們首先將公司ID上的所有發(fā)票左連接到order_leads。 但是，合并數(shù)據(jù)會導致所有餐點都加入所有訂單。 也有古老的飯菜，以最近的訂單。 為了緩解這種情況，我們計算了進餐和點餐之間的時間差，并且僅考慮訂單周圍五天的進餐。

仍然有一些訂單已分配多餐。 當同時有兩個訂單和兩餐時，可能會發(fā)生這種情況。 然后，兩餐將分配給兩個訂單線索。 要刪除這些重復項，我們僅使餐點最接近該訂單。

我創(chuàng)建了一個繪圖欄功能，其中已經(jīng)包含一些樣式。 通過該功能進行繪圖可以使目視檢查更快。 我們將在一秒鐘內(nèi)使用它。

進餐類型的影響：

orders_with_meals['Type of Meal'].fillna('no meal',inplace=True)     
_ = orders_with_meals.groupby('Type of Meal').agg({'Converted': np.mean})     
plot_bars(_,x_col='Type of Meal',y_col='Converted') 

哇! 用餐相關(guān)的訂單與不用餐相關(guān)的訂單之間的轉(zhuǎn)換率差異非常大。 不過，看起來午餐的轉(zhuǎn)化率略低于晚餐或早餐。

時間的影響(即進餐之前或之后進餐)：

_ = orders_with_meals.groupby(['Days of meal before order']).agg(     
{'Converted': np.mean}     
)     
plot_bars(data=_,x_col='Days of meal before order',y_col='Converted') 

“訂購前用餐天數(shù)”為負數(shù)表示用餐是在訂單線索輸入之后進行的。我們可以看到，如果膳食在訂單線索進入之前發(fā)生，則對轉(zhuǎn)化率似乎有積極影響。 訂單的先驗知識似乎在這里給我們的銷售代表帶來了優(yōu)勢。

結(jié)合所有：

• 現(xiàn)在，我們將使用熱圖同時可視化數(shù)據(jù)的多個維度。 為此，首先創(chuàng)建一個輔助函數(shù)。
• 然后，我們使用一些最終數(shù)據(jù)進行爭辯，以額外考慮餐食價格與訂單價值的關(guān)系，并將交貨時間分配到“訂購前”，“訂購前后”，“訂購后”，而不是從負4到正4的天數(shù)，因為這在解釋方面有些繁瑣。

運行以下代碼片段將產(chǎn)生多維熱圖。

draw_heatmap(     
    data=data,     
    outer_row='Timing of Meal',     
    outer_col='Type of Meal',     
    inner_row='Meal Price / Order Value',     
    inner_col='Number Participants',     
    values='Converted'     
) 

該熱圖當然很漂亮，盡管起初有點難讀。 因此，讓我們來看一下。 圖表總結(jié)了4個不同維度的影響：

• 用餐時間：訂購后，訂購前后，訂購前(外排)
• 用餐類型：早餐，晚餐，午餐(外欄)
• 餐單價格：最低價格，最低價格，比例價格，最高價格，最高價格(內(nèi)排)
• 參加人數(shù)：1,2,3,4,5(內(nèi)欄)

當然，圖表底部的顏色似乎更深/更高，這表明：

• 在點餐之前用餐時，轉(zhuǎn)化率會更高
• 當只有一名參與者時，晚餐轉(zhuǎn)化率似乎更高
• 與訂單價值相比，看起來更昂貴的餐食對轉(zhuǎn)化率有積極影響

結(jié)果：

• 銷售代表的帳戶不要超過9個(轉(zhuǎn)化率會迅速下降)
• 確保每個訂單線索都伴隨有會議/進餐(因為這會使轉(zhuǎn)換率翻倍當只有一位員工來訪時，晚餐最有效
• 您的銷售代表應支付的餐費約為訂單金額的8%至10%
• 時間是關(guān)鍵，理想情況下，您的銷售代表應盡早知道即將達成交易。

單擊此處查看代碼： GitHub Repo / Jupyter Notebook

備注為熱圖：

• 要解決可能出現(xiàn)的格式錯誤，可以先卸載(然后在終端中必須這樣做)，然后運行以下命令，將matplotlib降級到3.1.0版：

!pip install matplotlib==3.1.0 

本文轉(zhuǎn)自雷鋒網(wǎng)，如需轉(zhuǎn)載請至雷鋒網(wǎng)官網(wǎng)申請授權(quán)。