Sign in

Assistant Manager of Application Development Center @KKBOX Taiwan Co., Ltd.

The Guide to Product MetricsMixpanel

我們知道做產品功能上線後,仍需要追蹤一些指標,來衡量產品功能規劃是否成功,使用者是否埋單,後續該做什麼改善。但在規劃產品時,該怎麼設定衡量指標呢?

Mixpanel 有提了一個 Framework 方便大家歸納,有幾個面向可以規劃:

Focus Metric — Active usage(活躍使用者)

該功能最大顆粒度的最關鍵指標

Leve 1 Metrics(一級指標)

Reach(處達度)

該功能處達的人數

Activation(活躍度)

有多少「新」使用者踩過了該功能的關鍵情境(而成為該功能活躍使用者)

Engagement(互動度)

使用者使用該功能的頻率有多高?

Retention( 留存度)

有多少使用者為上一期的活躍使用者,而這一期仍然活躍使用的?

Business-specific(特定商業目標)

達成特定商業目標的情境數有多少?

Leve 2 metrics(二級指標)

二級指標通常會承接一級指標的內容,再做更細部的分析。
舉內文中影視娛樂產業 App 的處達人數為例:

  • 若該功能是特別為了「獲取新用戶」而設計,則會基於一級指標「訂閱人數」這群人,再詳加區別出屬於「原本就有在用(Retanined)」、「原本沒有用,但後來有在用(Reactivated)」、「新用戶來用(New)」這三類族群。
  • 若「新用戶來用」的人數是有在上升,且在族群別是佔預定比例以上(假設在某一段期間內,使用該功能者有 20% 是新用戶),則可以說明此功能規劃否方面是成功的。

結語

每個「指標定義的情境」都跟產品的特性息息相關。

  • 若產品屬於使用者每天、很常在用的,可能觀察的期間會是 1 週、2 週為一個期間,如:每天都在用的社群軟體 Facebook / Instagram, 每天都會拿來聽音樂的音樂服務平台 KKBOX / Spotify…)。
  • 若產品屬於使用者定期偶爾使用的,可能觀察的期間會是 1 個月、1 季,如:網路銀行(一個月至少確認一次進帳)、一季買一次衣服的服飾購物網站。

但最終,這些指標數據的用途,都是拿來衡量功能的成功與否、後續該怎麼調整方向的依據。

所以,回到最初,仍是整個團隊需要了解公司為何需要做這樣的功能?它要解決什麼問題?它要創造什麼效益?它的限制會是在哪裡?再小心謹慎地解讀這些數據,以免有快樂的假象,或是過度解讀的情況。


Pruning: Making room for something newJason Fried

Image for post
Image for post
https://deepgreenpermaculture.com/2019/08/18/how-to-prune-a-fruit-tree-step-by-step/

你多久會修剪你家的植栽

前言用了個很特別的比喻「修剪樹木」來表達如果沒有定期「修剪功能」可能會有什麼樣的後果,當你試著要修剪時可能會發現一些困難,甚至還會有情感上的因素。

畢竟這株植物可能是你耗費十年苦心種起來的

這就好比是程式碼內的 Dependencies,越久越大型的 App,往往都會有個複雜的生態,如果沒有定期的刪減或 Refactoring,就會像個雜亂無章的後院,當你要試著修剪時就會發現難以下任何一刀,因為說不定每一個 Component 都有著複雜難解的程式邏輯,這個痛點其實大多數的人都知道,但真正實踐的卻寥寥無幾,畢竟大家都知道這不是件簡單事。

刪減 Feature 具體能獲得什麼

回想看看我們的開發日常,如果當你發現你的 Release Cycle 已經陷入「加功能」、「加功能」、「加功能」這種迴圈的話,你很可能已經掉入文章說的盲點內了。

尤其當這件事情到一定程度之後,你會發現產品的所有新增功能都會因為既有功能的隱含邏輯而被綁死,導致「新功能」慢慢的會走向「優化功能」,因為程式邏輯過於複雜,導致開發難以大展身手。

Before pruning, the last thing we were thinking about was adding more products. Now, with some breathing room, new ideas are getting light, getting fresh air, and coming to life.

這個發現很有趣,過往我們只會一直想著新增功能,但當我們停下腳步後,卻會發現過往想新增的念頭全部泡沫化了,反而開始會產生過往沒有的新想法!

當房間滿了,只會買買新裝飾讓房間更美

當房間空了,你就會有新的想法怎麼裝潢

所以不用擔心停下腳步做刪減會導致 App 沒有新產出,因為當你踏出刪減這一步之後,往往自然而然跟著來的就是新點子!

