※ 本文轉寄自 ptt.cc, 文章原始頁面
看板Soft_Job
標題

[心得] 如何藉由數據優化服務流程

時間
最新2023-07-06 12:05:00
留言17則留言,12人參與討論
推噓-1 ( 2312 )
分享我在數據分析上所建立的思考架構, 而這個思考架構包含了從服務流程的盤點、到數據的建立、再到場景的規劃、反覆的實驗 。 讓產品可以真的因為數據被優化,而不是產品產生的數據造成我們日常做事的困擾。 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

17 則留言

kimi112136, 1F
看了很多字,但是我覺得啥都沒有優化到的感覺?

dailylily, 2F
聞君一席話

brucetu, 3F
翻譯:大部分企業不知道用戶要什麼,反正都試試看,看會

brucetu, 4F
不會剛好在風口上,搞產品的,套公式精神喊話之後一項一

brucetu, 5F
項試錯即可

brucetu, 6F
一頓分析猛如虎,結論是增加使用次數限制以增加轉換率,

brucetu, 7F
如果用戶不買單跑去別人家,下一步?

ku399999, 8F
如果看完一篇文就優化了 大家都可以轉行了 薪水翻倍

pttnowash, 9F
浪費我一分鐘時間 還給我

Burwei, 10F
只有我有學到東西嗎XD 沒想過這些,感謝分享

knives, 11F
反正就是先把數據收集下來,有沒有用再說

loadingN, 12F
這些連web仔都知道的

hobnob, 13F
你講得在我看來都是基本觀念欸

joekaojoekao, 14F
所以是修煉之路

alan3100, 15F
..太空洞了吧 搞不好問gpt還比較詳細

ck237, 16F

brucetu, 17F
自信點把搞不好去掉

abc5555 作者的近期文章

[心得] 大型專案是升遷的美夢還是多災的雷坑?
知道這邊工程師大大居多,但想說也從PM的角度來分享面對大型專案時的情況, 讓大家可以彼此多了解一些,進而讓專案更好的進行。 內文引言 : 大型專案在職涯中如果完成了,那必定是滿滿的大補丸,不管是補履歷還是補被升遷的機 會。 但是也可能發現自
更多 abc5555 作者的文章...