WiDS Taipei 2022| 洞察指標背後的使用者需求：Pinkoi 如何將數據落地在日常產品決策中 — 劉映蘭 Lany Liu
📍講者介紹：【Lany Liu】Pinkoi Product Analytics Lead你知道 Pinkoi 是如何打造瀏覽體驗，幫助使用者找到令他們生火不已、逛到欲罷不能的產品嗎？本次 WiDS Conference 很開心邀請到 Pinkoi 的 Product Analytics Lead Lany 與我們分享電商從發現、定義、分析到解決產品問題的一系列流程！Lany 擁有豐富的數據分析經驗，橫跨串流平台、網路業與電電商，深耕於產品及使用者行為分析，曾經擔任：Mozilla Sr. Data/Applied Statistics ScientistKKBOX Data ScientistNielsen Data Scientist如果想進一步了解 Pinkoi 如何一步步拆解顧客旅程，找到對的指標一步一步迭代產品，就千萬不要錯過本次 Lany 的分享！📍講者簡介影片：https://fb.watch/d8d_30u2oo/
Pinkoi: For people pursuing uniqueness and mindful quality in life.
希望讓使用者可以找到最能突顯自己獨特性、品味的生活用品或食品，同時服務設計師與買家。
Product Analyst平常在Pinkoi做什麼事情？
- EDA(資料探索)：
insight的發源地，透過設定各種衡量指標去拆解公司目標。
UR(user research)單位是彌補量化分析不可或缺的一部分。 - Knowledge Sharing：
發現insight後需要落地，與各個stakeholder分享和討論是重要的過程。這個過程可能是反反覆覆的迭代進行，最後會慢慢有對這個 insight 獲得共識與以及下一步可能發展的行動。 - Evaluation：
去驗這各種假設存不存在，通常會透過實驗的方式去進行。
「我想增加retention rate」
當你收到從PM而來的上面的通知時，你心中有解法嗎？
當PM說出這句話時，他背後一定有個假設，我們要去問出他背後的假設是什麼，例如，Retention rate跟我們的goal中的關聯、Retention rate代表什麼？一直來官網嗎？一直有購買行為嗎？
問出來後，可能又會遇到下一個問題，如何在business goal與user needs間取得平衡？
Top-Down Metrics Hierarchy — Business Goal
Metrics可以分成以下兩個種類：
- Leading Metrics(領先指標)：較容易因為團隊做了優化而改善。
- Lagging Metrics(落後指標)：過去已經發生的事情，不容易因為團隊優化而改善。
在這兩種metrics當中，領先指標較偏向團隊層級的衡量指標，而落後指標較偏向公司層級的衡量指標。
例如，對公司來說，年對年的銷售要成長N%；對於團隊來說，要拆解這個business goal，可能可以分為流量要成長X%、轉換率要成長Y%、客單價要成長Z%，以來達到這個目標。
以團隊來說，必須回頭去看公司最主要想達成的目標是什麼、其他團隊的目標是什麼，以避免目標不一致而產生衝突。
Bridge to Tactic Level — User Needs
團隊有目標後，要怎麼把這個目標拆解成各種project來進行？這時候就要去挖掘user needs了，盡可能的把公司想達成的目標往使用者的行為貼近。
以轉換率而言，我們可以透過User Journey來理解使用者行為，大概會經過以下這幾個階段：
Awareness → Exploration → Interest → Consideration → Purchase
「如何提高轉換率？什麼行為出現時，代表顧客找到感興趣的商品？」產品可以從這裡切入提供更流暢的體驗，來嘗試影響整體轉換率。
但是對於更深入的理解什麼是 “找到感興趣的商品”，會發現定義不明難以引發更深入的分析和討論，這時候會需要更明確探索的範圍，可以從以下兩個面向去發想和聚焦：
- 從UR團隊找尋User Voice。例如「使用者A：我一進到網站就覺得A產品很有趣，吸引我的注意力」、「使用者B：我逛了一陣子後，覺得Pinkoi的網站很特別，這邊賣的東西其他地方很少或不會賣
- 根據從UR團隊蒐集回來的User Voice，去詢問Stakeholder想要專注的點，以進行量化的分析。例如，如果想專注的點是想知道使用者怎麼找到他很感興趣的商品時，就去驗證有多少人是跟使用者A一樣、有多少人是跟使用者B一樣。
從外部蒐集完資料後，PA的任務來了：
- 任務1：如何描述有深度的探索行為？通常log的資訊都是單項且平面的，例如「使用者進行搜尋的動作」、「使用者是從首頁點選進來的」，但深度的描述比較像是「使用者在瀏覽N頁搜尋結果頁面後再回來看已經看過的商品」、「在同一個商品種類下，一連串看完10個商品後，再回來看第1個商品」
- 任務2：當使用者有哪種行為時，更接近購買行為？(預測購買)如果收斂狀態還在很前期的話，那下一步出現購買的行為的機率會比較低。
視覺化呈現圖表：
sankey：呈現使用者進站後瀏覽頁面的先後順序，可看出使用者會在哪幾個頁面流失
heatmap：使用者在不同 journey 階段特別仰賴的某幾個頁面/功能，可以幫助團隊明確地提出假設 e.g 透過優化 __{某功能}__ 來提升 __{某段 journey}__ 的完成率，進而影響整體轉換率 - 當可以輕易地描述上述假設時，就可以進入AB test的環節了
重點整理
從目標出發去制定測量指標，去思考為什麼要做這個題目
專注在User Needs，EDA會不斷地重複執行，直到了解使用者的輪廓
在跳下去做複雜的分析之前，不斷地跟各個stakeholder溝通與分享，了解目前的finding是否確實地被理解和傳達，或是跟UR做資料確認，從UR過去質化研究的觀點，互相核實彼此的發現
記得在產出分析時候也產出actionable items，讓insight不只是分享，也有機會可以被討論和落地
Q & A
Q1：從分析師走到資料科學家需要具備那些經驗與能力？
Ans：台灣的資料科學家的職稱有點太廣泛的包含各種技能
資料分析師要更看重資料整理的技能，比較著重在怎麼去解釋資料與跟商業問題結合，比較少的機會會去碰機器學習的模型Q2：通常開始這樣的process，是PM提出他想知道的問題，會自行發想商業命題？
Ans：在pinkoi，專案是以 Sqaud 為單位進行專案，裡面的組成包含設計師、PM、PA跟developer，所以其實都是團隊一起想的Q3：Product team可能同時有很多個專案在進行，PA team是怎麼挑選自己要參與哪個專案？
Ans：要依照product team他的任務類型去區分，例如有些專案的進程是在比較前面的探索性，或是比較後面的驗收流程，又或是一次性的取得資料。PA team會比較著重在探索性與驗收流程，而對於一次性的取得資料，會比較傾向幫助stakeholder取得資料的能力，而不是每次都幫他拉資料，所以可能每半年都會有一次data training。Q4：假設PA的分析結果或動到產品的feature或是既有結構，那PA怎麼跟其他部門溝通？
Ans：PA team會參與其他team的規劃過程，例如product team可能要訂個中長期的目標，會需要量化的資料去做分析，看是哪個feature要先做，這時候PA team就會進來協助，所以比較少的情況會是product team自己跑自己的。後續Q&A補充
關於分析…
Q1：Hello Lany，您好，想請教功能驗收的問題，是由甚麼過程來評估這些功能是否有達到原本提出的 metrics ? 怎麼去評估這個新功能有成功 ? 會有一個追蹤期嗎？ 如果沒有達到原本訂的 metrics 標準會持續優化這個功能還是會找其他解法?
Ans：
先說方法：
如果是個待驗證的假設會透過實驗（ab test），如果他是個很明確的功能修正則會直接上線收資料的期長：
depends on 功能的屬性，可以用 “這個功能多常被使用”、“使用者上手需要一段時間嗎” 來判斷要收集多久，e.g 首頁上搜尋按鈕可視性優化 vs. 慾望清單頁面優化，需要的收集時間就不一樣驗收結論的判斷：
這在上線前期會很需要找 stakeholder 一起決定喔～ PA 角度可以支援的是驗證差異是否存在，但對於功能優化後的期望會回到 PM 的判斷，通常花越多人力心力規劃的功能會期望帶來更大的 impact，若結果不如預期 PA 可以在驗收資料中多一點 deep-dive，提供更多線索讓 PM 決定是否還有其他機會點＆迭代的空間，最後會由 PM make the call 判斷是否停止這條策略線，或找更多可行性
Q2：想知道pinkoi平常分析資料的類型有哪些(app/web)？以及分析上有遇過怎樣的困難經驗可以分享嗎？
Ans：app / mobile web / desktop web 都有喔～
困難的地方通常是在非會員的狀態，若是跨裝置很難知道是同一個人的行為Q3：自己為數據分析師，其實有時候會覺得是用數據去講個讓各個Stakeholder都覺得合理的故事。想要請問，要怎麼衡量在「講故事」與「數據呈現」間的拿捏呢？
Ans：
good question! 呈現方式我也想了好久，我甚至在自己的 OKR 上為他放一個 O，原因是我認為沒有被如實傳達的 insight 都還不能叫 insight，因為若無法達成傳述和落地即便分析做得再多也無法有貢獻。思考方向我覺得可以不用侷限在故事性的配置上，故事給的是情境，讓聽的人能容易想像和進入資訊，我會建議用對話是的方式來一邊理解對方跟上的速度，也方便一面調整資料被描述的方式
Q4：想請問如何確定 leading metrics 跟 lagging metrics 的關聯性？（leading metrics 變好會導致 lagging metrics 變好）
Ans：
容易入門的方法：
用 user journey 去理解使用者如何達成 lagging metrics 的，用 journey 來拆（如這次的分享內容）ML 方法：
到歷史資料裡挖，解釋 model & 找到相關性，再拿出來提假設和驗證確保因果存在
Q5：Pinkoi 如何用資料判斷使用者目前在瀏覽的哪個階段？ exploration, interest
Ans：
可以回憶一下這次的分享內容，當找到不同 journey 階段代表的關鍵行動（behavior），就可以把這一系列的規則放回到每一位使用者的 journey 中，也就能知道他走到哪囉～Q6：Pinkoi 的商品在做 Feature 會用哪些明確的特徵呢？想象中 “設計” 這個概念很難以做出 feature，甚至是量化…
Ans：
不會直接去描述 “設計” 喔～ 這是個在不同人眼中會有不同定義的地方（不管是外部使用者或是內部同事間），通常會使用的方式是幫商品盡可能做分類 e.g 依使用情境、材質、用途…，一開始可能很難發想，可以試試看從使用者訪談收集一些靈感關於分工…
Q1：Product Team可能同時有很多個功能/專案在進行，PA怎麼挑選哪些專案需要involve呢？是接收PM來的requests還是PA平常就involve在產品進程中很深呢？
Ans：
PA 是在產品部門中的支援配置，所以平常會跟著不同專案線一起跑，需求類型會有 PM 主動想到的，也會有參與過程中自發性的探索。在人力有限的前提下，任務的排序會優先支援 roadmap 優先度高的專案，可以看下一點的回答Q2：提出假說，會動到 feature 的時候，要如何和 UI, UX 合作，同時產品也可能有既有的 roadmap，要怎麼與這些不同的 stakeholders 溝通？
Ans：
目前合作的方式是：
PM 定方向 -> UIUX 提設計解法 -> PM / UIUX / PA 一起確認假設（包含專案假設和設計假設）並且訂出對應的觀察指標＆實驗方式roadmap：
PA 會主動在新的一個年度開始前收集下個年度會有的專案方向和 team goal 想法，這時候的大方向可能還滿模糊的，跨部門間 kick-off roadmap planning 時候會先準備好一些量化素材協助討論的進行 e.g TA 可能有多少人、功能使用率… 確保 PA 角色在 roadmap 討論過程中的參與度，通常這時候已經可以大概知道不同季度 PA 重要的任務會是什麼了
Q3：好奇詢問，你們服務的重心是設計師還是使用者？總會有比較偏向的方向？還是這會是不同數據單位去專注的？
Ans：沒有哪一方比較重要，PA 兩者都會支援Q4：想知道pinkoi的數據團隊有多少PA?
Ans：目前配置 3 位Q5：想要詢問一下，所以在Pinkoi的數據分析的過程中，除了量化以外，質化分析的部分(UR部門)的聲音也佔很大一部分嗎？
Ans：UR 在 PA 之前就成立囉～對 Pinkoi 來說 PA 是近一年多來新的角色，可以想像過程中使用質化資料已經是稀鬆平常的事情，再加上我雖然身為 PA 也是質性資料的愛好者，PA 分析過程中少不了要和 UR 聊天吃飯喝咖啡的！Q6：想問pinkoi的產品部門同仁需要有能力來做質性訪談或研究嗎？還是會以外包方式呢？
Ans：不會預期應該要有能力來做質性訪談，通常會依賴 UR 的專業來進行，除非案子量特別大才會考慮外包一部份Q7：請問參考產品分析師的分析結果來訂定策略的人通常是誰？一樣是產品分析師嗎？還是產品經理之類的
Ans：以產品部門來說：
水平層級 PM / PO 垂直層級會到 CPOQ8：請問pinkoi上的會員點數或打卡活動等，都是PA規畫後的成果嗎?
Ans：規劃一個產品功能向來都是 PM / PD（UIUX） 的專業喔～ PA 的角色是支援他們做出判斷和決策關於職涯…
Q1：想請教，您第一份工作為數據分析師，從分析師走到資料科學家需要具備哪些經驗與能力，謝謝
Ans：以技能來說：
跨團隊溝通、拉資料、訂指標、統計檢定、Modeling
DA / PA 越前面的項目越偏重，DS 越後面的項目越偏重Q2：想請問您在資料職涯間，有沒有曾經有職業倦怠或迷惘過? 如果有，是怎麼克服的?
Ans：
曾經有幾種迷惘
1/ 顧問 or in-house：要玩跨產業的分析案，還是專案主看自家產品
2/ 硬實力：要讀的書好多，先讀哪個好
3/ 軟實力：要走向應用面還是研究面對於 1&3 只能問自己的心了（這不是廢話）哪個做起來更快樂，那個就是適合自己的選擇
至於 2 我的解決方式是，把自己丟到強者很多的環境（當初的 KKBOX RDC）想辦法學會同事們會的技能，對我來說直接看 code 依樣畫葫蘆學習速度會比直接跳進去論文快，可以試試找到適合自己的學習方法喔～最後，所有工作都有令人累的地方，希望大家在資料職涯中都能保持初心，記得自己選擇這條路時怦然心動的感受，不論是不是資料職位，找到維持自己熱情的事情，好好享受這個旅程吧～