好像不只是產品,對人來說也是

「刪減」具體上來說

其實會學到更好的處理事情的方法

團隊在閱覽這篇文章時有產出個共同想法,那就是基本上這套 Concept 也能套用在工程師的工作模式內,如果當你身上被炸滿了一堆事務,基本上你一天的工作就會忙於處理這些 Routine 事務。

但我們必須適時的停下腳步,回過頭來檢視自己身上的所有工作流程,看看哪些是必要的哪些是可省略的,甚至可以看看哪些能夠被自動化取代,定期的做這件事情,其實會有助於產出更多更有趣的工作模式。

這件事情不容易做到,但總該試著做一次看看

而我們正在這條航道上!


How to Sunset a Feature to Drive EngagementPulkit Agrawal

Sunset Feature 到底有多難

光是這前言就忠實的點出目前大多數人會遇到的情況,舉例來說:

  • 想刪減但又不敢大膽,因為害怕遺失該 Feature 的忠實用戶
  • 團隊成員對於刪減有認知上的差異,導致討論出現歧異
  • 刪減功能牽扯太多面向,尤其是 Legacy Issue,動也動不了
  • 缺乏對於該 Feature 有高度認知的人,是很致命的痛點

大致的問題都是互相矛盾互相牽扯的,砍 Feature 很簡單但可能就直接順手砍了 User,究竟團隊該怎麼在這錯綜複雜的情境中找出真理解呢?

這就是大家已知但卻又極度難解的問題

Image for post
Image for post
https://www.trychameleon.com/blog/sunset-feature-drive-engagement

刪減功能?我們需要的是規畫妥善的退場

直接將功能刪減掉,肯定不是個好選擇,因為用戶百百種,總會有極度仰賴此功能的使用者,因此我們需要規劃「退場」。

當 App 內有個新功能上線時,我們總是會風風光光的將此功能分享給使用者知道,但往往在退場的時候,多數的團隊並沒有好好的規劃,甚至也沒有完善的與使用者溝通,文章內利用沙漏來解釋 Customer Engagement,果然點出了我們一如往常的構思盲點,往往我們都覺得當使用者「付費」後即代表使用者 Onboard 完成,但事實上 Onboard 這件事情應該是會持續進行的。

使用者不會一直愛著你的 App

因此,不要貿然的將 App 在使用者心中的價值刪除掉,因為那很可能會直接將使用者往回推好幾步,如果完善的與使用者溝通退場流程及原因,雖然可能仍然會讓這段 Onboard 流程退步,但至少不至於大退好幾步。

而我們在這環節中也觀察出一件事實,那就是通常 User Base 越多的公司,通常退場機制可能會越潦草,因為即使他們做得不好,使用者還是可能會留著,所以關鍵應該在於「產品有沒有替代性」。

講那麼多,究竟可以怎麼做?

3 個 Key Points,我們可以試著做看看。

You need to communicate to the right person, in the right channel, with the right content.

1. 對的人

我們不必像個好鄰居代表,針對你的所有用戶都宣傳一遍,因為不是每個用戶都會用透你產品內的所有功能,因此我們僅需要針對該退場功能的忠實用戶訴說即可,而這部分的做法就仰賴各團隊的方式,像是可以從 Log System 或是 Analytics Tools 來 Mapping 出對應的名單。

2. 對的管道

Email、In-App 引導提示、推播通知,各種管道各有好壞,Email 在這個時代或許成效不佳沒錯,但收到的用戶往往能感受到不少真誠,In-App 引導提示很可能就會踩到前一點提及到的,甚至可能會干擾到其他不關心此功能的用戶,推播通知是最直接的管道,但很可能因為過往的使用方式,有可能導致使用者誤判為廣告,因此這項對的管道真的很視各個團隊的生態而定。

3. 對的內容

這點我們覺得非常之重要,千萬不要把使用者當笨蛋,總是用「我們改善了體驗」這類型的官方說法打發使用者並不是長遠之計,我們可以試著遵循以下這三點原則:

  1. 明確的讓使用者知道有所改變
  2. 明確的讓使用者知道這項改變對他來說有什麼好處
  3. 在對的時間告知使用者有這項改變

不是每個團隊生來都會處理瘦身議題

簡單來說,這真的不是一件容易事,團隊在執行退場功能的過程中一定要體悟到一件事情,就是「不管怎麼做,一定會破壞掉某些人的操作習慣」,因此我們要試著讓傷害降到最低,透過完善的功能取代規劃及與使用者溝通,建立完善的通知系統以及良好的溝通內容會是很大的輔助,這件事情一直以來都是個眾所皆知但難以執行的議題,但只能慢慢的從練習中學習!

