數據分析在攜程產品設計中的應用

數據與設計的關係，業界向來頗多熱議——有「數據驅動設計」之說，有「數據引導設計」之論，也有相似「數據關注削弱用戶體驗」的抱怨。看似感性主觀的用戶體驗設計與理性客觀的數據分析，究竟怎樣才能相互做用進而碰撞出產品的靈感火花？

本文試拋一磚，將經過酒店產品設計中的兩個案例來介紹數據在攜程產品設計過程當中的應用實踐，以及攜程所構建的專業數據體系。

產品設計的數據觀

做爲互聯網產品設計者，首先要樹立對數據的正確認知，咱們稱之「數據觀」。

• 數據貫穿設計全過程，產品設計要學會用數聽說話
• 數據是人創造的，只有人會解釋和分析數據
• 明確業務/設計目標，根據需求來採集、分析數據
• 上線後關注數據變化，發現問題，快速迭代
• 持續監測、評估數據，以檢驗設計目標是否達成
• 數據不能替代用戶體驗，改進仍需結合多種手段

而要讓數據分析真正有效地推動產品設計，又有如下必備條件：

首先是數據源，「巧婦難爲無米之炊」，完善的數據採集、展現體系，是進行分析的先決條件。

而後是數據感，也就是從數據中捕捉、挖掘、分析的能力。

林彪當年在遼瀋戰役聽取一場遭遇戰的戰報時，敏銳地發現繳獲短槍長槍之比、小車大車之比、俘虜軍官士兵之比，都顯著高於日常，因而判斷敵軍指揮所就在附近。果真，經專門部署，在後續戰鬥中俘獲了主將廖耀湘。林彪並無大數據分析工具，可是他有經驗的積累，數據感出色，當數據異於日常時就能作出準確預判。

再次是對數據的分析法，常見的專業方法有多維分析、路徑分析、留存分析、回訪分析等，將多種方法結合使用會更有助提高數據支撐的深度。

最後，如何將從數據分析中洞見的用戶行爲與態度，在設計中予以體現，那就須要設計師的設計力。

攜程的數據體系

數據分析在攜程有着重要地位，這或許與攜程創始人梁建章系出計算機專業又曾在Oracle任職的經歷有關。在攜程，數據既是考量工做績效的指標，也是將來業務拓展的探針。

在攜程產品的整個生命週期中，數據始終貫穿其間。始自一個創意的誕生，需求分析階段就有基於數據的診斷性研究；隨後在產品設計環節，又會有數據作出價值預估，並給出目標建議；在產品上線初期，海量數據環境的A/B測試，數據波動關注，一直到產品上線穩定後的運營監控、定製報表，數據無一不是重要的考察因素。

工欲善其事，必先利其器。攜程平臺打造了多款數據利器，幫助員工善用數據：

利器之一，UIP用戶洞察平臺。它將主要數據指標一網打盡，產品設計可根據須要，基於頻道、頁面、地理位置、提交渠道、流量來源等，逐一查看各類PV、UV指標，以及跳出率、二跳率、退出率、轉化率、頁面停留時間等數據。

利器之二，頁面點擊插件。點擊頁面上的每一個模塊，能夠查看到它的點擊概要、訪問趨勢、統計數據明細、瀏覽器統計、頁面熱力圖等信息。

利器之三，A/B 測試，也就是切取部分流量，採用科學取樣方法，讓新舊設計版本在同一時間段同質的用戶羣體內「以實踐來檢驗」，直觀地從轉化率數據評判出設計的價值。這種方法穩定、高效，目前在酒店產品線已獲得普遍應用，測試的成功率達到15%以上。

因爲A/B測試僅在必定樣本內進行，不致對全局業務產生影響，因而設計師得到更大空間去發揮他們的創意，勇於試錯；數據比對會幫助他們不斷修正設計中的方法誤差。固然，A/B測試着力相對短時間，不能過分依賴，且更適用海量用戶的測試。

利器之四是定製開發的KPI Portal，它根據各個項目的具體需求，將與項目相關的各種數據指標集成在一塊兒，作出趨勢看板，供項目中人快速、直觀地瞭解項目目標達成狀況。有趣的是，這些指標還可換算成收益！

然而光有這些數據分析工具，難免還有所欠缺。好比酒店詳情頁上展現的房型和設施信息，要從點擊數據上分析用戶對它們優先級的排列和分組的見解，就很是困難。由於定性的問題很難經過定量的分析工具來獲得解決。此時，攜程的用戶研究團隊就受命登場了。

用研團隊會經過對典型用戶的訪談、焦點小組、卡片分類、眼動追蹤等一系列專業手段，挖掘出用戶的行爲與態度特徵，幫助產品設計理解表象行爲後的內在緣由，爲優化設計提供依據和佐證。

攜程民宿頻道的設計進化或許就可歸因於這種定量與定性分析的結合。

案例之一，攜程民宿頻道進化史

近年來，住宿市場上獨具個性和人情味的民宿、客棧異軍突起，深受遊客追捧，因而攜程應運市場趨勢，在攜程旅行客戶端推出了民宿頻道。用戶訪問的路徑是：民宿頻道首頁（選擇城市與時間段）-列表頁（選擇客棧）-詳情頁（瞭解客棧的房型信息）-預訂填寫頁（對具體房型下單購買）。

