產品經理數據入門(下)
深入淺出帶設計師了解數據大小事
承接上集後，我們將從「收集數據」開始這次的旅程。
大綱
1.產品經理為何需要具有數據思維 (Why you need data?)
2.數據驅動(Data-driven)的產品開發流程
2.1 定義問題與目標
2.2 設定假說與衡量指標
----------------------------------
2.3 收集數據-量化資料與質性資料 👈 We are here!
2.4 依據分析結果構思解決方案並迭代
3.別讓數據成為你的絆腳石-留意數據誤區
4.參考資料與連結2.3 收集數據-量化資料與質性資料
所謂的數據(Data)實際包含量化資料與質化資料（維基百科），然中文翻譯的「數據」僅包含前者，這也導致許多公司誤解所謂的數據驅動( Data Driven )只著重於量化資料即可。
「數據」只能透露用戶做了什麼，但不能告訴我們為什麼。單看數據沒有辦法了解產生數據結果背後的完整脈絡。-Netflix 消費者洞察副總裁 Adrien Lanusse
若只重量化數據而忽視質化資料，將會形成決策盲區。若透過問卷收集數據，統計結果雖能顯示一種現象與趨勢，然有時造成該種結果的原因不見得是設計問題，也可能是效能問題或其他外在因素的問題。
因此，量化資料與質化資料兩相搭配，才能更好地理解問題背後的本質，及決定問題該如何被修復。
1.內部案例：對應掃描Barcode需求，設備工程師使用電腦+Barcode槍大於使用手機掃描。
問卷調查可以讓我們知道裝置使用的多寡，除了設計與裝置效能外，我們田野調查才能知道這種結果的背後，也受廠區網路覆蓋率、設備工程師使用手套不好點擊等問題影響。2.外部案例：從量化資訊發現有女性使用者對於微軟產品使用度不高，或是要花許多時間去學習的現象。
但經過研究後發現，是一開始產品經理解釋數據解釋錯誤。應該是有幾類人比較偏愛某種學習方式，但剛好這類人的背景跟女性資料有某種程度的吻合，故產品經理誤以為女生都會遇到這樣的問題，其實與女性無關，只是碰巧誤以為是因果關係。所以想要知道為什麼，都還是要去做後續的質化分析，觀察訪談，才能瞭解背後原因與真正的問題在哪。
▌「量化資料」與 「質化資料」之差異與限制
量化資料與質化資料各有千秋與適用時機，最好能視情況互相搭配。我們常會透過量化資料先知道問題的影響範圍，再針對多數人常反應的問題來做深入質化研究。以下為兩種資料的差異比較：
1.可解之問題類別與深入度
「量化資料」能幫助你知道 The What、When、Where，能快速讓你掌握趨勢與現象，但不容易做深。
「質化資料」則是幫助你知道 The Why、How。能深入問題本質為質化研究的優勢，然需要花時間找到正確使用者，較不容易大量規模化。
2.敏捷度
「量化資料」的優點是「敏捷」，我們每天面臨很多不同的分析工具，只要今天安裝了GA(Google Analytics)，明天就能看到今天的資料，因此量化資料是敏捷的。
相對的，收集「質化資料」卻需要一定時間。如問卷設計與發放都需要時間，若希望跟使用者進行訪談，更是需要花精力找到正確使用者、跟使用者聯繫才能進行訪談，訪談每次也頂多對一個人進行。質化資料敏捷度雖較差，卻適合探究問題背後的本質。
3.資料規模
若產品遍佈全世界，擁有大量的用戶數較容易收集「量化資料」。例如A/B Testing 最好能要找上十萬人去追蹤數據才有價值。
若你的網站/產品是屬於流量很小的規模(一個月的流量不到 200人)，那麼量化數據較難提供很好的商業價值，或提出更好的判斷。企業內部系統常因為用戶樣本數不夠只有百人千人，因此較常採用的方式為發放問卷，再針對想要探究的問題做質化研究與分析。
4.環境控制
有很多人忘了思考使用者在使用產品時，有太多不同的情境跟環境。以手機使用者來說，瀏覽網頁時有人可能正在搭公車、上課、上班、甚至一邊吃飯，他們也會在各環境下產生不同的行為及想法。將這些不同場景的使用者資料都放在一起分析，會是量化數據的一大缺點。
但質化資料卻不同。我們約使用者進行訪談並現場觀察他們使用產品的狀況，該環境是可控的。你可以決定會面的時間、環境，以及透過甚麼裝置來操作產品。
▌「量化數據 」與 「質化資料」之收集方式
數據收集方式非常多，可依據問題假設與手上資源來決定。除上方列表所示，我們將分別介紹幾種常見的量化資料與質化資料收集方式。
▌量化資料收集
量化資料可以告訴我們問題在哪裡、影響的人有多少、程度有多嚴重，對安排處理優先級或錨定哪些問題再做深入研究來說很有幫助。
1. 埋點(Event tracking)
埋點學名叫「事件追蹤」，英文為 Event tracking，其目的是監測用戶與頁面互動行為。數據應用一般會有採集、加工、存儲、計算及可視化這幾個環節，而「埋點」即是一種重要的「數據採集」手段。
每個埋點都可視為一個監測點。為了讓這些監測點上的行為數據被我們收集到，我們必須在這些監測點上部署程式碼。這樣的程式碼，在網站上叫監測代碼，在app中則稱為 SDK（Software Development Kit）。
埋點的實際作法很簡單。即在 Web 或 APP 產品中植入一段程式碼用以監控用戶行為事件(例如瀏覽某個頁面)。用戶一旦觸發此事件，就會上傳埋點程式碼中定義的、需要上傳的有關該事件的訊息。
前端埋點 vs. 後端埋點
數據埋點一般可以分為兩類 — 前端埋點和後端埋點。
1.前端埋點
主要在「客戶端進行埋點」，收集前端數據如用戶行為、介面變化等。適合產品營運初級階段，產品功能相對簡單，分析前端互動行為。
2.後端埋點
主要在「服務端埋點」，收集如業務邏輯、後端交互數據等。適用於各行業中網站或 App 之重要業務需求，追求精細化運營與多維度分析，對數據安全要求較高。
不論是前端埋點還是後端埋點，都需要工程師將專用的監測代碼個別加在每個監測點上，這過程被稱作「手動埋點」。為了要保證這些代碼跟監測點一一對應，不能錯加或者漏加。
簡化開發效率 －「半自動埋點」與「全埋點」
看到這邊大家應該發現手動埋點是件非常人工又繁瑣的工作，因此為了解決這種問題就又產生了「半自動埋點」。
舉例來說，100 個埋點中可能 80 個埋點都是點擊事件(註)，這類非常相似的埋點模式就可以用同一套手段去解決。即把部分人工的工作進行標準化，開發成專用的 SDK，前端工程師只要通過 SDK 提供的接口來開發，就可以不需要考量過多細節，只需要關注:
•SDK的初始化配置
•事件怎麼標示、需要哪些參數、如何觸發
(註)點擊事件：不管點擊後有無結果，用戶點擊按鈕即算一次點擊事件。這時開始有人思考，能否再進階用一個監測程式碼，就能對網頁上或 APP 上有明確的位置的監測點都進行自動的監測呢？也就是不管需不需要，在所有監測點上都埋點。這種就稱為「全埋點(or 無埋點)」。
「無埋點」這個名詞，雖然看起來沒有了埋點這個動作，但本質上是一樣的，都是透過 SDK 實現的。可以理解為是程式碼幫工程師完成了處處埋點的繁瑣工作，這種 SDK 不需調整，已經直接嵌入在 Web/App 中。
但也因為全埋點是由一套 SDK 對應一套數據上傳方式，需要盡可能通用以適應更多場景。因此具有特殊需求的情境就被犧牲了，只能對頁面曝光、關閉，控件點擊這種通用事件進行全自動埋點。
從商業價值來看，埋點是產品經理、數據分析師基於業務/產品需求，對用戶與產品互動產生的每一個事件對應的頁面和位置做監測，以便能追踪用戶行為，推動產品優化或分析未來營運方向的一項工程。應用方向包含：
1.了解用戶行為，比如用戶的使用習慣，用戶的決策路徑，用戶的注意力分佈。
2.掌握產品動向，比如產品用戶量，產品所處的生命週期，目前的數據表現。
3.為產品決策說話，比如新功能的上線，舊功能的迭代優化等。
2. 數據收集工具 — Google Analytics(GA)
除了人工埋點，目前市面上也有很多數據收集工具。目前最普及的可能就是 Google Analytics(GA)。假如你擁有一個網站，只要在上面安裝 GA 的追蹤程式碼 (tracking code)，就能監測和蒐集使用者在網站上的各種行為資料。
以行銷產業為例，GA 能幫助我們了解網站的流量都來自於哪裡、不同的流量來源幫我們帶來的商業表現又是如何、不同時間點的流量各自有何差別、 誰有較高的轉換率或較理想的互動狀況。
上圖為 GA 的系統範例。顯示的是網站在一段時期內的數據指標表現，例如訪問情況的線性趨勢圖、 平均訪問時長和頁面瀏覽情況。這些有關訪問和頁面瀏覽情況的圖形顯示了一些網站中存在的典型模式、週末和平時的訪客量、訪問次數和頁面瀏覽量會存在一定的差異。還可以獲得訪客的一些基本資訊，如圓餅圖所示意的：用戶為新訪客或舊訪客。
若有瞭解訪客來源的需求，GA也提供分析報表告訴你訪問流量是從 YouTube、Facebook、或者其他地方來。
數據並不全是量化資料，有時候會是質化的，生活化的。接下來我們將介紹質化資料的收集方式。
▌質化資料收集
欲獲得質化資料，可以透過用戶訪談、跟蹤法、田野調查或焦點小組等眾多方式以了解用戶行為背後的需求與原因，本篇我們僅專注介紹易用性測試。
1. What / 什麼是易用性測試 (Usability Testing)
PM、設計師雖然是產品設計、UIUX 的專家，但畢竟不是真正的使用者；就算本身是使用者，也可能因為對產品、軟體設計太過熟悉而產生盲點，無法講明哪裡不好用、哪裡需要調整。
為因應這種問題，易用性測試 (Usability Testing) 能讓使用者直接與產品互動，PM 與設計師則從旁紀錄、觀察用戶行為和感受，了解他們實際如何使用產品、遇到什麼困難、是否有解決他們的問題等來驗證產品是否符合當初設定的商業目標，並以之做為參考依據以優化迭代產品。
以使用者在網路購買東西的操作行為為例：
「能否在購物網站上快速搜尋到想要購買的商品」、「能否將商品加到購物車完成結帳流程」以及「消費者在購物車內可否順利使用折價券」，便是衡量購物網站易用性的ㄧ種展現。2. When / 何時做易用性測試
你可以在這幾個階段加入易用性測試：
1.「在產品進入實際開發前 (設計階段) 」針對現階段之設計做出可互動的原型，初步驗證該解法的方向是否正確，蒐集用戶回饋來修正。(註)
2.「在功能開發完成後、產品上線前」進行易用性測試作為上線前的最後確認，避免好的點子與功能因為難用而無法發揮效果。
3.「產品上線後」若觀測到埋點或 GA 部署的量化數據顯示欲達成的指標成效不彰、且無法說明發生什麼具體問題，也很適合搭配易用性測試進一步了解背後原因，以擬定迭代方向與策略。
(註) 在「設計階段」進行易用性測試的優點：
1.能夠獲取使用者真實回饋(提前得知問題所在)
2.降低人力開發成本(不需要工程師開發，就能先快速調整設計)
3.在產品上線前，確保產品品質 (擁有真實使用者的操作結果利於提案或與團隊溝通)3. How / 易用性測試的執行規劃：計畫 > 招募 > 測試 > 分析測試結果
(1) 計劃：定義情境與測試任務
一開始我們必須先設定研究與測試目標、預期達成的結果，再來就是規劃測試流程，並撰寫流程稿與觀察重點。你可以提出明確的情境(Scenario)以及任務(Task)，切記描述須簡單明瞭不宜太長，重點是貼合你想測試的產品內容進行規劃。
Tips
建議將情境與任務以A4紙張列印出來，並帶至測試場合中。情境與任務部分可以口頭講解與說明，不過由於任務中有可能會提到須設定的時間、地點、金額或是數字…等資訊，提供紙本可讓受測者不會因為不知道資訊而打斷他們的測試過程。若目前有遠端測試需求，也可先行請受測者列印出來參照。
(2) 招募：尋找適合的受測者
受測人數
Nielsen (2000) 認為，5位受測者即可找出大部分的問題。而 Thomas (2013)等人認為 6–8 位測試者中，大部分的易用性問題在前 6 位即可找到。但如果受測者有分類別，則每個類別至少要有 4 位受測者。
受測對象
找到合適的受測對象對於是否能搜集到有用的回饋非常重要。一般來說若能邀請 End User 受測是最好的，然部分產業的系統因資訊保密原則，不易對外徵求客戶端使用者，多半以對內招募為主。對內招募對象時可以注意以下幾點：
- 不要找產品團隊的人，包含其他 PM、設計師、工程師、QA，因為他們本身就是軟體/產品專家
- 不要找你的利害關係人（stakeholder），包含你的直屬主管或老闆，這些人給的回饋不一定會中立
- 不要找真實使用者的利害關係人（stakeholder），因為他們可能會建立假設並從使用者角度思考，而不是從自己角度思考（這個階段應該是要接收受測者本人最真實的回饋）
- 同時顧及專家與新人、實習生，專家可以測試是否注意到部分設計規範，而新人腦袋裡還沒太多產品想法，對於實驗是否符合直覺操作是很好的測試對象。
對於同個公司甚至同個部門的人來說，他們腦袋已經有各種揮之不去的產品細節了。若他們想要參與測試與訪談過程，作為不介入流程的「觀察者」會更適合。
(3) 測試
每場易用性測試必要參與者除了受測者外，最好有至少兩位產品團隊的人參與，一個主訪、一個主紀錄。此外務必於測試前準備好測試原型及測試任務之相關資料。若時間允許，測試團隊也可以簡短跑過一遍。
測試當天的流程大致如下：
1.說明今日的流程與團隊的期待
2.說明測試情境與背景資訊
以上兩點即先幫受測者做心理建設、說明測試背景、測驗實施方式與團隊希望得到的回饋等等，提供範例如下。
3.讓受測者搭配「放聲思考法」開始進行測試、完成指定的任務
放聲思考法(Thinking Aloud) 是一種低成本、執行簡單、且具有彈性以及容易學習的方法。其顧名思義是請受試者在操作產品的過程中，將所有想法與即將進行的操作大聲說出來。
例如「我現在正在…..的頁面瀏覽」、「我看到這裡有…可以點擊」、「我正在閱讀…文案，我認為意思是…」、「這個Icon的表意是…嗎？」、「我現在正在操作這個介面，流程上我感覺應該要…，但是卻是…」…等。許多受測者在一開始大多會記得說出心裡的想法，但往往會越說越少，或是從一開始便不好意思說出自己的感受。這時主持人就必須嘗試使用「鼓勵與讚揚」或是「問問題」的方式引導受測者開口。
但這邊要特別注意的是勿讓受測者提供問題的設計建議與解法，而是盡可能的導正讓使用者自行說出真實想法與感受。
4.測後訪談 與 受測者回饋
測後訪談除了針對在測試時，沒跟受測者討論的議題進行追問外，也可以更加了解受測者的背景、動機，補問我們沒有在計畫中問到的基礎問題。此外也可主動請受測者提問，對整個流程做回饋。
Tips
易用性測試過程的細節變化多樣，簡言之執行測試須掌握以下原則：
1.讓測試者「自行」完成任務
2.從測試中挖掘測試者在想什麼？(4) 分析測試結果
待所有的測試都完成後，就可以開始整理、分享測試結果，並依照觀察到的問題來優化產品。
你可以查看上篇已介紹過的幾種度量模型。普遍來說有效性(任務成功與否)、效率、與滿意度在產品易用性測試中是相對重要的，只是重要程度會依照產業、產品性質的不同隨之改變。例如工具型產品與遊戲體驗型產品重視的度量就會不同。此外，也可依不同產品階段想探究的問題，將該其他度量加入分析表格中，如錯誤率或學習率等。
根據上圖，我們可以將觀察到的問題放入度量表中，從高到低開始解決，也可以根據產品的特性，來決定該解決問題的排序。但此排序應先了解問題的性質又是什麼，又是什麼原因導致問題的發生。接著以問題發生的頻率/嚴重程度來決定處理的優先順序。
假設你認為調整後的設計，還是具有許多不確定性，不妨再安排下一輪易用性測試，幫助產品獲得最好的品質不 NG!
Tips
易用性測試有它的限制，它可以告訴你產品好不好用、是否容易用，但無法完全告訴你使用者會不會想用這個功能、數據會不會成長。
對於一些較小的改動，直接上線做實驗(A/B Testing)、看數據可能會有更好的效果。除了產品本身的UIUX外，有時候文案、FAQ 的易讀性等產品輔助也會對易用性造成影響。2.4 依據數據分析結果，構思解決方案並迭代
量化資料與質化資料各有其優缺點，在商業角度扮演的角色也不一樣。我們不應一股腦的、沒方向的收集資料，實務上我們應根據遇到的問題來決定使用哪一種方式解決問題，甚至做詳細一點的規劃，比較常見的流程如下(以內容型電商網站為例)：
這邊再推薦一篇參考案例：Whoscall / Hero
3. 別讓數據成為你的絆腳石-留意數據誤區
(1) 適度依賴數據，而非全部依靠數據
數據能輔助我們決策，但數據並非唯一的決策方式。若過分依賴數據，除了妨礙我們做出精準且有效的判斷，也會限制產品經理本身應有的靈感和創意。許多優秀甚至偉大的產品決策，並非通過數據發現的，而是綜合智慧的體現。例如從馬車裡找不到關於汽車的數據，人類卻仍然能夠發明汽車。
案例：小心不要被資料矇蔽。就算是數據高手的 Google，也三不五時失敗。1.Google 前高層 Marissa Mayer，曾要求工作人員測試足足 41 種不同色階的藍色，哪種被人們使用最頻繁，從而決定網頁工具欄的顏色，然有的藍色甚至肉眼也難以分辨。2.Google 的頂尖設計師道格·鮑曼受不了一切都要量化，憤而離開 Google。他寫道：「我們爭論到底某個邊界究竟該是 3、4 還是 5 個像數寬，⋯⋯如果以為每個決定都可以簡化成邏輯問題，這些資料最後就會變成拐杖，每個決定都需要拄著柺杖，讓整個公司癱瘓！」以上這些例子指出 Google 對資料太言聽計從了，極端資料獨裁的結果，也遭來反抗。數據分析是科學的手段，但是過分依賴數據並不科學。
(2) 錯判因果關係和相關關係
因果關係：因為A的發生，導致了B的發生。比如酒醉駕駛導致交通事故，那麼酒醉就是交通事故的原因之一。
相關關係：A和B兩件事情的出現，都是出自同一個原因，數據上顯示火鍋消費高峰期和冰淇淋消費低谷總是同一個階段出現，而這兩件事情都有同樣一個原因，即天氣變冷，氣溫下降。
在分析數據的時候，發現指標裡的一些邏輯關係是指引我們產品設計的前提。如果我們在梳理數據關係的時候，把因果關係和相關關係搞混了，會導致我們做出一些錯誤的產品決策。
案例：吸煙真的是短命的原因嗎？是不是吸煙的人其他的生活習慣並不好，比如說熬夜、喝酒等也會導致吸煙的人群壽命變短；然反過來，我們也經常見到一些比較長壽的煙民。其實要證明吸煙和短命是因果關係的話，需要有一個比較嚴格的人體實驗才行，根據我們的常識做推斷不一定能夠得到準確的結論。
(3) 數據分析需要大量投資
有些人認為要做數據驅動或分析在人力資源與工具上要價不菲，因此僅限於擁有大量預算或大量內部資源的企業機構才有機會執行。然事實並非如此，現在市場上有很多開源工具和其他工具能夠幫助展示數據分析的價值如 GA；並且基於 Cloud 的大數據架構，也會比想像中便宜得多。
PM 或設計師只需要明確內部數據存儲以及要解決的問題，就可以輕鬆使用這些數據分析工具來輔助解決問題。
(4) 留心漂亮數據背後的誤區
[下載數 / Installation rate ] 部分新產品或功能上市會透過短期利益讓用戶暴增(如蝦皮免運活動、新註冊抽電影票)，這種狀況下不能將下載數作為絕對成功指標。
[淨推薦 / Net Promoter Score ] NPS 是服務的重要指標，績效指標來源。實際指「有多少用戶願意推廣你的產品」。但對於企業內工具型產品來說，許多使用者為非用不可的同一群人，因此單發一次問卷無法作為成功的絕對指標，需要定期做前測與後測，不同時期看分數是否有改變。
4. 其他參考資源
數據領域又深又廣，若大家在閱讀本篇後想再進一步了解數據，歡迎參考以下相關資源與書籍連結。
▌ 書單 ▌
1.户體驗度量(簡)
2.Designing with data 善用數據幫你打造好設計(繁) (For A/B Testing)▌ 網路資源 ▌
數據驅動的產品設計 Ref
1.5 Reasons Why Product Managers Have to Understand Data
2.Data-Driven Design: What It Is and Why It Matters
3.9 Mistakes to Avoid while creating an Internal Product
4.data-drive decision management (DDDM)
5.What is Data-Driven Product Design?
6.初嚐數據驅動的產品開發流程
7.Product Design 心法系列 — 何謂 Data-Driven Design
8.PM入門指南：產品優化方向的三個靈感來源！2C,2B產品 vs 對內產品 Ref
1.Data-driven Product Design for Internal Users
2.WTF is Internal Product產品指標 Ref
1.產品指標系列
2.Usability Metrics
3.用户体验度量之模型解析(簡)
4.Internal customer satisfaction: how to use surveys to measure and improve internal processes
5.Product Metrics for internal tools
6.CSAT How to Use the Customer Satisfaction Score (CSAT) Metric
7.CES What is Customer Effort Score (CES)?
8.How to run a customer satisfaction survey
9.HEART 產品指標設計 Google HEART framework 筆記
10.HEART Google UX HEART Framework: Project Management埋點 Ref
1.透過埋點，讓數據說話：埋點基本知識
2.為什麼要關心資料來源？談談埋點數據的陷阱
3.神策分析
4.数据埋点之前端埋点數據分析工具 Ref
1.[Google Analytics] 超詳細GA網站分析入門教學，看這篇就對了！
2.產品埋點筆記- Google Analytics 和 Mixpanel埋點工具分析
3.GA 易用性測試 Ref
1. Usability Testing 101
2.《First-Time Usability: The Test and Script》提供了滿好的範例。
3. 沒有資源做產品的使用者研究？讓我們從內部易用性測試開始！數據誤區 Ref
1. 數據太髒了！3步驟做好數據質量管理
2. 数据分析中常见的误区有哪些?
結語
現今數據驅動(Data-driven)是讓產品貼近用戶需求不可或缺的關鍵。其核心在於將每個假設付諸行動，用實驗的精神去看待每次的迭代，透過數據去了解使用者的行為與動作，縱使實驗失敗是家常便飯。
數據是一種使用者與產品對話的方式，唯有透過觀察數據，假設問題，並搭配量化與質化資料之混合驗證方式與度量指標，才能協助團隊決策下一步行動。希望本篇數據整理能對您有所幫助，我們下次見 :)！
