經常能聽到設計師大談特談數據分析，一般講的是漏斗分析，或者分析留存、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 個月內會有慢慢回升。又或者節日/突發性事件都會對某些產品/設計產生影響。有時原因是外部的：比如雖然我們沒有做什么事情，但是競品上線了新功能，或者因為政策局勢的變化引起了變化。

當然，更多的時候原因是內部的、和設計相關的，比如設計中遺留的可用性問題或者部分邊緣場景沒有被支持到。為了挖掘出這些原因，往往我們需要和用戶實地訪談，或者至少打打電話。因為問卷、取數的結論比較浮于表面，只能給到淺層的概念，而深刻的洞見、真實的反饋，只能在人和人溝通的時候漸漸表露出來。

歡迎關注作者微信公眾號：「白話說交互」