最初，民宿頻道只是將具備民宿、客棧屬性的酒店收錄進來，其頁面樣式仍然沿襲常規酒店的模板。很快，數據發現，民宿頻道各頁面的轉換率低於常規酒店。用研給出結論：民宿頻道功能照搬常規酒店，沒有考慮民宿用戶的特定需求；頻道定位不清晰，沒有凸顯特點。

因而，改版優化開始。首先，經過對訂單數據的挖掘，咱們發現民宿類酒店提早預訂天數較之常規酒店更長，預訂距離更遠，說明民宿用戶訂單特徵跟主頻道差別明顯，基本是度假出遊類型；隨後經過用戶訪談，對用戶特徵作出了分類畫像；再通過對競品的對比研究，新的設計方案脈絡清楚起來：

首頁：着重瀏覽和推薦，弱化搜索功能；總體佈局高、大、鬆；視覺暖色調，小清新

列表頁：嘗試提供大圖模式，讓用戶出行前提早了解民宿特點

詳情頁：加強模塊感，每一個模塊均外露一部份內容，讓用戶對模塊內容有預覽

初版的設計方案上線即伴隨A/B測試，結果發現訂單轉化率上升明顯，而具體到各頁面，轉化率變更狀況以下：

首頁：首頁-列表頁的轉化率出現了20%的降低（分析：用戶找不到查詢模塊，迭代時需增強）

列表頁：轉化率上升10%，可是大圖效果差於小圖列表（後續默認切換爲小圖列表，同時保留大圖列表）

詳情頁：到預訂填寫頁的轉化率上升（信息外露對用戶有效，後續外露更多內容幫助用戶更快決策；同時讓價格常駐頁面底部，減小用戶來回拖動頁面尋找的費力度）

    

在初版基礎上的迭代在兩週後上線，A/B測試的結果使人欣喜，首頁到列表頁的轉化率由原來的降低逆轉爲上升2%，訂單轉化率繼續上升26%。

面向客戶的C端產品在數據指導下得到了明確的迭代方向，而面向商戶的B端產品，也能夠藉助數據分析幫助用戶得到工做效率的提高。

案例之二，客棧通APP訂單詳情頁優化

客棧通是一款幫助民宿客棧老闆管理房態、處理訂單的軟件，在這款APP上，訂單詳情的展現對老闆相當重要，可是訂單內信息較多，在最初的版本上作了逐行展現，用戶要看全信息必須上下滑動3屏。

產品上線後就開始監測這個頁面所涉及的數據指標，咱們發現，進入訂單詳情的用戶大多隻是查看信息，作出修改的只佔13%；而修改操做中，修改訂單狀態的又遠多於修改訂單內容的。訂單修改頁面的平均停留時長達到11秒，說明用戶定位到要修改的信息再完成修改有必定費力度。

雖然對訂單信息作了逐行展現，但有些字段長度有限，能夠考慮合併；而有些字段（如房型名稱、房間號）長度可能超出但對用戶這全不是問題——客棧老闆對本身的房間如數家珍，並不強求完整展現。

因而，改版設計方向明確，咱們對訂單信息從新佈局，分紅預訂、住客、房間和結算四個小模塊，每一個模塊內信息精簡展現，令一屏內能完整展現訂單的重要信息；將低頻的修改訂單內容操做（如添加房間、入住人）經過入口隱藏起來；同時將咱們要強化的修改狀態操做置底顯示，引導用戶進入主流程（辦理預訂-辦理入住-辦理離店）。

商戶端產品的用戶數與客戶端不在一個數量級，所以設計驗證咱們未採用更適於海量數據的A/B測試，而是實地走訪多家客棧，經過高保真原型演示和任務模擬，直接觀察客棧老闆的操做，來進行可用性測試。

優化版本上線後的數據使人欣喜，訂單查看和修改頁面的PV有了30%以上的增加，訂單平均修改時長由11秒顯著下降至4秒；而與此同時，APP的訂單修改量增長了30倍。顯然，快捷方便的體驗令更多用戶把修改訂單操做由PC轉向手機。

對數據的研究終須落足於人

小結這兩個案例，對數據的監測和分析始終貫穿於產品的生命週期。而在對數據的探究中，始終圍繞着如下幾個問題：

• 問題和目標是什麼？
• 影響哪些用戶？
• 影響哪些流程？
• 你但願的結果是什麼？如何測量？
• 是否有交叉影響（致使此升彼降）？

咱們的體會是，數據必須與使用場景緊密結合，明確目標來採集分析數據，同時引入用戶調查、情境訪談等定性研究，多管齊下，善用數據資源去改進問題和發現新的可能，而非「爲數據而數據」，或是被各類數據目標牽着走。

數據貫穿設計全過程，但不可能取代用戶體驗設計。全部的數據探索、研究和分析，到最後都要落足於人，所謂「設計以人爲本」——經過數據和設計的彼此做用、相輔相成，最終去影響人的態度與行爲，收穫業務目標和良好用戶體驗的雙雙達成。

————————————————

本文做者林傳毅，攜程酒店UED資深交互設計師，2013年加入攜程，負責酒店先後臺產品設計及客棧通的總體設計。本文爲林傳毅在第八期【攜程技術微分享】中的分享內容。視頻回放可點擊這裏。

【攜程技術微分享】是攜程技術中心推出的線上公開分享課程，每個月1-2期，採用目前最火熱的直播形式，邀請攜程技術人，面向廣大程序猿和技術愛好者，一塊兒探討最新的技術熱點，分享一線實戰經驗。