至於 Sunset Feature 到底有什麼好處?

這就是下個議題了。


身為一個數據分析師,我在矽谷科技公司學到的幾件事Fiona Lin

文章開頭就破題,讓我們可以勾勒出資料分析師職涯的三個層次。

合格的分析師呈現數據

良好的分析師提出具體建議

優秀的分析師會提升團隊治理之道

但在分析數據前,必須要確保數據埋點跟「公司戰略」方向一致、有確實整合埋點工程。

統一的成功指標

若目前公司的戰略方向是「增加新用戶成長 5%」,為了吸引新用戶,戰術上計畫開發的新功能 A,則埋點指標除了看「有沒有人用?」,更要看「有多少新用戶來用?」、「使用此功能內,新用戶使用的佔比應該佔 50% 以上」這類面相。

只看「有沒有人用」可能會陷入零和遊戲的窘境,即使用量很多,但也許只是將既有用戶的使用習慣導來使用功能 A,而不用舊功能 B,對公司營收成長沒有幫助,等於是白花工時跟工資。

確實整合埋點工程

數據並非想到就會有得撈的,有得撈的數據也不一定值得信任,必須要確保有埋且埋得正確,整體數據還可以被查詢表單視覺化。

每一條向量線的轉換都有一關關的自動化測試,如:

  • 確保「 App 送給 Server」的埋點沒有掉、或是誤植
    e.g. App 改版中不小心刪掉這個埋點
  • 確保收到的資料的資料格式有符合規定、正規化過,寫入資料庫
    e.g. 不會有無效格式內容、未來時間

確保「資料流」和「埋點目標」沒問題後,才開始進行「資料分析」

合格的分析師呈現數據

合格的分析師會撈資料並統整數據

  1. 今年營收多少?
  2. 比去年高多少?
  3. 當地市場銷售量多少?

合格的分析師針對老闆各面向的問題,都可以信手拈來。

良好的分析師提出具體建議

良好的分析師會根據數據跟實驗提出具體建議。

  1. 根據 A / B Testing 的實際數據觀察 B 的效益高,而建議使用 B 方案。

優秀的分析師會提升團隊治理之道

優秀的分析師在執行專案時,時時刻刻都會以第三人的角度檢視流程,看可否降低各個環節的處理門檻,提高處理效率。

想辦法讓別人複製自己會的技能

舉凡「設計埋點」、「驗證埋點」、「查詢數據」等工作流程模組化,設計平易近人的 Training Book,並公開透明化這些數據跟查詢方法,讓公司內部同仁可以因為技術門檻低,而可隨時自行查詢數據來回應自己的疑惑。

當這樣各種公開透明的文化下,會造就好的團隊氣氛,加速成員進步速度,加速開發迭代,加速成功!

好的團隊氣氛,是成功的加速器

沒有笨問題,只有共同解決問題!

  • 因為決策透明,公司員工可以第一時間知道公司的策略方向,把時間跟力氣放在如何開發、創造對公司最大效益的產品。
  • 因為「Work Smart」文化,只要可以達到相同效益,不需看誰加班加得晚,鼓勵員工多進修學習,應用新方法來解決問題。
  • 因為樂於分享,大家會彼此分享新的所學,可以一起打團體戰。

整體員工的技能變高、工作開心、工時產出效益變大,受益者絕對是公司!何樂而不為?

結語

雖然此文環繞著在處理數據分析團隊的工作流程跟文化,但其實他的脈絡是一直環繞著「好的做事方法」。

  1. 必須知道
    WHY — 要解決的問題是什麼?
    HOW — 該怎麼做?
    WHAT — 做什麼?
  2. 確定一致認同的目標(就跟 Scrum 內每個 Story 的 DoD 一樣)
  3. 每個工作流程最好可以自動化,透過 Pipeline 減少人為錯誤的機會
  4. 崇尚公開透明、樂於分享、了解其他人的工作內容,不侷限自身事務
  5. 時時刻刻致力於讓處理流程可以處理更大規模的量,盡量讓事情都給機器做,不能給機器做的就降低門檻,讓做的人變多,

這樣做事情會變得開心,將時間釋放出來去接觸、應用新知。

工作也會因此開心許多!


Untools: First PrinciplesAdam Amran

