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 垂直層級會到 CPO
Q8:請問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 依樣畫葫蘆學習速度會比直接跳進去論文快,可以試試找到適合自己的學習方法喔~最後,所有工作都有令人累的地方,希望大家在資料職涯中都能保持初心,記得自己選擇這條路時怦然心動的感受,不論是不是資料職位,找到維持自己熱情的事情,好好享受這個旅程吧~