經常能聽到設計師大談特談數據分析，一般講的是漏斗分析，或者分析留存、PV/UV之類的分析方法和細節，偶爾有些設計團隊分享谷歌的GSM模型，但是很少聽人講數據分析的基礎邏輯。這周我正好事情很多，就和大家簡短的分享一下。
對於設計來講，數據分析就4步：
制定指標：知道要去分析什麼
衡量指標：什麼是符合預期、什麼是正常波動、什麼是異常波動
拆解分析：假如數據不符合預期/出現異常波動，找到關鍵場景
分析原因：內部/外部原因
制定目標
項目目標：也就是谷歌GSM里的「Goal」。項目開始時，你就應該了解：這個項目的業務目的是什麼？是提升老用戶的平台粘性還是拉新促活？是提升熟練用戶的操作效率從而提昇平台體驗，還是幫助新用戶更好的學會使用產品從而降低平台運營成本？項目目標是整個設計項目的根本評判標準，雖然一般不是設計定的，但我們可以在開工之前問一嘴。
設計目標：大部分情況下，設計目標和項目目標是兩個不同的目標，設計目標往往只看行為指標（PV/UV/時長等等）和態度指標（滿意度/NPS等等）。
設計目標可以是項目目標的一部分，但是因為項目目標經常包含和行為/態度數據（也就是PV/UV/滿意度）無關的滯後業務指標（比如GMV），這種業務指標對設計沒什麼指導價值，也很難證明設計對業務指標有直接影響，所以一般不建議把項目目標直接作為設計目標。
現在你已經有了自己的設計目標——比如你的項目滿意度是3.5，那3.5是好還是差？這是需要定義的。我在之前的這篇文章中講過基本功！交互嘎韭菜常見誤區，互聯網設計是一種帶點創意的、可證偽的實證研究，為了讓我們這個設計可證偽，我們需要劃出那條證明/證偽的界限。一般而言有三種辦法：
縱向趨勢比較：我們可以和上一個時間周期做對比（比如本月和上個月的滿意度對比，這叫環比）；或者和一個更大的時間周期中相同的節點做對比（比如今年1月和去年1月的滿意度對比，這叫同比）
橫向比較：和競品或者和平台其他模塊比較，比如雖然我們的功能滿意度只有2，但是競品是1，說明總體我們解決的比他們稍微好些。
基線比較：有些量表（比如NPS、SUS）自帶了推薦的基線值，低於基線（比如NPS的7分）可以說明體驗就是不太好。
講這一塊之前我們先舉個例子，北京某大學有兩個學院，經濟學院和教育學院。廣東/天津兩地各有700個學生報考了這個大學，其中廣東省有380人高中，而天津只有260個人考中了，假如你來做這個分析，現在能得出結論：廣東省的錄取率比天津省高嗎？
不能。
假如我們以學院-省份兩個維度去拆解數據，可能會發現：經濟學是當年大熱門專業，錄取門檻極高，而教育學院沒招滿，錄取分數線比較低。廣東省報考某大學的學生報教育學院的比較多，而天津報考某大學的學生報經濟學院的多。這麼一算，反而在兩個院中，天津學生的錄取率都比廣東學生高
這件事情說明，我們需要探索、分析所有可能對總體情況造成影響的場景或者指標，否則分析結果就會和事實產生偏差。以滿意度為例，有幾種拆解維度：
基於時間的：縮小分析的時間單位，是否在某一周內滿意度驟降，導致一個月內平均滿意度都有下跌？
基於人口統計學的：不同年齡段/性別/地區/語言的用戶，是否在滿意度上有差異？是否有明顯不滿意的群體？
基於用戶技能/行為習慣的：新老用戶、小白/專家用戶、不同用戶角色、不同訴求的用戶是否在滿意度上有差異？
基於任務環節的：不同任務環節、甚至不同頁面，是否在滿意度上有差異？
拆解不同維度分析後，我們基本可以定位到具體影響設計目標的關鍵問題點：比如一部分老用戶的滿意度下降了，或者1-2月間的PV大幅下降導致整體指標受影響。最後，我們需要為這些現象找到原因。
有時原因是周期性的、不可避免的，比如一般改版後老用戶都需要一點時間去適應新的設計方案，這會導致短期內滿意度降低，但2個月內會有慢慢回升。又或者節日/突發性事件都會對某些產品/設計產生影響。
有時原因是外部的：比如雖然我們沒有做什麼事情，但是競品上線了新功能，或者因為政策局勢的變化引起了變化。
當然，更多的時候原因是內部的、和設計相關的，比如設計中遺留的可用性問題或者部分邊緣場景沒有被支持到。為了挖掘出這些原因，往往我們需要和用戶實地訪談，或者至少打打電話。因為問卷、取數的結論比較浮於表面，只能給到淺層的概念，而深刻的洞見、真實的反饋，只能在人和人溝通的時候漸漸表露出來。
留言列表