分享我在數據分析上所建立的思考架構， 而這個思考架構包含了從服務流程的盤點、到數據的建立、再到場景的規劃、反覆的實驗 。 讓產品可以真的因為數據被優化，而不是產品產生的數據造成我們日常做事的困擾。 Medium好讀版 : https://reurl.cc/DAOD7R -- 數據在組織中的現況 企業中大家都知道數據的重要性，但一路走來發現很多的PM，甚至是主管對於如何藉由數 據來策略性的推動產品，都還沒辦法較深入有脈絡去運作。 通常組織都會胡亂地埋了一堆數據，網頁用GA、App用flurry等，有用外部solution的可 能就看後台提供的資訊，現今的科技複雜度與商業複合運作模式下有這些分散的流程是很 正常的，但是如果沒有一個統整的面向來看待整體的用戶旅程的話，很可能就只是在建一 堆數據孤島，然後在某些時候數據出事的時候，再驚慌失措地找原因，但在追蹤這些孤島 時卻只增加了疑惑，卻找不到可能的解答。 一部份是因為大家的分工趨於精細，行銷做獲客或是內容經營，產品可能是注意留存或是 部份的轉換，然後不同的角色升上主管職，就會以過往的習慣來執行，大部份時候服務流 程需要改善的點是行銷、有時候需要改善的點是產品。 舉例: 產品升上來的主管，可能繼續用產品內的視角在看整體服務流程，但問題可能是出在獲客 。 行銷升上來的主管，可能用行銷的視角在看，但問題可能在於用戶留不住，再怎麼寄edm 給用戶，還是止不住往下掉的數據。 捧LP上去的主管，就是用各種巧妙的言論來躲避無能運作的事實，久而久之，上司覺得做 得很好，問題都有控制住，然後榮升產品長(可能無誤?)。 雖然要產品出身的看行銷，或是行銷出身看產品，這些事情有點殘忍。但我認為只是更有 意識的去認知到服務流程中，哪裡出了問題，要去優化時，可以更通盤的去看待整個局面 ，然後進到細節處理的時候，再與相關同仁以邏輯來處理相關議題。因為只要沒有整體的 視野，大家很容易各做各的，這對於用戶來說，只是一盤散沙的經營。 我會在底下提出方法供大家參考，它會從最一開始的盤點服務流程、數據建置、定義規劃 方向、規劃執行與反覆實驗，藉由這些步驟，可以去反思在工作流程中，怎麼更有脈絡的 去定義要優化的策略、鑽研的議題、觀察實驗結果是否有用。另一部份也能藉由數據讓團 隊同仁可以有更多的機會互相交流與討論，提升團隊感同時也在專案運作上可以有更多不 同的火花。 盤點服務流程 在現有的業務流程下，主管或是業務同仁通常會用過往習慣的做法來執行，而過往習慣的 做法通常是拍腦袋想出來的，而那時可能有成效，所以就一直沿襲下來了。不是說沿襲傳 統不好，而是當時代與環境在變動時，要有方法可以重新省視與評估是否有更有效益的做 法，或是該換一條路的機制存在。 通常我會使用大家都知道的AARRR來當基底，看待整體服務流程。 補充:AARRR為Acquisition、Aha-moment(Activation)、Retention、Referral、Revenue 這五個單字。 意指我們獲取用戶後，用戶有使用的動機，然後願意持續留下來，願意付錢、好到足以推 薦給其他人的概念。 而根據上述的框架，來看整體的流程結構，就能夠更有概念的去思考如何推進。因為現有 的商業模式或是服務流程，當初在形成的時候不一定是很有條理，也不太可能有條理。但 是想要更完整的去探索，或完善商業模式，沒條理就看運氣，沒運氣就是各種規劃資源與 工程資源砸到水裡。 以訂閱制的選股軟體舉例，藉由這些面向來看待服務流程 : A(獲客):獲取用戶時可能用SEO、投廣、社群經營、app自然流量 A(Aha-moment):這個產品獨到的選股方式是用戶最買單的內容 R(回訪):用戶買賣股票頻率為1~2天就應該回來 R(利潤):多少用戶續訂、新訂，訂閱中的流程怎麼走 R(推薦):有沒有對應的推薦機制 從這樣的大項目裡面就可以再去拆解細節流程， A(獲客):(下面建置數據再提) A(Aha-moment):用戶在旅程或產品流程中，什麼樣的節點會碰到或是認知到這件事? R(回訪):(下面建置數據再提) R(利潤):我們現有流程或機制是怎麼讓新用戶做訂閱， 舊流程中用戶最喜歡用的功能是什麼，最買單的是什麼? R(推薦):用戶要推薦APP，或是分享炫耀自己股票，有沒有哪些點在執行 而在這些流程盤點完後，對於一個用戶怎麼進來，怎麼留下，怎麼離開，團隊的心裡應該 就會有概念的認知了，但具體用戶到底認同我們服務中的什麼機制、不認同什麼，哪一些 和我們預料的有落差，目前還不得而知，而要知道這些資訊，則需要數據來呈現，讓我們 可以往更實際的行動方針邁進。接下來在這些節點上是否有可追蹤的數據，就進數據建置 的部份了。 數據建置 到這個步驟就以上述了解到的流程，進而確認在對應服務流程的節點上，是否有對應的數 據，讓這些數據可以清楚明瞭的把用戶的流程鋪張出來，後續才能夠對用戶做更有根據的 猜想。另一方面也在這個階段去初步盤點目前有的數據，對這些數據的聯想是什麼，是否 有些也可額外記錄的(如果技術允許的話)，有可能會幫助到後面的步驟產生洞見。 A(獲客) SEO : 現在透過搜尋進來的流量多少? 投廣 : 從廣告來的用戶多少，成本多少? 社群經營 : FB社團上每週新增多少人?大家文章互動的頻率?導流時可以轉換多少? App自然流量 : 每週下載app多少人?卸載多少人? App內轉換 : 註冊成會員的有多少人?新訪客在產品內頁面點註冊的怎麼點、多少人? A(Aha-moment) 團隊覺得最核心的功能，新用戶觸及到的比率高嗎?每週新用戶碰了幾次?每天新用戶碰幾 次? 在提供的服務流程上，有沒有哭哭moment，就是我們設計A->B->C三個流程給用戶走，在A 有100人，走到B剩25人，走到C剩10人。這種流程上的節點都是要去記錄，也包含節點周 遭的一切其他入口，因為常常會有"我們以為的用戶"和真實用戶的差異，這些點在建置階 段可以稍做概括。 R(回訪) 用戶的留存率多少?日週月分別是怎麼樣的情形(這邊沒有絕對的數值，業界都市傳說40%( 日)–20%(週)–10%(日)，但隨著不同產品場景會有巨大差異，有些KOL的選股軟體可能可 以到60~80%的日回訪) 未訂閱用戶的留存? 已訂閱用戶的留存? R($$$) 新用戶: 用戶會在什麼地方買單?怎麼買? 我們的試用機制是什麼?他一路走的節點，我們有辦法都抓到嗎? 訂戶: 續訂率多少?訂戶主要在用的功能是什麼?那邊流程順嗎? 用戶流失的原因是什麼?有沒有相關記錄的機制，來知道用戶離我們而去是未什麼?(例如: 問卷、用戶怎麼離開頁面、具體怎麼使用) R(推薦) 用戶有沒有什麼炫耀機制?或是在行銷上有哪些可以拉客的制度? 上述只是暫提幾項提供參考，實際以公司的業務流程來做考量，評估要去記錄用戶的什麼 數據，可以讓團隊更有脈絡的知道用戶在幹嘛。經過流程盤點和數據建置後，我們基本上 可以完整的一窺用戶從哪個渠道來，來多少，為什麼而用，用什麼，用戶為了什麼原因而 買，又為什麼而離去。這些輪廓就可以被更完整的描繪了，而下一步也就可以進到定義規 劃方向。 定義規劃方向 當我們服務流程定義好，數據也建置完之後。我們基本上對於整個用戶旅程會有更完整的 了解，這時候也才有辦法具體的知道該往什麼方向推進。而且在推進的方向上才能知道細 節怎麼環環相扣。 一開始我們會從比較大的數據來觀看， A(獲客):各渠道來的流量 A(Aha-moment):新用戶的留存率 R(回訪):用戶買賣股票頻率為1~2天就應該回來 R(利潤):多少用戶續訂、新訂，訂閱中的流程怎麼走 R(推薦):有沒有對應的推薦機制，有多少人推薦出去 在全面看過數據之後，有可能你們的產品相對市場好很多，但知道的人還不多，那就可以 聚焦於獲客，在上面提到的SEO、投廣、經營粉絲團等渠道，即使產品人無法更細節知道 行銷該怎麼做，就直接找團隊內的行銷同仁來討論(或是自學…當一個成長駭客)。 也可能投廣投的天荒地老、也一直在耕內容讓用戶流進來，但是產品內的留存率很低，或 是很多人玩了產品不訂閱，那這時就是更細節去思考產品裡面到底是哪裡出了問題，有可 能是UX，也可能是產品定位不對勁，這些都是可能的面向。 但是當你能夠有脈絡的說出各個面向的數據，通常團隊同仁一定也會有相當想法可以和你 討論，這時產品的氛圍和方向就會很棒了。那當我們定義好方向之後，就可以進到更細節 的規劃！ 規劃執行與反覆實驗 通常在前一個階段定義好方向後，這階段已經會是比較針對性的問題來求解。在規劃求解 的過程中，一定至少會有一個明確的預測會變好的指標，在實驗後可以去觀察確認的。 例如說: 發現獲客部份能做的不多，然後留存轉換還有很多可以努力的。 數據發現，新訂用戶每週只增加50個，但是非訂閱用戶的活躍人數每週有1萬個，日活躍 還60%，那這就代表這產品大家玩得很開心，但是付費、試用機制可能沒有做好，那我們 可能就在更多用戶常用常點擊的核心功能上，加上更嚴格的使用次數或是使用時間。那我 們的指標就是新訂用戶要能夠大幅增加！ 在這個階段要規劃，盡量讓變因相對少，因為這階段即使我們看了數據，所提出來的概念 都還是假說，一個假說在實驗時，如果有很多變因，那麼結果出來會無從驗證，甚至做的 不好也不知道到底是哪裡出錯了。 所以以上面的例子，我可能在A頁面加一個次數限制，sprint的時間還夠，就在B頁面的流 程略改(如果兩方在用戶使用上不太衝突的話)，然後在上線後，給一段時間做觀察，看產 品的用戶使用頻率，使用場景越高頻的用戶，可能幾天到一週，數據就能明顯出來了，數 據出來後證明這個實驗的假設是否正確，不過是正確或是錯誤的都是好事，因為這代表你 已經在探索產品的可能性了，你可能試錯了3個sprints，但只要做對一次，那是未來幾年 都能以有效益的方式去運作，這報酬風險比非常高，很值得做的! 小結 使用數據分析來優化服務流程，其實是一個算是縝密且有結構與步驟的科學實驗，但是這 個思考架構掌握之後，其實對於組織內，不光是產品，很多的商業模式，其實都能夠用這 樣的架構去思考優化。 如果你是一個PO，那在產品上會更清晰的知道往什麼地方走，這同時能幫助到團隊，讓團 隊知道為什麼而忙，同時也能幫助到用戶，藉由用戶下意識的行為，為他們打造更好的服 務體驗。 如果你是一個PM，提出這些脈絡在給管理者時，也能夠有更充足的資訊讓管理者去做出好 的決策。 希望數據在我們的產品路上，可以是解決問題的神兵利器，而不是只在抄抄寫寫的絆腳石 ！ -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 223.137.139.99 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1688473694.A.CF8.html