虹科案例|虹科Visokio商業智慧平臺在疫後幫酒店業打好翻身仗!
疫後時代以來,報復性度假呈爆炸式增長,首先點燃的就是酒店行業。面對疫後更為理性“挑剔”的客戶以及酒店行業復甦節點:
如何提升酒店管理效率?
怎麼準確判斷流量變化趨勢,擴充線上客源?
有沒有可能透過雲科技手段,加強網際網路深度使用,實現酒店智慧化、互聯化?
類似問題似乎是當下無數酒店行業企業亟需解答的困惑。虹科Visokio Omniscope絕不能容忍任何酒店企業在疫後復甦黃金期掉隊!下面虹科將以酒店行業為例,以其相關資料為基礎,主要從資料探索、資料預處理、資料分析三個部分,為大家詳細介紹虹科提供的Visokio,作為一款商業智慧和資料分析平臺,可以如何從資料到分析再到視覺化,為企業提供一套完整的解 決方案,幫助企業搶得先機,跑得更快!
一.資料探索
該表共包含119390條資料,含32個欄位。由於源資料表欄位是英文的,不太符合國人的閱讀需求,因此需要先進行資料探索,將其轉換為中文,以便於更好地理解各欄位的含義。
將資料集匯入到MySQL資料庫後,各欄位的名字、型別、長度等性質都被做了重新整理,設計後的表結構如下圖所示:
二.資料預處理
1.輸入資料
首先,在虹科Visokio Omniscope中構建一個新的專案,用於處理酒店預訂資料的工作流。然後,新增一個資料庫輸入塊,透過JDBC,將MySQL資料庫中的“酒店預訂源資料”表連線到虹科Visokio Omniscope。最後,檢視錶中資料的分佈情況:
我們可以發現`下單公司`該欄位值存在明顯缺失,NULL值比例達到了94.31%。其次,“旅行社”欄位也存在大量NULL值,比例達到13.69%。
因此,我們之後需要著重對這兩個欄位值進行處理。另外,由於客戶抵達酒店的日期被切分為年、月、周、日四個欄位進行儲存,所以為方便後續的使用,需要將其合併起來形成一個完整的日期。
2.重複值處理
由於資料來源已經做了脫敏處理,所以沒有包含任何客戶或酒店的敏感資訊,原始資料表中也不存在主鍵或訂單ID等標識,即使2條記錄完全一樣,也不一定就是重複的。因此該處不對“重複記錄”進行刪除。
3.缺失值處理
(1)“下單公司”欄位
由於該欄位缺失率達到了94%,並且值的分佈較為零散,不存在分佈趨勢,因此可以認為該欄位參考價值較低,可直接將其刪除。
(2)“旅行社”欄位
該欄位值已經作了脫敏處理,使用ID代表各個旅行社。雖然欄位存在大量缺失,但存在合理性,因為客戶可以自行預訂酒店,並不一定需要透過旅行社進行預訂。於是,使用ID=0填充空值,代表該記錄沒有旅行社ID。
(3)“兒童數”欄位
瀏覽全表,發現在將近12萬條記錄中,只有4條記錄的“兒童數”欄位值缺失。作為int數值型變數,可採用中位數進行補齊。
(4)“旅客國籍”欄位
在該欄位的所有值中,旅客國籍都用了國家的三字母程式碼表示,不過可以發現其中有488條記錄值為NULL,故採用眾數PRT進行填充。
4.異常值處理
(1)“餐型別”欄位
該欄位雖然沒有缺失值,但是觀察資料分佈,發現有1169條資料欄位值為“Undefined”,即未定義,佔比0.98%。另外,該分類欄位有一個類別是’SC’,即無餐。因此,可以把“Undefined”修正為“SC”。
(2)“市場細分”欄位和“分銷渠道”欄位
與用餐型別相似,透過資料分佈情況發現`市場細分`欄位存在2條記錄欄位值為“Undefined”,分銷渠道`欄位存在5條記錄欄位值為“Undefined”。作為分類欄位,此處使用眾數來進行修正。
(3)入住人數統計
在一個訂單中,入住人數必須大於0,因此篩選出訂單入住總人數為0的記錄,即成人數、兒童數、嬰兒數均為0,共180條記錄,將其進行刪除。不同地方有不同規定,此處不考慮未成年人訂酒店的問題,因此不對成年人數為0的記錄做處理。
(4)“平均每日費用”欄位
該欄位不存在缺失值,但是存在異常值。對於每日的開銷,資料範圍應是大於等於0,因此需要刪除開銷為負的記錄,共1條。其次,所有的記錄中資料均分佈在0-520之間,存在一條值為5400的記錄,可以認為這是離群值,會嚴重影響後期的聚合統計,因此將離群記錄刪除。
(5)入住天數為0
在一個訂單中,客人預訂房間入住的天數應大於0,否則認定為沒有預訂房間。因此入住總天數為0的異常記錄需要被刪除,即刪除週末和工作日入住天數均為0的記錄,此處共刪除645條記錄。
(6)“旅客國籍”欄位
在該欄位中,同時存在兩個表示中國的值,即CN和CHN,為方便後續表連線,此處將CN修正為CHN。此外,該欄位還存在值TMP,在國家程式碼記錄表中查詢不到,為錯誤值,並且佔比較小,僅為3條記錄,因此直接將其刪除。
5.欄位值漢化
資料表中的分類欄位,值均為英文,為便於閱讀,將欄位值替換為中文。
6.日期值處理
(1)入住日期處理
前面提到在該資料表中,客人預訂的入住時間被切分為了年、月、周、日四個欄位。為方便後續的操作和閱讀,在此處需要將年、月、日三個欄位合併起來,形成一個日期形式的欄位值,新欄位命名“預訂入住日期”,輸出模式設定為“yyyy-MM-dd”。
(2)“訂單最後更新日期”
原始資料表中訂單最後更新日期為字元型,需將其改為日期型,輸出模式設定為“yyyy-MM-dd”。
在便於閱讀Visokio Omniscope中完成上述所有的資料預處理,形成工作流如下:
三.資料分析
1.資料分佈情況
首先可以對原始資料集中比較重要的欄位資料分佈做一個視覺化處理,以便大家快速知道資料集中包含的資訊以及各欄位資料的分佈情況,構建出第一個儀表板-資料的分佈情況,如下圖所示:
從上圖可以瞭解到,在總體資料中,城市酒店和度假酒店的訂單記錄約為2:1,相差較大。因此在之後分析的過程中,應注重特徵分佈和比率,而不是值的大小。
其次,絕大多數的訂單都不需要提前交定金,但在需要交定金的14.6k個訂單中,只有162條訂單定金是可退的,這暗示了消費者為避免造成不必要的損失,在預付定金時需要慎重考慮。
再者,對於訂單的取消情況,總體的取消率達到了37%,後期需要對取消情況進行著重分析。
對於數值型變數,透過直方圖可以瞭解到:
大部分旅客都不會有特殊請求,約有94%的訂單顯示旅客不需要停車位。此外,在入住總人數上,基本在1-4人的區間內,顯示入住2人的比例最高,達到了68.87%。而入住天數大多在1-4天的區間內,顯示預訂入住2天的比例最高,達到了23.31%。
2.酒店資料分析
源資料中的酒店型別有兩種:度假酒店和城市酒店。考慮到這兩個酒店型別本身性質不同,且記錄數相差較大,因此在分析過程中將資料分為兩個類別進行獨立分析,並且在儀表板中設定了過濾器,透過過濾器可以篩選出對應類別的資料。
為提升訂單的入住率,酒店需要不斷最佳化自己的服務,給顧客提供更舒服的體驗。因此,從酒店運營角度考慮,主要研究:整體的訂單情況、訂單的取消率、以及可能造成訂單取消的因素等等,並做出以下分析(以城市酒店資料為例):
第一,
處
理後的資料集中,共有78895條城市酒店的預訂資料。
透過堆疊條形圖可以看到,城市酒店的所有訂單取消率為42%,這說明客戶預訂訂單後,行程還是存在很大的不確定性。
在此基礎上,對各個月份的訂單量和取消情況進行分析,繪製“各月份取消訂單數”面積圖。可以發現,訂單取消量隨時間變化的趨勢與總體訂單數量走向基本相同,因此可以判斷,季節因素對於旅客取消訂單的影響較小。
第二,
根據酒店各月份的收入和訂單數繪製棒棒糖圖。
結果顯示,兩圖不僅呈現趨勢相同,且變化程度也非常類似,這說明降價促銷或者急劇漲價的情況並不明顯,高訂單量同時也帶來了高收入。而對於各月份老客戶的訂單統計,並未從中發現明顯規律。2015年10月的回頭客訂單最多,為125條記錄,其次是2017年5月,為103條記錄。
第三,
對入住人數的統計
。
對訂單的入住人員結構進行分析,可以發現,各月份的訂單主體都是以成人為主,兒童和嬰兒的比例極低。在大多數月份,幾乎看不到嬰兒的佔比情況,這是符合我們的常理的。
第四,
對於旅客國籍分佈,繪製樹狀圖進行分析。
其中來自葡萄牙、法國和德國的旅客最多,佔比分別達到了39%、11%和8%。對於停車位的需求,圖中顯示,98%的旅客不需要停車位,2%的旅客只需要1個停車位,停車位需求數大於1的訂單記錄數僅為5條,幾乎可以忽略不記,因此記為佔比為0%。
第五,
對於餐型的需求
。
絕大部分旅客只預訂了早餐,佔比第二高的是無餐,即不需要預訂任何餐型,三餐都需要預訂的訂單佔比是最小的。
3.取消預訂分析
透過上述分析可以瞭解到,城市酒店的訂單取消率達到了42%,這個資料不太理想。為提高酒店的盈利,對訂單取消原因進行分析十分必要,從而可以有針對性的最佳化酒店運營,降低訂單取消率。對此,我們找出5個可能導致旅客取消訂單的因素,繪製了下面的儀表板:
(
1
)
房間匹配度
在78895條城市酒店資料中,有6965個訂單的房間與旅客最初預訂的房間不同,佔比達到了8.83%。將這些房間匹配度為否的資料篩選出來,可以發現未取消訂單和取消訂單的二級餅圖分佈情況產生明顯變化。
當旅客指定房間型別與最終預留房間型別為B-A或F-A時,更容易導致旅客取消訂單。因此酒店在面臨房源不足需要為旅客更改房間型別時,應該儘量避免這兩種更改方案,以減少旅客訂單取消率。
(
2
)
預付定金型別
在所有城市酒店中,定金型別共有三種:不可退、可退還和無定金。據此可以分別繪製未取消訂單和取消訂單的金字塔圖,從中發現未取消的訂單幾乎都屬於無定金型別。而在所有的取消訂單中,有12843條訂單定金顯示為不可退,佔取消訂單原因的比例高達38.86%。
據此可知,原本酒店設定定金不可退就是為了防止旅客取消訂單,但很明顯,這個操作並沒有得到很好的防範效果,反而還很可能導致不良的口碑,因此酒店後期在設定定金規則時需更加謹慎。
(
3
)
提前預訂天數
在所有城市酒店資料中,下單和入住間隔天數字段值的範圍為0-629。繪製提前預訂天數統計流圖,發現不論訂單是否取消,提前1個月預訂的佔比都是較高的。因為時間越長,旅客行程變化的可能性越大,也就更可能取消訂單,所以為判斷提前預訂天數對取消訂單的影響,可以將資料範圍縮小到30以上,即30-629。
結果顯示,當在提前240天以上預訂訂單時,旅客取消訂單的可能性會大於不取消訂單。因此酒店在計劃開放提前預約服務時,可以考慮適當的縮短預約週期。
(
4
)
入住
時長分析
從上文我們已經知道,旅客預訂的入住天數普遍在1-4天。以是否取消訂單為類別,繪製兩者的箱線圖,發現兩者中位數均為3,上四分位數均為4。
為了更好的分析入住時長對旅客取消訂單的影響,將入住時長大於4天的資料篩選出來。結果發現,訂單的取消率由最初的41.9%下降到40.71%,似乎入住時長對取消訂單的影響並不大。然而,當我們把入住時長範圍縮短到5-48天時,取消率達到了45.48%。當縮短到10-48天時,取消率達到了64.65%。當縮短到15-48時,取消率甚至到了76.97%。
這說明,入住時長在一定程度上確實是影響了訂單的取消,這也可能和旅客個人的時間安排有關。酒店在這方面的最佳化措施可以是對大額訂單給予一些優惠,以吸引旅客預訂。
( 5 ) 訂單等待時間
對於訂單等待時間,即酒店確認訂單的響應時間,值範圍為0-391。不論訂單最終是否取消,兩個類別中0-25的響應時間佔比都是最高的。
將資料範圍縮短到25-391,發現資料的分佈情況發生了非常大的變化。幾乎各個區間,訂單的取消量都超過了未取消的訂單數,總體的訂單取消率高達66%。如果將資料範圍縮短到365-391,即訂單等待時間超過1年時,訂單取消率達到了96.7%。
這說明,酒店對客戶的響應時間將在很大程度上決定訂單是否成交。因此,酒店應最佳化內部的軟硬體設施和員工培訓,儘可能的縮短客戶的等待時間。
“關於虹科Visokio Omniscope你瞭解多少?”
請聽題:
1. 虹科Visokio Omniscope支援哪些瀏覽器?(多選)
A.谷歌 B.Edge C. Internet Explore D.Safari E.Firefox
2. 虹科Visokio Omniscope是否支援私有化部署?
是【】 否【】
記得點贊收藏轉發,關注我們哦~不要錯過下一期文末正確答案揭曉!當然,也歡迎評論區告訴我們你的觀點,或者前往 虹科雲科技官網提前檢視答案以及瞭解更多虹科Visokio相關資訊...
虹科提供的Visokio 是一套集ETL、分析、視覺化、資料管理員、資料科學家、資料分析師等多重功能身份為一體的完美工具,是具備十足相容性,開放性、可擴充套件性、協作性、自動化、和安全性於一身的自助式商業智慧平臺。
虹科是Visokio的中國區戰略合作伙伴 ,虹科持續關注各行業當下急切需求,專注於為企業解答疑問,制定專屬服務,一站式解決問題!為企業的資料分析與決策提供定製化方案!是無數企業實現商業智慧的合作選擇!
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/70026953/viewspace-2940047/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 虹科案例 | 虹科Domo商業智慧,助力保險公司逃離繁雜資料池!
- 虹科案例 | 絲芙蘭xDomo:全球美妝巨頭商業智慧新玩法
- 虹科分享|被困雲端?虹科Redis企業版資料庫來解救!Redis資料庫
- 虹科乾貨 | 什麼是商業智慧 (BI) 儀表板?
- 虹科分享 | 虹科Redis企業版資料庫如何支援實時金融服務?Redis資料庫
- 虹科分享|虹科Redis企業版資料庫帶你跑贏MySQL數字時代!Redis資料庫MySql
- 虹科乾貨| 虹科Redis企業版資料庫:告別遊戲卡頓,讓快樂加速!Redis資料庫遊戲
- 虹科案例 | Redis企業版資料庫:金融行業客戶案例解讀Redis資料庫行業
- 虹科分享 | 資料庫效能翻3倍:虹科Redis企業版的RoF是如何做到的?資料庫Redis
- 虹科乾貨 | Redis企業版—比Redis開源更好用!Redis
- 虹科分享 | Domo零售行業商業智慧白皮書:《從零售企業的資料中獲取價值》行業
- 虹科乾貨 | 一文詳解Redis企業版軟體!Redis
- 虹科案例 | Redis企業雲如何透過快取輕鬆擴充套件到億級請求?Redis快取套件
- 虹科分享 | 為什麼要從Redis社群版轉向Redis企業版?Redis
- 【虹科乾貨】關於JSON資料庫JSON資料庫
- 虹科乾貨|Redis企業版資料庫為企業「資料安全」疊加最強Buff!Redis資料庫
- 【虹科乾貨】無模式資料庫的利與弊模式資料庫
- 【虹科乾貨】5個關於微服務的誤解微服務
- 【虹科乾貨】設計微服務架構的原則微服務架構
- 虹科乾貨 | 零售業數智升級不掉隊,get資料,get未來!
- 虹科分享 | 一個高爾夫球用品製造商怎樣處理資料?
- 【虹科乾貨】Oracle與Redis Enterprise協同,作為企業快取解決方案OracleRedis快取
- 虹科分享 | B站崩了怎麼辦?Redis企業版資料庫多雲戰略分析Redis資料庫
- 【虹科分享】Redis 不僅僅是記憶體資料庫Redis記憶體資料庫
- 【虹科乾貨】零售商們正在尋找實時庫存解決方案
- 虹科分享 | 一起聊聊Redis企業版資料庫與【微服務誤解】哪些事兒!Redis資料庫微服務
- 【虹科乾貨】Redis 開發者需要了解的快取驅逐策略Redis快取
- 虹科乾貨 | 資料庫的九大關鍵功能介紹資料庫
- 科虹通訊聯姻高亞科技一體化管理提升效益
- 【虹科分享】利用ProfiShark 構建行動式網路取證工具包
- 軟通金科升級釋出"企業智慧管家(SaaS版)"平臺
- 易沃普智慧商業平臺
- 【虹科分享】一種動態防禦策略——移動目標防禦(MTD)
- 【虹科乾貨】觸發器和函式:讓程式碼更接近資料觸發器函式
- 虹盤雲相簿:拉近家庭距離,跨平臺互聯
- 【虹科乾貨】Redis Enterprise vs ElastiCache——如何選擇快取解決方案?RedisAST快取
- 【虹科分享】針對終端的Defender:Morphisec彌補Windows10安全防護Windows
- 大資料:商業革命與科學革命大資料