1個月打造出自己的Appsflyer－用PMF與PDCA快速驗證產品核心價值
前言
約翰•沃納梅克曾說一句非常有名的行銷名言：「我知道我的廣告費有一半浪費了，但遺憾的是，我不知道是哪一半被浪費掉。」
2023年全球APP激活廣告支出達到820億美元，這樣的支出相當可觀，若未做好妥善數據分析，好幾百億美元的廣告花費就像投入水裡。這個數據是由AppsFlyer提供，而AppsFlyer就是一家專為解決此問題而存在的公司，最主要的特點和功能為「行動廣告追蹤數據」、「用戶歸因分析」、「行動分析和洞察」、「反欺詐保護」、「數據整合和 API」。而它的商業模式則是用Saas收費，依據客戶需求與使用情況，定期支付一定金額的訂閱費用，例如我們是以年費繳付，而部分功能也會再以使用量超額收費，例如廣告平台會有原始數據取用次數的限額等。 (資料來源：AppsFlyer)
當然，我們希望能夠分析成效，因此也有使用AppsFlyer的服務，但是在負擔Appsflyer高額的年費之下，我們發現自己團隊裡有PM、UI/UX、前後端RD、數據分析人員，因此起心動念：我們完全可以自己實作出這些核心功能！在這邊補充一下，我的角色是通用電商團隊負責人，主要為公司第一線運營人員提供工具與服務的團隊，因此我們的TA就是公司內部運營人員，因此決定要開始研究，我們接下來最主要的任務，就是如何用1~2個月的時間，快速驗證我們可以做出類似Appsflyer的功能，並且讓內部人員願意使用。
階段一：確認核心需求
這時候我想到Sean Ellis西恩·埃利斯(增長黑客之父)，提出了創業金字塔。金字塔模型底層是必須要有一個好用的產品，並與市場匹配，也就是我們所謂的Product/Market Fit (簡稱PMF)。當達到PMF才有機會往上到金字塔的第二層：價值傳遞，並持續優化過程(Optimize Value Delivery)。當確保能夠創造價值，金字塔最高層就要開始聚焦怎麼去擴大增長規模(Scale Growth)。
而我們目前是在產品0~1的階段，因此首要任務是要聚焦在PMF，且在有時間資源壓力下，打造出一個滿足最核心功能，且用戶覺得好用的產品。那如何找出最核心功能是什麼呢？
首先，我們觀察AppsFlyer帳號裡，使用率最高、最多的人，這些人就是我們第一批的忠實用戶，最後組成約5個人的焦點小組，與他們直接進行需求訪談。接著，設計以下幾個問題來提問運營人員，目的是為了找出需要先做的核心功能！
- 如果無法使用Appsflyer，讓你最痛苦的事情是什麼？
- 如果無法使用某某功能，有現有替代方案嗎？
過程中設計用減法來做詢問，並且觀察是1個人的痛點，還是5個人都有的痛點，因為通常詢問需求方會使用什麼功能，需求方一定會淘淘不絕，表示每個功能都是必要的，但PM在沒有足夠資源與時間下，沒有辦法讓需求方100%滿意，因此就要盡可能幫助需求方找出核心功能做取捨，讓產品能符合80%的滿意度。
最後我們找出，若要取代AppsFlyer，焦點小組最需要的功能其實是「廣告社群平台留存數據追蹤」、「下載渠道歸因分析」、「Onelink渠道建置」與「自動化數據面板」這4項。
階段二：進行PDCA，驗證技術可行性
確認這四項需求後，我們依據可行性、效益、工程規模大小，區分出實作的優先級，進而制定了如下的OKR與產品的Roadmap：
其實跨各部門的項目，對於PM來說是非常難追蹤的，但透過列出Roadmap和Sprint假設驗證來同步認知，有具體的內容來溝通排程並定期追蹤結果，對我在推動這個項目非常有幫助，推薦給大家。
若要完全取代AppsFlyer，最主要的產品是KR2的onelink建置後台+KR3數據分析後台，目標1~2個月內實作完成，而這個項目需要跨多職能與部門之間合作，所花費的溝通與實作成本會比想像中高，因此我們要先確保這件項目的可行性，於是我們增列KR1，小步快跑做MVP驗證。
KR1的目的是為了確保我們真的能做到最核心的部分：渠道歸因分析！
若這個技術無法實現，那麼後面的項目就不需要再投入，只能繼續使用AppsFlyer的服務。我們可以用兩個團隊就足以在技術上驗證是否可行。
在這階段更需要技術支援，我們需要驗證以下兩點：
- 支援跨平台：不僅需要支援iOS和Android平台，能夠對應啟動正確的APP，還要支援當用戶使用桌機版開啟連結時的到達頁面，進而跨平台追蹤和分析用戶行為。
- 支援多個廣告平台：能夠與各種第三方平台和工具無縫對接，從而實現更廣泛的整合，包括Google Ads、Meta Ads、Apple search Ads等。
在驗證的過程中有出現兩個小插曲，一個是發現需要工程服務團隊額外多幫忙做埋點，另一段是在向Google取得帳號授權API這段遲遲沒有等到回覆，剛好有發現以前申請過的帳號可以順利取得。呼~幸好順利完成。
最終我們KR1驗證成功了，順利取得下載成功數等數據資料！
階段三：繼續進行PDCA，驗證PMF
緊接著我們用同樣的方式，再次設計KR2的假設驗證如下：
KR2的目的是為了確認前後端與APP的連動有無成功，並順利對應到各渠道下載後留存的數據！
這個階段，我們需要將KR1對應的上下游介面設計出來，這意味著無論是在哪個平台上運行的應用程式，或是我們自產的渠道連結，都可以使用我們的數據介面進行統一的追蹤和分析，讓運營人員可以在同一個平台上查看各個廣告平台的數據，方便管理和優化廣告活動。
1.上游：OneLink後台
這是一個可以讓內部自行創建連結的後台，可以讓運營人員自定義自己想要推廣的渠道，並產出各種短連結放到社群上，吸引用戶來下載安裝產品。
2.中間：跨平台的串聯
根據用戶使用情境，列出Flow Chart，我認為PM在規劃上可以讓使用體驗更好的是，幫助運營人員做好預設值、選填值，這樣可以減少人為疏失，也能夠同時兼顧運營人員設定的效率與彈性。
3.下游：對應的數據呈現 (還在實作階段的規劃草圖)
在這邊就用上2007年Dave McClure提出的業務增長模型－海盜指標AARRR，我們需要觀察分析拉新、留存、變現等漏斗數據表現。
我們的漏斗可以變成這樣，進而分析出完整的使用者路徑
[R傳播]-[A獲得使用者]-[A產品互動]-[R使用者回訪]-[R獲取收入]
介面呈現大概如下 (草圖)
這階段我們正在驗證階段，等驗證結果完成，再幫大家更新上來～
寫在最後
如果你也對成為產品經理有興趣，歡迎一起加入我們！CMoney是一個創新的金融科技公司，作為產品經理，你將有機會參與並主導產品的開發和改進，與一支充滿激情和專業知識的團隊一起共事喔！