每個人一定都有自己解決問題的習慣作法,但可以回想看看自己遇過最大型最複雜的問題時,我們通常習慣怎麼解決?仔細回想後,你會發現通常沒有很有系統性,「解決問題」這件事情,其實是可以透過練習並熟能生巧,如果你還沒有找到屬於自己的好方法,或許你可以嘗試看看「第一原則」。

第一原則

簡單來說就是「複雜的問題透過一些技巧拆解縮小化」,如果沒有把握這個原則,我們的處理思維通常會停留在「利用單純的解法面對複雜的問題」,這往往會是造成阻礙的一大原因,而通常複雜的問題基本上不會是單一原因所造成,把握第一原則「找到根基問題」,當複雜的問題被一一拆解成細項時,通常迎面而來的即是反面的相對應解,提出正確問題,問題即解決一半!

5 Whys


科科測試在上週一(2020/11/23)前往參加 ProductTank Taipei #23,可能會好奇,為什麼身為軟體測試工程師,會去參加與產品議題相關的 ProductTank Meetup,原因在於今年科科測試團隊除了測試議題之外,我們開始斜槓了資料分析,身為資料分析的初心者,對於這次 ProductTank Taipei #23 的主軸真的太好奇了。

「如何設定產品指標?」

產品指標理當不應該是團隊內的某些人或某些部門才該知道的事情,身為公司團隊的一份子,你一定不能不知道產品指標為何!

而科科測試也將當天的心得筆記彙整在 ProductTank Taipei 的 Medium 上,以下也幫大家整理好了,如果覺得有收穫,也不要吝嗇你的 Claps 啦! 😆

PT #23(上)如何訂立北極星指標

PT #23(中)如何找到合適的產品指標

PT #23(下)活動後記與 Q&A


若你還沒看過前兩集,可千萬不能錯過

PT #23(上)如何訂立北極星指標

PT #23(中)如何找到合適的產品指標

活動後記與心得

Image for post
Image for post
ProductTank Taipei Fan page

我想很多人參與完 ProductTank Taipei #23 後跟我有一樣的體悟:

這些視野,與我認知的落差有點大(汗)

也讓我檢視一下自己對於 Product Manager 與 Project Manager 之間的理解,這場 Talk 著實的讓我擴增的不少視野,尤其過往許多知識來自於書本、文章,但親身經歷後淬煉精華所產出的分享,只有震撼兩字能形容之。

含金量非常高的分享,但我也相信這些專業知識即使聽得懂,真要能實際運用又是另一回事了。

這肯定會需要經歷許多迭代與嘗試

但總比停滯不前好,至少會是個好的開始!

Q&A 筆記

Answerer:Stanley Tseng & Peter Su

Q. 如果 Vision、Strategy 都不明確的時候,你們會怎麼做呢?

公司或產品的願景與策略,理當是高層的責任,但也能透過具體的問題描述直接的與高層或老闆討論,不要把 Vision、Strategy 想得太複雜,簡單的問題即可勾勒:

  • 我的用戶是誰?
  • 我的產品有什麼獨特性?
  • 我的產品有什麼價值。
  • 我該怎麼做能讓用戶體現出這些價值?

Q. 如何跟老闆爭取資源?

基本上這是個信任議題,資源的獲取建立在老闆信任你的前提,明確表達你的想法、你創造的戰績、你的 Guarantee。

Q. 很多指標(Acquisition、Activation、Retention)都很重要,假設北極星指標是商品交易總額(GMV), 該怎麼判斷優先順序?

所有事情要談優先順序的時候,先思考投資報酬率(ROI)。

舉 Booking.com 的例子來說:

  • 初期需要大量人流認識品牌,因此大量投資在 Google Search Ads 擴大 User Base
  • 次階段則 All In Conversion,開始改善並優化其用戶體驗價值,像是訂房流程、免費取消訂房等等
  • 三階段則進入 All In Conversion 疲乏,這個階段基本上改動都是為做而做,像是改改按鈕位置、改改 UI 等等,因此就需要新的商業市場,像是開始往民宿產業進駐,解決新的挑戰(民宿品質不穩定,導致支援線像是客服的成本比飯店高許多)

Q. 產品的 Metrics、Target 有沒有跟 KPI 做掛鉤?

沒有直接掛鉤,但會當作參考,會衡量當年度做的事情有沒有跟 Target 相關聯,重點在於定期 Review Target 及達成率之間的落差,重要的是逼近 Target 的過程。

Q. 想請問活動後 Peter 的 Slide 會分享嗎?

這題比較簡單我先回答,會!

Q. B2B、B2C、B2Internal 的 PM 技能樹有什麼差別?

  • B2C:需掌握用戶的喜好、理解用戶的組成複雜度,可透過 User Research 的方法去了解,並透過 A/B Testing 去驗證與實驗
  • B2C/Internal:需理解對應單位 Stakeholder 或 Management 的期待,像是 Sales 的需求聲量會很大,需要花時間去了解他們的需求

Q. 如何用北極星指標來衡量做對事情?

關注 Status 指標,像是 Weekly Active User,除了關注絕對數字,還需要觀測比值型的指標,像是 WAU 的成長趨勢有沒有趨緩,去挖掘比值下降的原因。

Q. 資料科學家或資料分析師人很少或沒空的時候,可以怎麼做?

Facebook 的 Case 可能不太庶民,因為 Facebook 每個團隊都有一位資料科學家。

如果公司有開放類似 GA 的數據 Console,其實就能仰賴既有的歷史資料幫助決策,但如果是新的產品,其實也不訂立什麼 Target,因為那都是不準、無意義的,最好的作法就是直接訂立出一個猜想數字,讓產品上線直接運作一季再來回頭看看當初訂的數字落差。

Reference

筆記產出為非專業產品人士所撰寫,如有觀念偏差或錯誤,再煩請協助告知錯誤及訂正之;
筆記內容產出之來源皆會附上引用來源連結,如有誤用或連結失效也煩請通知作者修正之。

筆記共筆作者:Denny Hsu


若你還沒看過上集,可千萬不能錯過

PT #23(上)如何訂立北極星指標

看完上半場 Stanley 分享的北極星指標後,接著我們將顆粒度縮小,來聽聽看 Peter 面對「如何找到合適的產品指標」有什麼建議吧!

Peter Su

如何找到合適的產品指標

什麼是指標?

同樣的,Peter 也來個破題小知識,所謂的 Metric 到底是什麼?

Image for post
Image for post
How to Set Measurable Goals for Your Next Design Project

簡單的公式一語道破!

  • Goal:2020 年 Q4 的會員轉換率從 5% 提升至 10%
  • Metric:會員轉換率
  • Target:從 5% 提升至 10%

Peter 也簡單的分享了「指標」存在的目的:

「Metric 是用來衡量產品成功的指標,不只是用來做 Performance Review、KPI 而已,而是用來讓團隊溝通、聚焦,輔助決策的重要存在」。

上一場 Stanley 分享的北極星,指標像是顆 …


最重要的不是等著算你賺了多少錢,

而是你要怎麼知道你正前往賺錢的路上?

咳,身為一個軟體測試工程師,今年兼職著當個資料分析初心者,因此對這個撼動人心的標題表示渴望,「如何設定產品指標?」這應該是我這半年來除了「今天午餐要吃什麼?」之外,最讓我困擾的議題了。

產品規劃新功能、工程師開發和測試、新功能出版上線,就是一條再正常不過的軟體開發流程,但這整趟過程真的有人知道我們正往什麼方向走?如果習慣以「我覺得應該是」為首的溝通,肯定走往過度發散無法聚焦,當然 Data Driven 的思維不會瞬間擁有,必要先有個準確的 Metrics 才行。

來學學看 ProductTank Taipei #23 專家的做法!

Stanley Tseng

如何訂立北極星指標 — 介紹與案例分享

什麼是指標?

破題先來個小知識,勾勒一下


Understand the analytics value chainre:Work

我們時常會聽到一句闡述「當問題被拋出來時,問題就解決了一半。」但這句話背後的含義為何?難道持續的拋出問題,團隊就能迎刃而解所有問題嗎?其實這中間有些不容易的流程,而且這些流程絕對會需要實際案例來練習,讓我們先來了解什麼是 Analytics Value Chain!

Image for post
Image for post
https://rework.withgoogle.com/guides/analytics-adopt-an-analytics-mindset/steps/understand-the-analytics-value-chain/

擁有意見不是件壞事,但需要數據佐證

我們會接受到各種不同的意見,但當意見沒有被準確的證實,其實只是一昧的拋出問題、石沈大海,我們需要擁有「實事求是」的精神,將意見透過各種不同的資料搜集來佐證,這完成了 Analytics Value Chain 的前兩步,也是很重要的起始步,因為當我們獲得了數據,在 Value Chain 後續的流程就會順理成章的進行下去。

如果我們有數據,那我們就看數據;

如果沒有數據,那我們就挖掘數據!

Analytics Value Chain

我們知道數據佐證意見很重要,但究竟這每一步代表什麼意思?我們拿個實際的案例來看:

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store